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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Thu, 21 March 2013 20:36 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 A5F3A21F8CDD for <oauth@ietfa.amsl.com>; Thu, 21 Mar 2013 13:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8]
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 v2MFEttELUV7 for <oauth@ietfa.amsl.com>; Thu, 21 Mar 2013 13:36:27 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 761CD21F8C9D for <oauth@ietf.org>; Thu, 21 Mar 2013 13:36:27 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2LKaHOS027270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <oauth@ietf.org>; Thu, 21 Mar 2013 15:36:18 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2LKaH9C002250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 21 Mar 2013 15:36:17 -0500
Received: from [135.222.232.243] (USMUYN0L055118.mh.lucent.com [135.222.232.243]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2LKaH00013082; Thu, 21 Mar 2013 15:36:17 -0500 (CDT)
Message-ID: <514B6F40.4090107@alcatel-lucent.com>
Date: Thu, 21 Mar 2013 16:36:16 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <5141EE22.2030306@oracle.com> <F38E6D5B-0062-4B27-BC93-1FB398F8808A@gmx.net> <51421CA0.7010400@oracle.com> <4E1F6AAD24975D4BA5B1680429673943675115B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <CABzCy2AigUzN7TMVD__jf88F6gZSVCjCrJgVF8K5PnU0ndcWRg@mail.gmail.com> <514B6D66.9070809@oracle.com>
In-Reply-To: <514B6D66.9070809@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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, 21 Mar 2013 20:36:28 -0000

I have no problem with the replacement of "audience" by "recepient,"  
but whether this suggestion implemented or not, I would very much like 
to see Prateeks elegant explanation of SAML terms and their relation to 
those defined in OAuth retained somewhere in the document.  This would 
help later  those who need to parse the specification without the 
benefit of being present at this discussion.

Igor

On 3/21/2013 4:28 PM, prateek mishra wrote:
> Mike, Nat -
>
> I am honestly not sure what to propose in terms of wording 
> clarification. <Audience> has a specific meaning in SAML and thats 
> different
> from its current meaning in OAuth. This issue becomes even more 
> confusing as the SAML assertion draft goes onto
> redefine the meaning of <saml:audience>. Its processing rules for 
> <saml:audience> duplicate those for the recipient attribute within 
> <saml:SubjectConfirmation>.
>
> In SAML request messages, <saml:destination> models what is 
> represented by "audience" in Oauth.
> As I mentioned above, SAML assertions utilize a recipient attribute 
> within the <saml:SubjectConfirmation> element to achieve the
> same effect.
>
> My suggestion would be to replace "audience" by "recipient" or 
> "recipients". That would maintain a certain parallelism
> between SAML and JWT assertions. It would also avoid the current 
> duplication of processing rules
> for <saml:audience> and the "recipient" attribute in the SAML 
> assertion draft.
>
> I understand that <saml:Audience> as defined in SAML 2.0  is 
> under-used and perhaps also widely misunderstood. Nevertheless there are
> implementations that make proper use of this element and they are 
> gonna be quite confused when they try to
> implement the SAML assertion draft. I can also see some real interop. 
> difficulties arising because of this mixup.
>
> - prateek
>> well.. the aud term came from googler's use of the term and not saml.
>> I agree with Prateek that the intention of the jwt:aud is rather
>> similar to saml:destination.
>> JWT is imposing the processing rule on it while saml:audience is
>> mainly concerned about the liability.
>>
>> Nat
>>
>>
>> 2013/3/15 Mike Jones<Michael.Jones@microsoft.com>:
>>> The JWT meaning of the term "audience" is intended to be the same as 
>>> SAML.  Suggested wording clarifications would be welcomed.
>>>
>>>                                  -- Mike
>>>
>>> -----Original Message-----
>>> From: prateek mishra [mailto:prateek.mishra@oracle.com]
>>> Sent: Thursday, March 14, 2013 11:53 AM
>>> To: Hannes Tschofenig; Mike Jones
>>> Cc:oauth@ietf.org
>>> Subject: the meaning of audience in SAML vs. OAuth
>>>
>>> Hannes - you make a good point.
>>>
>>> I believe that the usage of "audience" 
>>> inhttp://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
>>>>>
>>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth