Re: [OAUTH-WG] "cid" claim in JWT

[Nat Sakimura <[e-mail]>]

Thanks Justin for a very good rundown. I agree with these. It would be a
disservice to the community not to include "azp" (aka "reg", "cid") in JWT,
as this gives so much clarity on the issue.

Let me add one more: it is a use case for HoK of the presenter while not
letting the issuer know where it is being presented. (e.g., showing
driver's license at a liquor shop.) Most of the physical identity documents
(e.g., passport, national ID card, etc.) falls into this category.

iss => Authorization Server
aud => *
sub => Subject of the JWT Claim Set
azp => Subject of the JWT Claim Set

Nat

On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer <[e-mail]> wrote:

>  I thought I should drop in my full rundown of the party representation
> here. Assuming a standard 3-legged OAuth flow of any flavor, you have the
> following mapping:
>
>  iss => Authorization Server
>  aud => Resource Server(s)
>  sub => Resource Owner
>  azp => Client
>
> Note that the "sub" claim here is a drop-in replacement for "prn" and that
> "azp" is a more or less drop-in replacement for "cid".
>
> Of course there are other ways that a JWT could be minted, so let me be a
> bit more concrete with a few examples.
>
> 3-legged OAuth:
>
>  iss: http://auth.example.org/
>  aud: http://resource.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> 2-legged OAuth (client credentials):
>
>  iss: http://auth.example.org/
>  aud: http://resource.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Client authentication assertion, self-issued:
>
>  iss: oauth-client-1
>  aud: http://auth.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Authorization grant assertion, self-issued:
>
>  iss: oauth-client-1
>  aud: http://auth.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> Client authentication assertion, non-self-issued:
>
>  iss: http://auth.example.org/
>  aud: http://auth.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Authorization grant assertion, non-self-issued:
>
>  iss: http://auth.example.org/
>  aud: http://auth.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> OpenID Connect ID Token:
>
>  iss: http://auth.example.org/
>  aud: oauth-client-1
>  sub: bob.smith
>  azp: oauth-client-1
>
>
>
> Note that repeated values are intentional and MUST be preserved, since
> there's no way to know the value of a "missing" claim otherwise.
>
> There are likely other use cases here as well. Writing this all out has
> made me wonder if this needs to be captured in an online spreadsheet
> somewhere.
>
>  -- Justin
>
>
>
> On 12/20/2012 11:22 AM, Mike Jones wrote:
>
>  This was discussed on the OpenID Connect call this morning.  Our sense
> was that “Authorized Party” was actually a more general description of the
> concept than Client ID.  Justin Richer pointed out that at that point,
> there would be claims defined for representing all four potential parties
> in an OAuth interaction.  Connect plans to define the optional “azp”
> (Authorized Party) claim to let people experiment with it.  There wasn’t a
> sense that it’s necessary to add to the JWT spec itself at this time.****
>
> ** **
>
> As for the proposed “cid” (Client Identification Data claim type) claim,
> our sense was that that is more related to proof of possession, and can be
> discussed in that context.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Nat Sakimura [mailto:[e-mail] <[e-mail]>]
> *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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *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
> [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****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>


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