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