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> 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>> 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> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
