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

[Brian Campbell <[e-mail]>]

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