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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
