Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

[Hannes Tschofenig <[e-mail]>]

Hi all,

your text proposal sounds reasonable and it might, as suggested,
indicate what value to put in there for the anonymous user (such as
'anonymous'). Saying explicitly what implementers should be doing helps
interoperability.

Mentioning the pseudonym is also a good idea since in some cases
anonymity can be too strong and pseudonymity is what is desired. For the
terminology you could reference RFC 6973.

Ciao
Hannes

PS: A note to various folks in this email thread: We have not discussed
this issue before. As I mentioned in my original email we had only
discussed a related issue regarding client authentication. Antonio's
email lead me to think about the authorization grant, which is obviously
a different story (which only happens to be in the same document because
of the document structure we came up with).

On 04/25/2014 09:57 PM, Brian Campbell wrote:
> I absolutely agree with always requiring both issuer and subject and
> that doing so keeps the specs simpler and is likely to improve
> interoperability.
> 
> However, without changing that, perhaps some of the text in the
> document(s) could be improved a bit. Here's a rough proposal:
> 
> Change the text of the second bullet in
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-5.2 to
> 
> "The assertion MUST contain a Subject. The Subject typically identifies
> an authorized accessor for which the access token is being requested
> (i.e. the resource owner, or an authorized delegate) but, in some cases,
> may be a pseudonym or other value denoting an anonymous user. When the
> client is acting on behalf of itself, the Subject MUST be the value of
> the client's client_id."
> 
> And also change
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1 to
> 
> "When a client is accessing resources on behalf of an anonymous user, a
> mutually agreed upon Subject identifier indicating anonymity is used.
> The Subject value might be an agreed upon static value indicating an
> anonymous user or an opaque persistent or transient pseudonym for the
> user may also be utilized. The authorization may be based upon
> additional criteria, such as additional attributes or claims provided in
> the assertion. For example, a client may present an assertion from a
> trusted issuer asserting that the bearer is over 18 via an included
> claim. In this case, no additional information about the user's identity
> is included, yet all the data needed to issue an access token is present."
> 
> And maybe also change the subject text in SAML and JWT (item #2 in
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-08#section-3 and
> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-19#section-3)
> to read a little more like the new proposed text above for section 5.2
> of the Assertion Framework draft.
> 
> Would that sit any better with you, Hannes? Thoughts from others in the WG?
> 
> 
> On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Agreed.
> 
>     On Apr 25, 2014, at 3:07 PM, Mike Jones <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>>     I agree.  We’d already discussed this pretty extensively and
>>     reached the conclusion that always requiring both an issuer and a
>>     subject both kept the specs simpler and was likely to improve
>>     interoperability.____
>>      
>>     It’s entirely up to the application profile what the contents of
>>     the issuer and the subject fields are and so I don’t think we need
>>     to further specify their contents beyond what’s already in the
>>     specs.____
>>      
>>                                                                 --
>>     Mike____
>>      
>>     *From:* OAuth [mailto:[e-mail]] *On Behalf Of *Brian
>>     Campbell
>>     *Sent:* Friday, April 25, 2014 10:17 AM
>>     *To:* Hannes Tschofenig
>>     *Cc:* [e-mail] <mailto:[e-mail]>
>>     *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject
>>     issue____
>>     __ __
>>
>>     I believe, from the thread referenced earlier and prior discussion
>>     and draft text, that the WG has reached (rough) consensus to
>>     require the subject claim. So text that says "Subject element MUST
>>     NOT be included" isn't workable.____
>>
>>     It seems what's needed here is some better explanation of how, in
>>     cases that need it, the value of the subject can be populated
>>     without using a PII type value. A simple static value like
>>     "ANONYMOUS-SUBJECT" could be used. Or, more likely, some kind of
>>     pairwise persistent pseudonymous identifier would be utilized,
>>     which would not directly identify the subject but would allow the
>>     relying party to recognize the same subject on subsequent
>>     transactions. A transient pseudonym might also be appropriate in
>>     some cases. And any of those approaches could be used with or
>>     without additional claims (like age > 18 or membership in some
>>     group) that get used to make an authorization decision. ____
>>
>>     I wasn't sure exactly how to articulate all that in text for the
>>     draft(s) but that's more of what I was asking for when I asked if
>>     you could propose some text.____
>>
>>
>>
>>
>>     ____
>>
>>     __ __
>>
>>     On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig
>>     <[e-mail] <mailto:[e-mail]>>
>>     wrote:____
>>     Hi Brian,
>>
>>     Thanks for pointing to the assertion framework document.
>>     Re-reading the
>>     text it appears that we have listed the case that in Section 6.3.1 but
>>     have forgotten to cover it elsewhere in the document.
>>
>>
>>     In Section 6.3.1 we say:
>>
>>     "
>>
>>     6.3.1.  Client Acting on Behalf of an Anonymous User
>>
>>        When a client is accessing resources on behalf of an anonymous
>>     user,
>>        the Subject indicates to the Authorization Server that the
>>     client is
>>        acting on-behalf of an anonymous user as defined by the
>>     Authorization
>>        Server.  It is implied that authorization is based upon additional
>>        criteria, such as additional attributes or claims provided in the
>>        assertion.  For example, a client may present an assertion from a
>>        trusted issuer asserting that the bearer is over 18 via an included
>>        claim.
>>
>>     *****
>>         In this case, no additional information about the user's
>>        identity is included, yet all the data needed to issue an access
>>        token is present.
>>     *****
>>     "
>>     (I marked the relevant part with '***')
>>
>>
>>     In Section 5.2, however, we say:
>>
>>
>>        o  The assertion MUST contain a Subject.  The Subject identifies an
>>           authorized accessor for which the access token is being
>>     requested
>>           (typically the resource owner, or an authorized delegate).  When
>>           the client is acting on behalf of itself, the Subject MUST
>>     be the
>>           value of the client's "client_id".
>>
>>
>>     What we should have done in Section 5.2 is to expand the cases inline
>>     with what we have written in Section 6.
>>
>>     Here is my proposed text:
>>
>>     "
>>     o  The assertion MUST contain a Subject.  The Subject identifies an
>>     authorized accessor for which the access token is being requested____
>>
>>     (typically the resource owner, or an authorized delegate).
>>
>>     ____
>>
>>     When the client is acting on behalf of itself, as described in Section
>>     6.1 and Section 6.2, the Subject MUST be the value of the client's
>>     "client_id".
>>
>>     When the client is acting on behalf of an user, as described in
>>     Section
>>     6.3, the Subject element MUST be included in the assertion and
>>     identifies an authorized accessor for which the access token is being
>>     requested.
>>
>>     When the client is acting on behalf of an anonymous user, as described
>>     in Section 6.3.1, the Subject element MUST NOT be included in the
>>     assertion. Other elements within the assertion will, however, provide
>>     enough information for the authorization server to make an
>>     authorization
>>     decision.
>>     "
>>
>>     Does this make sense to you?
>>
>>     Ciao
>>     Hannes____
>>
>>
>>     On 04/24/2014 02:30 PM, Brian Campbell wrote:
>>     > There is some discussion of that case in the assertion framework
>>     > document at
>>     > http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1
>>     >
>>     > Do you feel that more is needed? If so, can you propose some text?
>>     >
>>     >
>>     > On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig____
>>     > <[e-mail]
>>     <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>>> wrote:
>>     >
>>     >     Hi Brian,
>>     >
>>     >     I read through the thread and the Google case is a bit
>>     different since
>>     >     they are using the client authentication part of the JWT
>>     bearer spec.
>>     >     There I don't see the privacy concerns either.
>>     >
>>     >     I am, however, focused on the authorization grant where the
>>     subject is
>>     >     in most cases the resource owner.
>>     >
>>     >     It is possible to put garbage into the subject element when
>>     privacy
>>     >     protection is needed for the resource owner case but that
>>     would need to
>>     >     be described in the document; currently it is not there.
>>     >
>>     >     Ciao
>>     >     Hannes
>>     >
>>     >
>>     >     On 04/24/2014 12:37 AM, Brian Campbell wrote:
>>     >     > That thread that Antonio started which you reference went
>>     on for some
>>     >     > time
>>     >     >
>>     >    
>>     (http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520)
>>     >     > and seems to have reached consensus that the spec didn't need
>>     >     normative
>>     >     > change and that such privacy cases or other cases which didn't
>>     >     > explicitly need a subject identifier would be more
>>     appropriately dealt
>>     >     > with in application logic:
>>     >    
>>     > http://www.ietf.org/mail-archive/web/oauth/current/msg12538.html
>>     >     >
>>     >     >
>>     >     >
>>     >     >
>>     >     > On Wed, Apr 23, 2014 at 2:39 AM, Hannes Tschofenig
>>     >     > <[e-mail]
>>     <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>>____
>>     >     <mailto:[e-mail]
>>     <mailto:[e-mail]>____
>>     >     <mailto:[e-mail]
>>     <mailto:[e-mail]>>>> wrote:
>>     >     >
>>     >     >     Hi all,
>>     >     >
>>     >     >     in preparing the shepherd write-up for
>>     >     draft-ietf-oauth-jwt-bearer-08 I
>>     >     >     had to review our recent email conversations and the issue
>>     >     raised by
>>     >     >     Antonio in
>>     >     >
>>     >  
>>       http://www.ietf.org/mail-archive/web/oauth/current/msg12520.html belong
>>     >     >     to it.
>>     >     >
>>     >     >     The issue was that Section 3 of
>>     draft-ietf-oauth-jwt-bearer-08
>>     >     says:
>>     >     >     "
>>     >     >        2.   The JWT MUST contain a "sub" (subject) claim
>>     >     identifying the
>>     >     >             principal that is the subject of the JWT.  Two
>>     cases
>>     >     need to be
>>     >     >             differentiated:
>>     >     >
>>     >     >             A.  For the authorization grant, the subject
>>     SHOULD
>>     >     identify an
>>     >     >                 authorized accessor for whom the access
>>     token is being
>>     >     >                 requested (typically the resource owner, or an
>>     >     authorized
>>     >     >                 delegate).
>>     >     >
>>     >     >             B.  For client authentication, the subject
>>     MUST be the
>>     >     >                 "client_id" of the OAuth client.
>>     >     >     "
>>     >     >
>>     >     >     Antonio pointed to the current Google API to
>>     illustrate that
>>     >     the subject
>>     >     >     is not always needed. Here is the Google API
>>     documentation:
>>     >     >  
>>       https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>     >     >
>>     >     >     The Google API used the client authentication part (rather
>>     >     than the
>>     >     >     authorization grant), in my understanding.
>>     >     >
>>     >     >     I still believe that the subject field has to be
>>     included for
>>     >     client
>>     >     >     authentication but I am not so sure anymore about the
>>     >     authorization
>>     >     >     grant since I could very well imagine cases where the
>>     subject
>>     >     is not
>>     >     >     needed for authorization decisions but also for
>>     privacy reasons.
>>     >     >
>>     >     >     I would therefore suggest to change the text as follows:
>>     >     >
>>     >     >     "
>>     >     >        2.   The JWT contains a "sub" (subject) claim
>>     identifying the
>>     >     >             principal that is the subject of the JWT.  Two
>>     cases
>>     >     need to be
>>     >     >             differentiated:
>>     >     >
>>     >     >             A.  For the authorization grant, the subject
>>     claim MAY
>>     >     >                 be included. If it is included it MUST
>>     identify the
>>     >     >                 authorized accessor for whom the access
>>     token is being
>>     >     >                 requested (typically the resource owner, or an
>>     >     authorized
>>     >     >                 delegate). Reasons for not including the
>>     subject claim
>>     >     >                 in the JWT are identity hiding (i.e., privacy
>>     >     protection
>>     >     >                 of the identifier of the subject) and
>>     cases where
>>     >     >                 the identifier of the subject is
>>     irrelevant for making
>>     >     >                 an authorization decision by the resource
>>     server.
>>     >     >
>>     >     >             B.  For client authentication, the subject
>>     MUST be the
>>     >     >                 included in the JWT and the value MUST be
>>     populated
>>     >     >                 with the "client_id" of the OAuth client.
>>     >     >     "
>>     >     >
>>     >     >     What do you guys think?
>>     >     >
>>     >     >     Ciao
>>     >     >     Hannes
>>     >     >
>>     >     >
>>     >     >     _______________________________________________
>>     >     >     OAuth mailing list____
>>
>>     >     >     [e-mail]
>>     <mailto:[e-mail]> <mailto:[e-mail]
>>     <mailto:[e-mail]>> <mailto:[e-mail]
>>     <mailto:[e-mail]>
>>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>>     >     >     https://www.ietf.org/mailman/listinfo/oauth
>>     >     >
>>     >     >
>>     >
>>     >____
>>
>>     __ __
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
> 
>