Looking at the text I noticed that.Sec 4.2 has an example that contains a JWE as a key but a comment that the remainder of the plain JWK is omitted.
That should probably be JWE. We should probably also have an example with the jwk object inline. One thing I think we have as a gap is that public clients have no real protection for the refresh token. Anyone intercepting any call to the token endpoint for a new AT will get the RT and be able to get new POP keys for the AT. We don't currently have any examples in the spec of getting a key based on a RT but it is required if you are using symmetric keys with multiple RS. One thing that might work is to only provide a key to public clients with the authorization_code grant_type. That protects the RT from being used if it is leaked by the app. I think Chuck Mortimore suggested on the list that the public client could provide a public key as part of the initial Authz request, and that key would be used to encrypt the token keys to the client. That is probably the most secure but would cause spop (yes we will rename it) to intersect with pop key distribution. eg define a new code_challenge_method that sends a "jwk" as the code_challenge and a signed jwt to the token endpoint as the code_verifier. Then using the code_challenge public key to encrypt the per AT key. That would be an extension of spop if we want to do it. At the moment I think the pop story for public clients/native apps is a bit weak. If people give me feedback plus any other updates for the key distribution spec I will rev it over the next couple of days, as it needs to be refreshed to keep it active. John B.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
