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 < hannes.tschofe...@gmx.net> 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 <ve7...@ve7jtb.com > > <mailto:ve7...@ve7jtb.com>> wrote: > > > > Agreed. > > > > On Apr 25, 2014, at 3:07 PM, Mike Jones <michael.jo...@microsoft.com > > <mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org] *On Behalf Of *Brian > >> Campbell > >> *Sent:* Friday, April 25, 2014 10:17 AM > >> *To:* Hannes Tschofenig > >> *Cc:* oauth@ietf.org <mailto:oauth@ietf.org> > >> *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 > >> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> > >> 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____ > >> > <hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net> <mailto: > hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net>>> 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 > >> > > <hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net> <mailto: > hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net>>____ > >> > <mailto:hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net>____ > >> > <mailto:hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net>>>> 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____ > >> > >> > > OAuth@ietf.org > >> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > >> <mailto:OAuth@ietf.org>> <mailto:OAuth@ietf.org > >> <mailto:OAuth@ietf.org> > >> > <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>> > >> > > https://www.ietf.org/mailman/listinfo/oauth > >> > > > >> > > > >> > > >> >____ > >> > >> __ __ > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org <mailto:OAuth@ietf.org> > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
