Inline > On Feb 14, 2016, at 3:29 PM, Justin Richer <jric...@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 > Yes > Server provides shared key: > - Server generates shared key > - Server stores shared key > - Server returns shared key > - Client stores shared key > Yes > > 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. Agreed > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
