A while ago, when implicit was almost entirely banned in the Security BCP, I raised voice that the ban should be constrained and the text was modified accordingly.
At the time, I probably did not express myself well enough so here is a bit of explanation on what I was thinking about the sender constraining the token. 1. Assumption: The client is a confidential client on a web server. 2. The Client registration is done either through the Developer portal at the AuthZ server or through RFC7591 in which jwks_uri is given. 3. When the client asks for the access token through implicit grant, the AS mints the client_id constrained access token or key constrained access token as in [JPOP] draft and send it back to the client. 4. The client exercises the token against the resource as in [JPOP]. Client ID based JPOP access token works better when the client keys are being refreshed quicker than the expiry of the access token. In the case of DPOP, the key is being specified during the token request, as I understand, so it does not work with implicit grant. When it comes to using the token, the [JPOP] draft only signs over a server created nonce (which can be tied to the URI and the method that the client was trying to access) while [DPOP] signs over client created nonce `jti` together with methods, uri, etc. [JPOP] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05 [DPOP] https://tools.ietf.org/html/draft-fett-oauth-dpop-02 my 2c. Cheers, Nat Sakimura -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
