Re: [OAUTH-WG] Question regarding RFC 7592

[Travis Spencer <[e-mail]>]

On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt <[e-mail]> wrote:
>
> What happens if the access token is lost or compromised? Does the app need to be completely re-registered?

Yes. Re-registration breaks many things though, so it's often not an
option. In these cases, the client is pretty much stuck with only bad
choices :-/

The token lifecycle of DCR(M) is one of the areas that would be great
to improve IMO. We originally had planned to always issue a dynamic
client a secret that it could use to get a DCRM scoped token using the
CC flow. We opted not to do that in the end because the client could
be using certs, for example, and a secret for management would lower
the security of the client. Using the credential (like a signed JWT
using an asymmetric key as you mention, Dick) could be a good way to
handle this. Perhaps RFC 7592 (DCRM) should be updated with some info
about allowing the client to use the CC flow with whatever credential
it registers with, just for the purpose of obtaining a new DCRM-scoped
registration management token.

Justin mentioned this though:

>  Why not use the client’s credentials? Because not all clients are set up to have credentials, plus we’d be spreading the requirement to support different kinds of client credentials to another endpoint.

IMO, the dynamic client should go to the token endpoint with whatever
credential it registered with using the CC flow and a scope of "dcrm".
So, the last concern about spreading the need to authenticate to other
endpoints would be moot. I'm not sure what to say about public
clients. ATM, in our product at least, we don't support public clients
registering, so this wouldn't pose an issue for us. Could for others I
suppose. Short of CC though, I can't think of a good way to get a new
registration management token.