Subject: [OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience)

From: prateek mishra <[email-masked]>
Date: Thu, 14 Mar 2013 11:34:58 -0400

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Mar 2013 11:51:42 -0400

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
> In contrast, <saml:audience>  is a means of limiting the liability of the asserting party and is described
> 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
> 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
> 
>

---

From: prateek mishra <[email-masked]>
Date: Thu, 14 Mar 2013 14:53:20 -0400

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Mar 2013 18:56:46 +0000

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:[email-masked]] 
Sent: Thursday, March 14, 2013 11:53 AM
To: Hannes Tschofenig; Mike Jones
Cc: [email-masked]
Subject: the meaning of audience in SAML vs. OAuth

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

[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

>> 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
>>
>>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 15 Mar 2013 05:12:37 +0900

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 <[email-masked]>:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: prateek mishra <[email-masked]>
Date: Thu, 21 Mar 2013 16:28:22 -0400

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
> 2013/3/15 Mike Jones<[email-masked]>:
>> Cc:[email-masked]
>> I believe that the usage of "audience" inhttp://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt
>>

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 21 Mar 2013 13:31:06 -0700

Hey Prateek - and suggested improvements for the SAML Bearer draft?

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 21 Mar 2013 16:36:16 -0400

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:
> In SAML request messages, <saml:destination> models what is 
> represented by "audience" in Oauth.
> 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
>>> The JWT meaning of the term "audience" is intended to be the same as 
>>> SAML.  Suggested wording clarifications would be welcomed.
>>>
>>>                                  -- Mike
>>>
>>> I believe that the usage of "audience" 
>>> inhttp://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt
>>>
>>> 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).
>>>
>>> think this is the correct name with the semantics implied by the 
>>> processing rules given in jwt06.
>>>
>>> - prateek
>>>
>>>
>>>
>>>
>>>
>>>> Hi Prateek,
>>>>
>>>>> I wanted to point out that use of the term "audience" in this 
>>>>> document is not consistent with the SAML 2.0 specification.
>>>>>
>>>>>
>>>>> URI reference identifies the location at which the message was 
>>>>> received. If it does not, the request MUST be discarded. Some 
>>>>> conditions of audience membership. It MAY also contain the unique 
>>>>> be no guarantee that a court would uphold such a warranty 
>>>>> warranty exclusion is considerably improved.
>>>>> [\quote]
>>>>>
>>>>> - prateek
>>>>>
>>>>>

---

From: prateek mishra <[email-masked]>
Date: Thu, 21 Mar 2013 17:24:12 -0400

Agreed, Chuck - I need to respond to Brian's message of Feb 14 and 
suggest proposed text for the draft. I plan to get to it in the next day 
or two.

- prateek

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Mar 2013 09:21:05 +0900

Prateek,

At this point, I would like to be a bit cautious about changing the claim
names as it would impact bunch of implementations that are potentially
being used by hundreds of millions of users now.

I am more open to change the text that defines "aud".

Currently, it goes:

4.1.3.  "aud" (Audience) Claim

   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.

Personally, I think there are two ways to change it.

The first way (Type 1) removes the processing requirements from aud claim.
As an individual expert, I feel that JWT should not mandate the processing
requirement on aud,
but just give the semantics of it and let the protocols/profiles decide on
the processing rules.

4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim specifies the audiences that the JWT is
   intended for. 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.

   Note 1: The issuer cannot prevent a party to whom the token is
   disclosed from taking action on the basis of the information provided.
   However, the aud claim allows the issuer to state explicitly that
   no warranty is provided to such a party in a machine 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.

A slight variation of Type 1 (Type 1a) alignes more closely to SAML's
definition.
(Much of the text is straight out of SAML Core 2.0)

4.1.3.  "aud" (Audience Restriction) Claim

   The "aud" (audience restriction) claim specifies that
   the JWT is addressed to one or more specific audiences identified
   by the elements of its value. Although a receiving party
   that is outside the audiences specified is capable of
   drawing conclusions from the token, the issuer explicitly makes
   no representation as to accuracy or trustworthiness to such a party.

   In the general case, the "aud" value is an array of case sensitive
   strings, each containing a StringOrURI value that identifies the
   audience intended for. 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
   restriction values is generally application specific.
   Use of this claim is OPTIONAL.

   Note 1: The issuer cannot prevent a party to whom the token is
   disclosed from taking action on the basis of the information provided.
   However, the aud claim allows the issuer to state explicitly that
   no warranty is provided to such a party in a machine 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.

The second way (Type 2)  is to change the acronym text.

4.1.3.  "aud" (Assertion Usage Destination) Claim

   The "aud" (assertion usage destination) claim identifies
   the party that the JWT is intended for.
   Each party intended to process the JWT MUST
   identify itself with a value in audience claim.  If the party
   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.

Note that I changed principal to party, since principal has more specific
meaning than wanted here.

Among them, I actually prefer Type 1a as I believe that JWT should be
generic.

BTW, I feel that the way aud is written now is a bit confusing to
developers.
Is the value of the aud claim an array or string?
It should still spell it out that both are permitted more explicitly.

Nat

2013/3/22 prateek mishra <[email-masked]>

> 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
> 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.
>
> implementations that make proper use of this element and they are gonna be
> quite confused when they try to
>> 2013/3/15 Mike Jones<Michael.Jones@microsoft.**com<[email-masked]>
>> >:
>>
>>> From: prateek mishra [mailto:prateek.mishra@oracle.**com<[email-masked]>
>>> ]
>>> I believe that the usage of "audience" inhttp://www.ietf.org/id/**
>>> draft-ietf-oauth-json-web-**token-06.txt<http://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt>
>>>
>>>
>>> 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]
>>>
>>> during the SAML assertion drafts discussion on Tuesday).
>>>
>>> think this is the correct name with the semantics implied by the processing
>>> rules given in jwt06.
>>>
>>> - prateek
>>>
>>>
>>>
>>>
>>>
>>>  Hi Prateek,
>>>>
>>>>> received. If it does not, the request MUST be discarded. Some protocol
>>>>> bindings may require the use of this attribute (see [SAMLBind]).
>>>>> [\quote]
>>>>>
>>>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>
>>
>