[OAUTH-WG] the meaning of audience in SAML vs. OAuth

prateek mishra <prateek.mishra@oracle.com> Thu, 14 March 2013 18:53 UTC

Return-Path: <prateek.mishra@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9221F8E95 for <oauth@ietfa.amsl.com>; Thu, 14 Mar 2013 11:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twi0k71ZY1oN for <oauth@ietfa.amsl.com>; Thu, 14 Mar 2013 11:53:31 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC621F8E99 for <oauth@ietf.org>; Thu, 14 Mar 2013 11:53:31 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2EIrSDu013028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 18:53:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EIrRFb023106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 18:53:28 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EIrRON019740; Thu, 14 Mar 2013 13:53:27 -0500
Received: from [130.129.23.121] (/130.129.23.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 11:53:27 -0700
Message-ID: <51421CA0.7010400@oracle.com>
Date: Thu, 14 Mar 2013 14:53:20 -0400
From: prateek mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Michael.Jones@microsoft.com
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <F38E6D5B-0062-4B27-BC93-1FB398F8808A@gmx.net>
In-Reply-To: <F38E6D5B-0062-4B27-BC93-1FB398F8808A@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] the meaning of audience in SAML vs. OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 18:53:32 -0000

Hannes - you make a good point.

I believe that the usage of "audience" in
http://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt

also corresponds to <saml:destination> rather than <saml:audience>.

[quote-jwt06]
The aud (audience) claim identifies the audiences that the JWT is 
intended for. Each principal
intended to process the JWT MUST identify itself with a value in 
audience claim. If the principal
processing the claim does not identify itself with a value in the aud 
claim, then the JWT MUST
be rejected. In the general case, the aud value is an array of case 
sensitive strings, each
containing a StringOrURI value. In the special case when the JWT has one 
audience, the aud
value MAY be a single case sensitive string containing a StringOrURI 
value. The interpretation
of audience values is generally application specific. Use of this claim 
is OPTIONAL.
[\quote]

I think this is a point of quite some confusion (a similar problem arose 
during the SAML assertion drafts discussion
on Tuesday).

To the extent that JWT re-uses concepts and names from SAML, I dont 
think this is the correct name with the
semantics implied by the processing rules given in jwt06.

- prateek





> Hi Prateek,
>
> I never had planned to make the term audience to align with the SAML specification.
> However, in case this could lead to confusion we could also define a different term.
>
> Btw, did you look at the JWT spec whether the audience term there is inline with the SAML spec?
>
> Ciao
> Hannes
>
> On Mar 14, 2013, at 11:34 AM, prateek mishra wrote:
>
>> Hi Hannes,
>>
>> I wanted to point out that use of the term "audience" in this document is not consistent with the SAML 2.0 specification.
>>
>>
>> What you are referring to here as "audience" corresponds to <saml:destination> which is described as
>>
>> [quote-saml2.0]
>> Destination [Optional]
>> A URI reference indicating the address to which this request has been sent. This is useful to prevent
>> malicious forwarding of requests to unintended recipients, a protection that is required by some
>> protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the
>> location at which the message was received. If it does not, the request MUST be discarded. Some
>> protocol bindings may require the use of this attribute (see [SAMLBind]).
>> [\quote]
>>
>> In contrast, <saml:audience>  is a means of limiting the liability of the asserting party and is described
>> in the following manner -
>>
>> [quote-saml2.0]
>>   <Audience>
>> A URI reference that identifies an intended audience. The URI reference MAY identify a document
>> that describes the terms and conditions of audience membership. It MAY also contain the unique
>> identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6).
>> The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of
>> one or more of the audiences specified.
>>
>> The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on
>> the basis of the information provided. However, the <AudienceRestriction> element allows the
>> SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and
>> human-readable form. While there can be no guarantee that a court would uphold such a warranty
>> exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably
>> improved.
>> [\quote]
>>
>> - prateek
>>
>>