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

Mike Jones <> Sun, 13 April 2014 03:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9EF2C1A000B for <>; Sat, 12 Apr 2014 20:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nvMEvtd3Exr2 for <>; Sat, 12 Apr 2014 20:33:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B54791A000F for <>; Sat, 12 Apr 2014 20:33:24 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.921.12; Sun, 13 Apr 2014 03:33:16 +0000
Received: from (2a01:111:f400:7c09::125) by (2a01:111:e400:c1b::26) with Microsoft SMTP Server (TLS) id 15.0.918.8 via Frontend Transport; Sun, 13 Apr 2014 03:33:16 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Sun, 13 Apr 2014 03:33:15 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Sun, 13 Apr 2014 03:32:53 +0000
From: Mike Jones <>
To: Chuck Mortimore <>
Thread-Topic: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
Thread-Index: Ac9OJMm2QQWqL+riTTewCyU8ts655AIkJjcAAATakwA=
Date: Sun, 13 Apr 2014 03:32:52 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439A155FFBTK5EX14MBXC286r_"
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)(377454003)(189002)(199002)(24454002)(77982001)(71186001)(81342001)(15975445006)(2009001)(86612001)(80976001)(19300405004)(4396001)(54356999)(92566001)(76176999)(76482001)(81542001)(16236675002)(83072002)(6806004)(19580395003)(86362001)(46102001)(15202345003)(66066001)(83322001)(19580405001)(44976005)(2656002)(80022001)(84676001)(74502001)(87936001)(55846006)(79102001)(92726001)(20776003)(97736001)(33656001)(512954002)(85852003)(84326002)(85806002)(74662001)(50986999)(31966008)(99396002)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB017;; FPR:CC40D19E.9E3A46D9.B3D3BD49.4CF0F471.20311; 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 03:33:27 -0000

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<>