I think that's the wrong perspective. If you intend the issuer to be the subject, you need to declare it.
I wouldn't worry that it duplicates issuer. The fields have different meaning. Phil @independentid www.independentid.com phil.h...@oracle.com On 2014-03-11, at 1:43 PM, Antonio Sanso <asa...@adobe.com> wrote: > agree, but in some cases the subject is not only same as the issuer but > simply it doesn’t matter. > > In my example below all it matters is that the assertion signed by app1 is > valid…. > > Continue in my probably not relevant “Google example” if I set the prn same > as the issuer it would not work (keeping only the issuer without any subject > gives me back a correct access token instead). > > Again this is not relevant spec wise. AFIU there is consensus in the working > group to keep the subject mandatory. Would it make sense at least to add a > little not that in some situations the issuer and the subject are the same? > This might clarify at least something to people that do wonder... > > regards > > antonio > > On Mar 11, 2014, at 8:12 PM, John Bradley <ve7...@ve7jtb.com> wrote: > >> The specification is intended to allow the interoperation of standard >> libraries. >> >> In some cases the subject and the iss may be the same, however the >> underlying OAuth library may be a general one and always require a subject >> for security processing. >> >> It is possible that all libraries could have a special rule for when sub is >> not present and use the value of iss as sub. This will save some bytes in >> the JWT but it is probably not worth creating an extra code path in >> libraries for the size optimization. >> >> I don't think your saying there is no subject just that it is redundant with >> iss in some cases. >> >> John B. >> >> On Mar 11, 2014, at 2:11 PM, Antonio Sanso <asa...@adobe.com> wrote: >> >>> Ok this is my use case: >>> >>> - I am John Doe and going to AS to register my app named app1 >>> - I then either upload my public key or download a private key >>> - at this point I am ready to build my assertion, the issuer claim is going >>> to be app1 and should suffice. >>> >>> is the subject really needed in this use case? >>> >>> regards >>> >>> antonio >>> >>> >>> On Mar 11, 2014, at 4:25 PM, John Bradley <ve7...@ve7jtb.com> wrote: >>> >>>> The missing scheme especially on JWT issued by google is something I >>>> understand they are working on but need to be careful about breaking >>>> existing code, so will possibly need new endpoints that are spec >>>> compliant. >>>> >>>> While in this google case the subject and the issuer happen to be the same >>>> they may well not be even in the self signed case. In WG discussions >>>> being consistent in providing the subject was considered to be better for >>>> interoperability than optimizing for the case where sub or issuer could be >>>> dropped. >>>> >>>> John B. >>>> >>>> On Mar 11, 2014, at 12:05 PM, Hannes Tschofenig >>>> <hannes.tschofe...@gmx.net> wrote: >>>> >>>>> Maintaining both information in the JWT is IMHO valuable since it gives >>>>> you some information about the security properties. Needless to say that >>>>> there is a substantial difference between a self-created JWT and a JWT >>>>> from a third party the relying party has some confidence in. >>>>> >>>>> Why Google has an old implementation and whether they are planning to >>>>> update their code remains to be seen. >>>>> >>>>> More importantly, however, is why you argue that the subject claim has >>>>> to be optional. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> Ps: I also noticed in the examples that all URIs have their URI scheme >>>>> missing. While that might be OK I am not entirely sure... >>>>> >>>>> On 03/11/2014 04:08 PM, Antonio Sanso wrote: >>>>>> >>>>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig >>>>>> <hannes.tschofe...@gmx.net> wrote: >>>>>> >>>>>>> Thanks for clarifying. >>>>>>> >>>>>>> I took a quick look at the Google API and it seems that in their use >>>>>>> case the client creates the JWT and consequently the subject and the >>>>>>> issue would actually be the same. I suspect that this is the reason why >>>>>>> they omitted the subject. >>>>>> >>>>>> agreed that is why in my mail I said the subject might overlap with the >>>>>> issuer. >>>>>> The subject in the google case is still called with its obsolete name >>>>>> (prn) and it is actually listed as ‘additional claims’ hence not >>>>>> mandatory. >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>>> >>>>>>> Could you explain why you would like to omit the subject claim in the >>>>>>> JWT? >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> PS: Your feedback on the draft-ietf-oauth-jwt-bearer-07 spec is timely >>>>>>> since we are about to finish all three assertion specs. >>>>>>> >>>>>>> >>>>>>> On 03/11/2014 03:56 PM, Antonio Sanso wrote: >>>>>>>> hi Hannes, >>>>>>>> >>>>>>>> I am aware of the 2 documents, >>>>>>>> >>>>>>>> I might be wrong but >>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also >>>>>>>> about Authorization Grant Processing (this is the part I do use in my >>>>>>>> implementation ) and not only Client Authentication Processing. >>>>>>>> >>>>>>>> Just my 0.02 $ but this seems to be a place where different >>>>>>>> implementer have the same issue :) >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> antonio >>>>>>>> >>>>>>>> On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig >>>>>>>> <hannes.tschofe...@gmx.net> wrote: >>>>>>>> >>>>>>>>> Hi Manfred, Hi Antonio, >>>>>>>>> >>>>>>>>> Note that there are two documents that talk about the JWT and you guys >>>>>>>>> might be looking at the wrong document. >>>>>>>>> >>>>>>>>> The main JWT document (see >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines >>>>>>>>> the subject claim as optional (see Section 4.1.2). >>>>>>>>> >>>>>>>>> The JWT bearer assertion document (see >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed >>>>>>>>> define it as mandatory but that's intentional since the purpose of the >>>>>>>>> spec is to authenticate the client (or the resource owner for an >>>>>>>>> authorization grant). >>>>>>>>> >>>>>>>>> The assertion documents are used for interworking with "legacy" >>>>>>>>> identity >>>>>>>>> infrastructure (such as SAML federations). >>>>>>>>> >>>>>>>>> So, are you sure you are indeed looking at the right document? >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> >>>>>>>>> On 03/11/2014 03:13 PM, Antonio Sanso wrote: >>>>>>>>>> hi *, >>>>>>>>>> >>>>>>>>>> JSON Web Token (JWT) Profile section 3 [0] explicitely says >>>>>>>>>> >>>>>>>>>> The JWT MUST contain a "sub" (subject) claim >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now IMHO there are cases where having the sub is either not needed or >>>>>>>>>> redundant (since it might overlap with the issuer).\ >>>>>>>>>> >>>>>>>>>> As far as I can see “even Google” currently violates this spec [1] ( >>>>>>>>>> I >>>>>>>>>> know that this doesn’t matter, just wanted to bring a real use case >>>>>>>>>> scenario). >>>>>>>>>> >>>>>>>>>> WDYT might the “sub” be optional in some situation? >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> >>>>>>>>>> antonio >>>>>>>>>> >>>>>>>>>> [0] >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3 >>>>>>>>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>> >>> >> > > _______________________________________________ > 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
