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

Mike Jones <> Sun, 13 April 2014 04:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E80451A01D3 for <>; Sat, 12 Apr 2014 21:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I_bebi-t9tv3 for <>; Sat, 12 Apr 2014 21:17:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A26011A01CD for <>; Sat, 12 Apr 2014 21:17:53 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.921.12; Sun, 13 Apr 2014 04:17:49 +0000
Received: from (2a01:111:f400:7c09::105) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Sun, 13 Apr 2014 04:17:49 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Sun, 13 Apr 2014 04:17:30 +0000
From: Mike Jones <>
To: Chuck Mortimore <>
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: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A15609BTK5EX14MBXC286r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; 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;; 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 designates as permitted sender) receiver=; client-ip=;;
Cc: "" <>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 []
Sent: Saturday, April 12, 2014 8:39 PM
To: Mike Jones
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.


On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <<>> 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 [<>]
Sent: Saturday, April 12, 2014 6:12 PM
To: Mike Jones

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.


On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones <<>> 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:


An HTML formatted version is available at:


                                                            -- Mike

P.S.  This note was also posted at and as @selfissued.

OAuth mailing list<>