Agreed. On Apr 25, 2014, at 3:07 PM, Mike Jones <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 > 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> 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>> 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>>> 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.html belong > > > 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>> > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
