JWT - intermediate audience claim
'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.
Comments (13)
-
reporter -
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.
-
reporter Mike, the link does seem to point a wrong page. Could you give me the right one?
-
I've posted this at http://self-issued.info/docs/on-behalf-of.html. I also posted the .xml version.
-
-
assigned issue to
- edited description
-
assigned issue to
-
This was extensively discussed at IIW in October 2012, but no consensus resolution emerged.
-
reporter - changed status to open
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.
-
reporter Nat to send a proposal to the list.
-
reporter 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.
-
reporter 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
-
reporter 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.
-
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.
-
- changed status to resolved
Fixed
#636- ID Token authorized party claim→ <<cset d5c848cd2a5f>>
- Log in to comment
I wrote up a proposal: http://nat.sakimura.org/2012/08/03/named-token/