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 <bcampb...@pingidentity.com > 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 < > 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.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 <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
