IETF Logo Mail Archive

Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Mike Jones <Michael.Jones@microsoft.com> Sun, 13 April 2014 04:17 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80451A01D3 for <oauth@ietfa.amsl.com>; Sat, 12 Apr 2014 21:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_bebi-t9tv3 for <oauth@ietfa.amsl.com>; Sat, 12 Apr 2014 21:17:54 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id A26011A01CD for <oauth@ietf.org>; Sat, 12 Apr 2014 21:17:53 -0700 (PDT)
Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB026.namprd03.prod.outlook.com (10.255.240.40) with Microsoft SMTP Server (TLS) id 15.0.921.12; Sun, 13 Apr 2014 04:17:49 +0000
Received: from BL2FFO11FD032.protection.gbl (2a01:111:f400:7c09::105) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Sun, 13 Apr 2014 04:17:49 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD032.mail.protection.outlook.com (10.173.160.73) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Sun, 13 Apr 2014 04:17:49 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.232]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0174.002; Sun, 13 Apr 2014 04:17:30 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Chuck Mortimore <cmortimore@salesforce.com>
Thread-Topic: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
Thread-Index: Ac9OJMm2QQWqL+riTTewCyU8ts655AIkJjcAAATakwAAAEqKgAABT95w
Date: Sun, 13 Apr 2014 04:17:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439A15609B@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn_LBojNz+LCTTQN62P_U7Rag0rot715c7XCOcXAQJmEhA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A155FFB@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn-Dto7ySgNgMu5rkqyzfok1BWdS7WxB18ep+Uv0sFRsuw@mail.gmail.com>
In-Reply-To: <CA+wnMn-Dto7ySgNgMu5rkqyzfok1BWdS7WxB18ep+Uv0sFRsuw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A15609BTK5EX14MBXC286r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(24454002)(189002)(199002)(377454003)(33656001)(92566001)(19300405004)(86362001)(92726001)(15202345003)(2009001)(86612001)(46102001)(85852003)(83072002)(80976001)(2656002)(66066001)(512954002)(87936001)(99396002)(76482001)(55846006)(80022001)(97736001)(77982001)(83322001)(4396001)(20776003)(19580395003)(19580405001)(79102001)(16236675002)(6806004)(81342001)(74502001)(50986999)(84326002)(71186001)(44976005)(54356999)(15975445006)(76176999)(84676001)(74662001)(85806002)(81542001)(31966008)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB026; H:mail.microsoft.com; FPR:CE40D11E.9E3A52D9.B3D3BD49.4CF0F471.2039E; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 018093A9B5
Received-SPF: Pass (: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YZAp7igB1zlwsKm77MkA7ixoxLg
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 13 Apr 2014 04:17:57 -0000

Can you sketch out what data structures you'd ideally use for your scenario and what the elements mean?

From: Chuck Mortimore [mailto:cmortimore@salesforce.com]
Sent: Saturday, April 12, 2014 8:39 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Not sure it it's common yet.   The scenario I'm exploring is a client that is paired with a server.     For example, a mobile app that's an OpenID Connect client that is sharing it's ID Token with the server.   Both the client and server want to be able to prove possession without sharing a private key.

-cmort

On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
Is having multiple confirmation keys a common case?  I'd rather we "make simple things simple" than build the most general solution possible.  If an application really needs multiple confirmation keys, it can always defined a "jwks" element and the handling rules for it, and go for it...

                                                            -- Mike

From: Chuck Mortimore [mailto:cmortimore@salesforce.com<mailto:cmortimore@salesforce.com>]
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones

Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Good start here Mike!

One quick question - I see the "cnf" member is defined as a JWK.  Why not a JWK Set?    I could see use-cases for binding in multiple keys.

-cmort



On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
I've written a concise Internet-Draft on proof-of-possession for JWTs with John Bradley and Hannes Tschofenig.  Quoting from the abstract:

This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key.

This specification intentionally does not specify the means of communicating the proof-of-possession JWT, nor the messages used to exercise the proof key, as these are necessarily application-specific.  Rather, this specification defines a proof-of-possession JWT data structure to be used by other specifications that do define those things.

The specification is available at:

*        http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00

An HTML formatted version is available at:

*        http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.html

                                                            -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1210 and as @selfissued.


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

v2.23.0 | Report a Bug | By Email