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

Mike Jones <Michael.Jones@microsoft.com> Thu, 20 December 2012 06:07 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3876121F8848 for <oauth@ietfa.amsl.com>; Wed, 19 Dec 2012 22:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q8fRtJfGtpQ for <oauth@ietfa.amsl.com>; Wed, 19 Dec 2012 22:07:21 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 857E321F8853 for <oauth@ietf.org>; Wed, 19 Dec 2012 22:07:15 -0800 (PST)
Received: from BL2FFO11FD005.protection.gbl (10.173.161.203) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 06:07:06 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 06:07:06 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 06:07:02 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Nat Sakimura <sakimura@gmail.com>
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eeDoQnms0qid0tk+0K29GGMlTVQ==
Date: Thu, 20 Dec 2012 06:07:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697EF82TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(53806001)(54316002)(44976002)(56776001)(1411001)(15202345001)(512874001)(74662001)(31966008)(54356001)(76482001)(47446002)(550184003)(74502001)(56816002)(5343635001)(47736001)(46102001)(16236675001)(33656001)(5343655001)(59766001)(50986001)(77982001)(4396001)(16406001)(51856001)(47976001)(55846006)(49866001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2012 06:07:25 -0000

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 <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> 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 <tonynad@microsoft.com<mailto:tonynad@microsoft.com>> 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: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-<mailto:oauth->bounces@ietf.org<mailto:bounces@ietf.org>] 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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




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