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

[Mike Jones <[e-mail]>]

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

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


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[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 list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/oauth




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