Re: [OAUTH-WG] PoP Key Distribution

John Bradley <> Mon, 15 February 2016 01:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD02F1A87E7 for <>; Sun, 14 Feb 2016 17:32:12 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MLww6w7-F9Ae for <>; Sun, 14 Feb 2016 17:32:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 720261A8776 for <>; Sun, 14 Feb 2016 17:32:10 -0800 (PST)
Received: by with SMTP id s5so50863928qkd.0 for <>; Sun, 14 Feb 2016 17:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4RFiFnW5Hk4/qsQwemcfLrLgYgAs7QxdEMZEV2JbrJY=; b=tSxICT6aZMd9rGaqW4YtZ+ztKbMSq6uh7LFkPp1xfPiSBhBN6yta2kN+fSzrsIkR2N F+wOFXLLz39RuU3zNJeXQt22nzHrKbzK5ISfp6PutUdkm99Iqt96t5AMZvfDA5IzsQI9 5AKtsxY3vciHRHwfCQW1JJpcDqHWZcU1R/lHA4BJhAl4mXnQcIVKrbdSvzFJuC+6K1MB zHdEhn9S28mkbOApPtX7jLWqoBIeNyQ3fWGy9ELi24eAdSXOSky8zV8xiQqgMh30E9JS kYWE5X68apKYPjVSETfkFPM/Vd9OiTriMVoZHlKLfKm7qlT4Z0oA1T2xJbIoYEFlCZxS JnVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4RFiFnW5Hk4/qsQwemcfLrLgYgAs7QxdEMZEV2JbrJY=; b=X+07Lu5TwtwqG8Kzt4c53mvs/06+0Qpkb4ngu1qDFrSZacetGrGiU1GIAlU0lOerPc udXfUr4oA3i9RG1z/EDUl2MarZO7HV1b/nfh+I9Bl7u84kUe/XlJnF1OCCm18JT+tkIZ TGhaKRag8HnDJMyDhUVQtV/N7Lu6EVjFD+7RhYdGhLLnhUDC4lRrs4FEnF86HluQq6/J Rlb+FPzvvOAgOvSYD1fBLpORfb0Il7EIOyxN9fiTeGzVKVtah8orXsY2RWStp/gHoLVU 7GTQy0cZ4I+p7puj8EgIymZQMe66WMoszKwYFOHXRtBAKt6TRmfJ3qQ5BBjjq49qKGyg RJYQ==
X-Gm-Message-State: AG10YOSyskfvhAJDOARKp46RUj0fcUkfqD2bgW7CnRWOyXHP724cfg+SQuMd/YGyDzExwA==
X-Received: by with SMTP id w65mr17073216qka.68.1455499929507; Sun, 14 Feb 2016 17:32:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 200sm10143017qhm.47.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Feb 2016 17:32:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2D24771F-A9B8-4B03-9A46-5373477C9556"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Sun, 14 Feb 2016 22:32:04 -0300
Message-Id: <>
References: <>
To: Justin Richer <jricher@MIT.EDU>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] PoP Key Distribution
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: Mon, 15 Feb 2016 01:32:13 -0000

> On Feb 14, 2016, at 3:29 PM, Justin Richer <jricher@MIT.EDU> wrote:
> In PoP Key Distribution, I’m trying to figure out the full set of expectations that the client and AS will need to handle across different systems. From what I gather, we’ve got at least these:
> Client provides public key:
> 	- Client stores keypair
> 	- Server stores public key
> 	- Server returns public key
> 	- Client makes sure the public key matches the request (?)
Yes, sort of the public key is not returned to the client.   It is embedded in the cnf element of the AT if it is a JWT .  See sec 5.2

> Client provides shared key:
> 	- Client stores shared key
> 	- Server stores shared key
> 	- Server returns shared key
> 	- Client makes sure the shared key matches (?)
We did not so this one based on the assertion by some that the random number generation on the mobile device is not good so it is better to have it generated by the server.
We have talked about having the client provide some entropy, but don’t know if the complexity is worth it.

> Server provides public key:
> 	- Server generates keypair
> 	- Server stores public key (and promises to not store the private key?)
> 	- Server returns the keypair
> 	- Client stores the keypair
> Server provides shared key:
> 	- Server generates shared key
> 	- Server stores shared key
> 	- Server returns shared key
> 	- Client stores shared key
> First, I think it would be helpful to have this all laid out in the document. Second, a few of these are confusingly non-parallel. If the client sends the key, the server returns the public key. If the client doesn’t send the key, the server returns the keypair (public and private together). It makes sense why the responses are different, but it’s strange to me that we’re asking client developers to expect different things in the same field. 

We are missing an example of the asymmetric response where the AS provides the key.

The value of the key parameter is always a JWK,  You don’t get it back in the response if you send it in the request.

I will note looking at Sec 5.1 the text about using a thumbprint is wrong.  That was broken in the JWK thumbprint spec because the parameter to say it is a thumbprint was removed from the spec (I argued for keeping it for this use case but some people wanted the thumbprint to just be a way to calculate a keyid. )  We need to remove the text or add a cnf parameter to show it is a JWK thumb print.

So it should always be a JWK in the key field in a response if it is present.   If that is unclear it needs fixing.

> And then we have error conditions. What happens if the client provides a key but the server rejects that key and creates its own to send to the client? Does the client need to accept this key instead of its own? What if the client sends a shared key and the server returns a keypair? Should the server accept the same key from the client for multiple token requests? I think all of these conditions (and likely a lot more) will need to be covered in the document before it can be really useful for implementors.

Good point I would argue that the server should return an error if the client sends a key that it is not supposed to, and not return a key.   That should be clarified.

> The document has a few other editorial and technical problems, like describing the access_token field as a JWT with an encoded key. That’s one of the options for the access token, but hardly the only. It’s fine if it’s used in one of the examples, but we shouldn’t confuse people that they need to use encrypted key wrapping for PoP to work.

> Additionally, the use of the “audience” parameter is tied up with key management. The use is really pretty separate, since depending on my setup I can manage the keys just fine without an audience parameter, or require an audience parameter with no key management. It’s really the same problem that we have with Bearer tokens today: how does the RS get the info it needs about the token? Audience parameters help with that but aren’t required for functionality. To me this actually begs a larger question of how scopes get overloaded in OAuth 2. I proposed a while back that we look at three categories of scope-like things sent in parallel: time-based things (token lifetime, do I get a refresh token, etc), target based things (audience, resource), and access based things (the kind of stuff that we thought scope was for in the first place, read/write/delete/etc.). This is all for targeting the token and not tied to PoP itself.
The relationship between audience and pop is that for symmetric keys you need to know what key to use to encrypt to the RS and that requires knowing the RS.

That was why we put Audience in this spec , as we didn’t have it any place else even though it is in use in the wild in some cases. 

We probably should move it to it’s own spec  along with any other useful parameters.

We do sort of have a tension between the client knowing where the resource is and asking for a token type based on the pop presentment and alg based on alg support, and a view that it is the RS that is going to tell the client where it is going to use the token based on scopes (Nat’s link relationship takes the later view more or less) 

We are pushing a lot of complexity into the client to have knowledge of all the endpoints and configure itself/ask for the correct thing.

One alternative might be to have the client register the presentment mechanisms, algs and public keys it supports as part of client registration and have the server just provide all the correct info based on the resource.  That is different from this spec but might be worth considering if this is too complicated for client developers.

John B.

> — Justin
> _______________________________________________
> OAuth mailing list