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

"Manger, James" <> Wed, 02 April 2014 05:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F35951A0138 for <>; Tue, 1 Apr 2014 22:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SdDFaooWRwrN for <>; Tue, 1 Apr 2014 22:50:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E02401A0137 for <>; Tue, 1 Apr 2014 22:50:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,778,1389704400"; d="scan'208";a="5210449"
Received: from unknown (HELO ([]) by with ESMTP; 02 Apr 2014 16:42:40 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7395"; a="206238874"
Received: from ([]) by with ESMTP; 02 Apr 2014 16:50:23 +1100
Received: from ([]) by ([]) with mapi; Wed, 2 Apr 2014 16:50:23 +1100
From: "Manger, James" <>
To: "" <>
Date: Wed, 2 Apr 2014 16:50:22 +1100
Thread-Topic: Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
Thread-Index: Ac9OJMm2QQWqL+riTTewCyU8ts655AABhU1A
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 02 Apr 2014 05:50:32 -0000


A new registry for "cnf" members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date "exp" alongside claims such as "given_name". This spec starts introducing structure by wrapping members in a "cnf" (confirmation) object. It is not clear to me which new things would go in "cnf" versus going in to the top-level of the JWT claim set. Both locations have a "MUST ignore" policy for unrecognized members.

   "(In some applications, the subject identifier will be relative
   to the issuer identified by the "iss" (issuer) claim.)"

This isn’t very helpful as it gives no hint about when this is or isn’t the case. I guess this is just rewording a flaw from JWT.

Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren’t we going to include "kid" is almost all the examples in JWE?]

You may as well drop the "cty":"jwk+json" member as this is implied by the JOSE message being the value of a "jwk" member.

OpenID Connect has already defined a "sub_jwk" field that performs a similar role to "cnf":{"jwk"}.

Perhaps the biggest security consideration is missing: "cnf" may be ignored. A recipient that doesn't understanding "cnf" is likely to accept a JWT as a bearer token without doing any proof-of-possession.

James Manger