Re: [OAUTH-WG] JSON Web Token (JWT) Profile

[Nat Sakimura <[e-mail]>]

+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 <[e-mail]>:

> 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
> [e-mail]
>
> On 2014-03-11, at 1:43 PM, Antonio Sanso <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]> 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
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en