[OAUTH-WG] Implicit grant and sender constrained token/JPOP/DPOP

[Nat Sakimura <[e-mail]>]

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