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
Hey Prateek - and suggested improvements for the SAML Bearer draft?


On Mar 21, 2013, at 1: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.jo...@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.mis...@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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to