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

[Nat Sakimura <[e-mail]>]

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]>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]>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]>
>> 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]] *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]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [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