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

From: Mike Jones <[email-masked]>
Date: Thu, 20 Dec 2012 06:07:01 +0000

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> [mailto:oauth-<mailto:oauth->[email-masked]<mailto:[email-masked]>] 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 20 Dec 2012 16:42:50 +0900

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-masked]>wrote:

>  *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
>
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones <[email-masked]>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
>>
>>  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.
>>
>>  On 2012-12-19, at 9:40 PM, Anthony Nadalin <[email-masked]>
>> 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-masked] [mailto:[email-masked]] *On
>> Behalf Of *Nat Sakimura
>> *Sent:* Tuesday, December 18, 2012 6:22 PM
>> *To:* oauth
>> *Subject:* [OAUTH-WG] "cid" claim in JWT
>>
>> *4.1.9. "cid" Client Identification Data Claim*
>>
>>
>>
>> *4.1.10 "cit" (Client Identification Data claim type)*
>>
>>
>>
>> [email-masked]
>> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Dec 2012 16:22:17 +0000

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:[email-masked]]
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

"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

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.

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

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."

Nat

"the subject of the JWT"

"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."

"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."

On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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

- Airline boarding pass

Nat

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

John

It seems premature and we should consider this in the bigger context of the "on behalf of"/delegation work that has been started

Cheers,

Nat

  identify the client.

are the following:

the registered client.

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 20 Dec 2012 16:39:08 +0000

I can't see how you think PRN is way under defined when SUB is not

then:

iss: Japan Airlines

iss: Japan Airlines
prn: John Smith
cid: John Smith

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Nat

"the subject of the JWT"

-- Mike

From: Nat Sakimura

- Airline boarding pass

Nat

-- Mike

From: John Bradley

John

Cheers,

Nat

  identify the client.

are the following:

the registered client.

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 22 Dec 2012 02:08:35 +0900

SUB is totally undefined, if I remember correctly.

Nat

On Fri, Dec 21, 2012 at 1:39 AM, Anthony Nadalin <[email-masked]>wrote:

>  I can’t see how you think PRN is way under defined when SUB is not****
>
> ** **
>
> *From:* Nat Sakimura [mailto:[email-masked]]
> *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****
>
> ** **
>
> "prn". ****
> ** **
> 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: ****
>
> ** **
>
> 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****
>
> ** **
>
> 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. ****
>
> ** **
>
> 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. ****
>
> ** **
>
> 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 ****
>
> ** **
>
> and each part containing base64url encoded content."****
>
>  ** **
>
> Further, expanding "JWT Header", it will become ****
>
> ** **
>
> 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-masked]>
> wrote:****
>
>   What would the iss, prn, aud, and cid values represent in the boarding
> pass example?****
>
>  ****
>
> -- Mike****
>
>  ****
>
> *From:* Nat Sakimura
> *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-masked]>
> wrote:****
>
> history behind them.  These don't.****
>
>  ****
>
> think we should consider first.****
>
>  ****
>
> -- Mike****
>
>  ****
>
>  ****
>
> *From:* John Bradley
> *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. ****
>
> ** **
>
> 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-masked]> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Nat Sakimura
> *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)****
>
> @_nat_en****
>  ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat) ****
>
> @_nat_en****
> ****
> ** **
> Nat Sakimura (=nat)****
> @_nat_en****

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 Dec 2012 10:38:13 -0500

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:[email-masked]]
> boarding time (14:30) and 10 minutes before the departure time (15:10)"
>
> then:
>
> iss: Japan Airlines
>
> 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
>
> Either way, as "prn" lacks exact semantics, what goes into it is 
> subject to interpretation while "cid" is very clearly defined.
>
> 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
>
> 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."
>
>     "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."
>
>     "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."
>
> On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> pass example?
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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
>     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.
>
>         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-masked] <mailto:[email-masked]>
>         [mailto:oauth- <mailto:oauth->[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Nat Sakimura
>         The "cid" value is acase  sensitive string containing a StringOrURI value.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 30 Dec 2012 13:18:31 +0900

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 <[email-masked]> wrote:

> here. Assuming a standard 3-legged OAuth flow of any flavor, you have the
> following mapping:
>
> 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:
>
> 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:[email-masked] <[email-masked]>]
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 30 Dec 2012 08:05:51 +0000

We added "azp" as an optional claim in the OpenID Connect ID Token definition to let people experiment with it.  However, unlike the other three claims (issuer, subject, audience) discussed below, for which there is a great deal of industry experience, the "authorized party" claim is one we're newly making up and I don't think its semantics are well understood.

For starters, would it be better expressed as a second audience value rather than a separate claim?  Must it also be an audience of the token?  What validation steps must/should which parties perform when an "azp" claim is present?  What steps must/should which parties perform when one is not present?

If this matures to the point that it seems that there is sufficient usage experience of the "azp" claim to believe that it's the right way of meeting a need and that there are well-understood consensus answers to the questions above based upon that usage experience, then great.  At that point I'd be in favor of adding it to the JWT spec.

I'm fine with experimental use in OpenID Connect, but I think it's way too early to add it to the JWT spec now.

Finally, remember that it's very easy to add a new claim definition even after the JWT spec is an RFC by defining the claim in another spec and registering the claim in the IANA JSON Web Token Claims registry.  I'd rather we be conservative about the claims we add in the JWT spec itself and then add new ones by defining them in additional specs as it makes sense.

                                                            -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Saturday, December 29, 2012 8:19 PM
To: Justin Richer
Cc: Mike Jones; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

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.

Nat

On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> 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:

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: oauth-client-1

 iss: oauth-client-1

OpenID Connect ID Token:

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

                                                            -- Mike

then:

iss: Japan Airlines

iss: Japan Airlines
prn: John Smith
cid: John Smith

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Nat

"the subject of the JWT"

-- Mike

From: Nat Sakimura

- Airline boarding pass

Nat

-- Mike

From: John Bradley

John

Cheers,

Nat

  identify the client.

are the following:

the registered client.

OAuth mailing list