+1. Saving a few bytes in exchange to interoperability and security possible downgrade does not seem to be a good strategy for me.
Nat 2014-03-12 7:04 GMT+09:00 Phil Hunt <phil.h...@oracle.com>: > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
