[Openid-specs-ab] "reg" claim in JWT

[Nat Sakimura]

Amended text. Changed "reg" to "cid". 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.


On Wed, Dec 12, 2012 at 8:15 AM, Nat Sakimura <sakimura at gmail.com> wrote:

> Oh, that is good to know. That is a real statement of use.
> I do not have attachment to the claim names.
> Semantically, cid would be more purpose free than reg.
>
> Nat
>
>
> On Wed, Dec 12, 2012 at 1:53 AM, Tim Bray <tbray at textuality.com> wrote:
>
>> Hm, the ID Tokens our OIDC connect endpoint produces currently contain a
>> “cid” claim, which if I understand correctly is used for this.  It’s very
>> useful. “cid” seems slightly more mnemonic.  -Tim
>>
>>  On Mon, Dec 10, 2012 at 5:33 PM, Nat Sakimura <sakimura at gmail.com>wrote:
>>
>>>  As it was discussed during today's call, here is the concrete proposal
>>> that I am making.
>>>
>>> I would take them to OAuth ML if you guys agree.
>>>
>>>
>>> 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 (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121219/04c4c74c/attachment.html>