JWT - intermediate audience claim

[Nat Sakimura]

'On behalf of' and 'user of the token' should be extremely useful. The former can be prn. We do not have anything for the later. That would solve the problem of one of the Agency that I know of.

[Nat Sakimura]

I wrote up a proposal: http://nat.sakimura.org/2012/08/03/named-token/

[Michael Jones]

I wrote an on-behalf-of draft a good while ago that I posted to the list on 8/3/12 as input to the discussion in message http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120730/002224.html.

We probably need a dedicated working group session to work on this issue.

Part of what's probably needed is clear terminology for the different potential actors involved.

[Nat Sakimura]

Mike, the link does seem to point a wrong page. Could you give me the right one?

[Michael Jones]

I've posted this at http://self-issued.info/docs/on-behalf-of.html. I also posted the .xml version.

[Michael Jones]

This was extensively discussed at IIW in October 2012, but no consensus resolution emerged.

[Nat Sakimura]

Ok. This is getting to somewhere more complex than I expected. What I was proposing was just to add a simple claim 'reg', standing for "registered to", which shows to whom it was issued to. This will allow HoK etc. in a very very simple manner. It is much less complex than delegation cases in general. I will create a new ticket for this simple proposal, and leave this ticket deal with more complex cases.

[Nat Sakimura]

Nat to send a proposal to the list.

[Nat Sakimura]

Concrete proposal: There are two types: Brief one, and more specified one.

(Option 1) Really brief one

4.1.9. "reg" (Registered to) Claim

The "reg" (registered to) claim is the Client ID of the user of the 
JWT that the audience is able to identify the client with. 
This claim is OPTIONAL.

(Option 2) Brief one

Add the following to the JWT.

4.1.9. "reg" (Registered to) Claim

The "reg" (registered to) claim identifies the client that the JWT is 
intended for. The client intended to use the JWT MUST be 
identified by the audience with the value of this claim.

The "reg" value is a case sensitive string containing a StringOrURI value.
This claim is OPTIONAL. If the principal processing the claim does not 
identify the user of the JWT with the identifier in the "reg" claim value, 
then the JWT MUST be rejected. The interpretation of the registered to 
value is generally application specific.

(Option 3) More specified one

Add the following to the JWT.

4.1.9. "reg" (Registered to) Claim

The "reg" (registered to) claim identifies the client that the JWT is 
intended for. The client intended to use the JWT MUST be 
identified by the audience with the value of this claim.

The "reg" value is a case sensitive string containing a StringOrURI value.
This claim is OPTIONAL. If the principal processing the claim does not 
identify the user of the JWT with the identifier in the "reg" 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: 
* A base64url encoded JWK. 
* A base64url encoded DER. 
* A URL that points to the key material that the audience can use to 
  authenticate the user of the JWT. 
* client_id that the audience can use to authenticate and 
  identify the client.

4.1.10 "rct" (Registered to claim type)

The "rct" (Registered to claim type) identifies the type of the "reg" claim. 
It is a StringOrURI value. The defined values are the following:

"jwk" The value of the "reg" claim is a base64url encoded JWK of 
the registered client.

"x5u" The value of the "reg" 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.

"client_id" The value of the "reg" claim is the Client ID of the client 
that the audience of the JWT is able to use to authenticate the client.

Alternatively, they can be added to Table 1 of the Messages, but I think it is general enough that it should live in JWT.

[Nat Sakimura]

Tim B. reported in openid.net connect wg mailing list that 'reg' is same as the 'cid' in the id_token implementation by Google.

cf. http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121210/002673.html

[Nat Sakimura]

Amended text. Will post the longest version to the OAuth list, as cutting down is generally easier than adding in the list.

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.

[Michael Jones]

Per discussions on the 20-Dec-12 working group call, we are defining the optional "azp" (authorized party) claim in the ID Token to experiement with this functionality.

[Michael Jones]

Fixed #636 - ID Token authorized party claim

→ <<cset d5c848cd2a5f>>