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

[Torsten Lodderstedt <[e-mail]>]

+1

(we actually use a sub value of "anonymous" in our id tokens in case age 
verification, if we do not want to disclose the user's identity to the RP)

Am 25.04.2014 22:11, schrieb John Bradley:
> I am OK with that.
>
> On Apr 25, 2014, at 4:57 PM, Brian Campbell 
> <[e-mail] <mailto:[e-mail]>> 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.htmlbelong
>>>     >     >     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
>>
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth