SUB is totally undefined, if I remember correctly. Nat
On Fri, Dec 21, 2012 at 1:39 AM, Anthony Nadalin <[email protected]>wrote: > I can’t see how you think PRN is way under defined when SUB is not**** > > ** ** > > *From:* Nat Sakimura [mailto:[email protected]] > *Sent:* Wednesday, December 19, 2012 11:43 PM > *To:* Mike Jones > *Cc:* Anthony Nadalin; John Bradley; oauth > > *Subject:* Re: [OAUTH-WG] "cid" claim in JWT**** > > ** ** > > As "prn" is way under-defined [1], there can be two interpretations for > "prn". **** > > ** ** > > Considering that "subject" is not a defined term (= dictionary term), and > interpreting a boarding pass as:**** > > ** ** > > "Japan Airlines authorizes JL002 to accept passenger John Smith at the > Gate B22 provided safety and other requirements are met between the > boarding time (14:30) and 10 minutes before the departure time (15:10)" ** > ** > > ** ** > > then: **** > > ** ** > > iss: Japan Airlines**** > > prn: JL002 (the flight number)**** > > cid: John Smith (the passenger, who uses the boarding pass)**** > > aud: Gate B22 (Gate assigned to JL002)**** > > nbf: 2012-12-31T14:30+9**** > > exp: 2012-12-31T15:00+9**** > > ** ** > > Alternatively, if we interpret the boarding pass as: **** > > ** ** > > "Japan Airlines authorizes John Smith to board JL002 at the Gate B22 > provided safety and other requirements are met the boarding time (14:30) > and 10 minutes before the departure time (15:10)""**** > > ** ** > > iss: Japan Airlines**** > > prn: John Smith**** > > cid: John Smith**** > > aud: Gate B22 (Gate assigned to JL002)**** > > nbf: 2012-12-31T14:30+9**** > > exp: 2012-12-31T15:00+9**** > > ** ** > > This interpretation has lost some information while encoding into JWT, so > prior one may be more appropriate. **** > > ** ** > > Either way, as "prn" lacks exact semantics, what goes into it is subject > to interpretation while "cid" is very clearly defined. **** > > ** ** > > Let me give another example. **** > > ** ** > > An entitlement that says: "John Smith is allowed to activate the system > when Mary White presents this token (#1234) to the System A" that is issued > by the "ABC Corp"**** > > ** ** > > iss: ABC Corp. **** > > jti: #1234**** > > prn: John Smith**** > > cid: Mary White**** > > aud: System A**** > > ** ** > > Note: this is not delegation nor on-behalf-of. **** > > ** ** > > More webby example: "John Smith authorizes photo print service A to access > photo archive service B for John Smith's photo #123 until 2013-04-01 for > the sum of $100."**** > > ** ** > > iss: John Smith's Authorization Server**** > > prn: John Smith's photo #123**** > > cid: Photo print service A**** > > aud: photo archive service B**** > > exp: 2013-04-01**** > > ** ** > > Nat**** > > ** ** > > [1] 4.1.6 "prn" defines its value as what identifies:**** > > ** ** > > "the subject of the JWT" **** > > ** ** > > This can be expanded by replacing "JWT" with its definition as **** > > ** ** > > "the subject of the string consisting of multiple parts, the first being > the Encoded JWT Header, plus additional parts depending upon the contents > of the header, with the parts being separated by period ('.') characters, > and each part containing base64url encoded content."**** > > ** ** > > Further, expanding "JWT Header", it will become **** > > ** ** > > "the subject of the string consisting of multiple parts, the first being > the string representing a JSON object that describes the cryptographic > operations applied to the string, plus additional parts depending upon the > contents of the header, with the parts being separated by period ('.') > characters, and each part containing base64url encoded content."**** > > ** ** > > To me, it is not clear what it means. **** > > ** ** > > ** ** > > On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <[email protected]> > wrote:**** > > What would the iss, prn, aud, and cid values represent in the boarding > pass example?**** > > **** > > -- Mike**** > > **** > > *From:* Nat Sakimura > *Sent:* December 19, 2012 9:32 PM > *To:* Mike Jones > *CC:* Anthony Nadalin, John Bradley, oauth > *Subject:* Re: [OAUTH-WG] "cid" claim in JWT**** > > **** > > I obviously disagree - if I did agree, I did not send it to the list to > start with :-) **** > > ** ** > > "cid" (or in my original proposal, "reg") has a very clear and established > meaning. **** > > The parallel examples abounds in our daily life. **** > > ** ** > > It has very little to do with On-behalf-of. **** > > It is not a delegation statement. **** > > ** ** > > "cid" is there to indicate to whom it was issued to. **** > > The entity who was issued this "token" is eligible to use it at the **** > > entities indicated by "aud". **** > > ** ** > > Example in our real life are like: **** > > ** ** > > - Airline boarding pass**** > > - Registered instruments (bond / share) **** > > - Monthly train pass**** > > - Disneyland annual passport**** > > etc. etc. **** > > ** ** > > Please do not mix it up with a delegation statement like on-behalf-of, *** > * > > which is much less well defined. **** > > ** ** > > Nat**** > > ** ** > > ** ** > > On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones <[email protected]> > wrote:**** > > I'm with Tony on this. This seems premature to put into the JWT > standard. All the other JWT claims have well established meanings and > history behind them. These don't.**** > > **** > > If the goal is to allow OpenID Connect implementations to not reject > tokens using “cid”, there are lots of other ways to accomplish this that I > think we should consider first.**** > > **** > > -- Mike**** > > **** > > **** > > *From:* John Bradley > *Sent:* December 19, 2012 6:25 PM > *To:* Anthony Nadalin > *CC:* oauth**** > > *Subject:* Re: [OAUTH-WG] "cid" claim in JWT**** > > **** > > I agree, audience who requested it and and who it is requested for are all > interrelated. **** > > ** ** > > However we do need to set down some standard way of expressing it as > people are starting to make stuff up on their own that will impact > interoperability.**** > > ** ** > > If Google starts thawing in cid and clients don't know about it they must > reject the JWT etc.**** > > ** ** > > John**** > > ** ** > > On 2012-12-19, at 9:40 PM, Anthony Nadalin <[email protected]> wrote:* > *** > > ** ** > > It seems premature and we should consider this in the bigger context of > the “on behalf of”/delegation work that has been started**** > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Nat Sakimura > *Sent:* Tuesday, December 18, 2012 6:22 PM > *To:* oauth > *Subject:* [OAUTH-WG] "cid" claim in JWT**** > > **** > > In OpenID Connect WG, we have been talking this for sometime. **** > > "cid" claim identifies the entity that the JWT was issued to as a > rightful/licensed user. **** > > Google already uses this in their implementation of id_token of OIDC. **** > > **** > > Here is the text proposal. It introduces two new standard claims: "cid" > and "cit". **** > > **** > > It would be very useful in creating a HoK drafts as well. **** > > **** > > Cheers, **** > > **** > > Nat**** > > **** > > **** > > *4.1.9. "cid" Client Identification Data Claim***** > > **** > > The "cid" (client identification data) claim allows the receiver **** > > of the JWT to identify the entity that the JWT is **** > > intended to be used by. The audience of the JWT MUST be **** > > able to identify the client with the value of this claim.**** > > **** > > The "cid" value is a case sensitive string containing a StringOrURI value.**** > > This claim is OPTIONAL. If the entity processing the claim does not **** > > identify the user of the JWT with the identifier in the "cid" claim value, > **** > > then the JWT MUST be rejected. The interpretation of the registered to **** > > value is generally application specific.**** > > **** > > A typical example of a registered to claim includes following: **** > > * client_id that the audience can use to authenticate and **** > > identify the client.**** > > * A base64url encoded JWK. **** > > * A URL that points to the key material that the audience can use to **** > > authenticate the user of the JWT.**** > > **** > > *4.1.10 "cit" (Client Identification Data claim type)***** > > **** > > The "cit" (Client Identification Data claim type) identifies the type **** > > of the "cid" claim. It is a StringOrURI value. The defined values **** > > are the following:**** > > **** > > "client_id" The value of the "cid" claim is the Client ID of the client **** > > that the audience of the JWT is able to use to authenticate the client.**** > > **** > > "jwk" The value of the "cid" claim is a base64url encoded JWK of **** > > the registered client.**** > > **** > > "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of **** > > JSON web signature [JWS].**** > > **** > > "x5u" The value of the "cid" claim is the URL that points to the public **** > > key certificate of the registered client. The format of the content **** > > that x5u points to is described in section 4.1.4 of the JSON Web > Signature.**** > > **** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > **** > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > > > **** > > ** ** > > -- > Nat Sakimura (=nat) **** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > > > **** > > ** ** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
