[OAUTH-WG] PoP Key Distribution

[Justin Richer <[e-mail]>]

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 (?)

Client provides shared key:
	- Client stores shared key
	- Server stores shared key
	- Server returns shared key
	- Client makes sure the shared key matches (?)

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. 

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.

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.

 — Justin