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

[Brian Campbell <[e-mail]>]

And those new drafts have now been published:

http://tools.ietf.org/html/draft-ietf-oauth-assertions-16
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-09
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-20


On Mon, Apr 28, 2014 at 12:41 PM, Brian Campbell <[e-mail]
> wrote:

> Thanks Hannes,
>
> I'll update that text to reference RFC 6973 and also to indicate a
> specific value which could be used for the anonymous user. And I'll publish
> new drafts here soon(ish).
>
>
>
>
>
>
> On Mon, Apr 28, 2014 at 2:49 AM, Hannes Tschofenig <
> [e-mail]> wrote:
>
>> 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.2to
>> >
>> > "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.1to
>> >
>> > "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
>> >
>> >
>>
>>
>