+1 thanks
antonio On Mar 12, 2014, at 8:08 AM, Manfred Steyer <[email protected]> wrote: > Hi John, > > thx for this explanation. It helps me to see, why this decision has been > made. > > Wishes, > Manfred > > > -----Ursprüngliche Nachricht----- > Von: John Bradley [mailto:[email protected]] > Gesendet: Dienstag, 11. März 2014 20:49 > An: Manfred Steyer > Cc: Hannes Tschofenig; Antonio Sanso; [email protected] > Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile > > Company X will likely care about the subject being asserted by company A for > auditing and possible revocation. > > It may be that the extension claim accessLevel=Accounting is sufficient to > grant the access token. > > By Policy A could make sub itself, or an identifier for the user of the > client in it's namespace. > > Yes there are some cases where it may be redundant or not disclosed for a > privacy reason, but the current decision is to keep the library consistent > and push that decision to the application logic. > > You can make the case the decision was wrong. > > The other reason for it is that the JWT and SAML assertions are parallel and > in SAML subject is required. That was the other consistency reason for > making it mandatory. > > John B. > > > On Mar 11, 2014, at 4:28 PM, Manfred Steyer <[email protected]> wrote: > >> Hi, >> >> perhaps you can show that I'm wrong, but I still think, that there are >> cases, where the subject is unknown cause it's not relevant. Let's > consider >> the following federation-scenario: >> >> 1. Bob has a Token T1 that says, that he works for Company A on Project > B. >> The Subject of this token is "Bob". >> 2. Company X says, that everyone in Company A working for Project B gets >> access to Accounting-Information. >> 3. Bob exchanges this Token T1 at Company X's AuthServer for another Token >> T2. T2 contains a claim AccessLevel=Accouting. T2 could also get a copy of >> the subj-claim, but Company X doesn't care about that, cause no one in >> Company B knows Bob. >> >> The only reason I can imagine, why the sub-claim should be copied into T2 > is >> because of tracing and finding out, that there is a correlation between T2 >> und T1. But this could be accomplished with other mechanisms too. >> >> Did I oversee something? If there is another reason, why sub is mandatory, > I >> think, it would not hurt too much to copy the sub-claim from T1 to T2 (and >> from T2 to T3 etc.)... >> >> Wishes >> Manfred >> >> >> >> -----Ursprüngliche Nachricht----- >> Von: OAuth [mailto:[email protected]] Im Auftrag von Hannes > Tschofenig >> Gesendet: Dienstag, 11. März 2014 16:05 >> An: Antonio Sanso >> Cc: [email protected] >> Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile >> >> 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 > <[email protected]> >> 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 >> <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
