Subject: Re: [OAUTH-WG] Question regarding RFC 7592

From: Robache Hervé <[email-masked]>
Date: Mon, 14 Oct 2019 09:09:54 +0000

Dear all

Thanks for your answers. I understand that RFC7592/§3 should be taken into account for enhancing the Client Information Response of RFC7591.

Best regards

Hervé

De : Travis Spencer [mailto:[email-masked]]
Envoyé : mercredi 18 septembre 2019 10:56
À : Robache Hervé
Cc : [email-masked]; Mark Dobrinic
Objet : [OAUTH-WG] Question regarding RFC 7592

On Fri, Sep 13, 2019 at 3:18 PM Travis Spencer <[email-masked]<mailto:[email-masked]>> wrote:
Ya, this part is confusing. I didn't get it at first either.

Seems I'm still a bit confused ;-)

this metadata isn't defined in RFC 7591 but discussed in section 1.3; that spec leaves the metadata out of scope. It is, however, profiled in section 3.2 of OIDC DCR (see registration_access_token in section 3.2

Mark Dobrinic pointed out to me this morning that RFC 7591 (DCR) is updated by 7592 (DCRM) in section 3 to include the same registration_access_token response metadata that OIDC defines.

Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci de le détruire ainsi que toute copie de votre système et d'en avertir immédiatement l'expéditeur.
Toute lecture non autorisée, toute utilisation de ce message qui n'est pas conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite.
L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique susceptible d'altération, STET décline toute responsabilité au titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou falsifié.
N'imprimez ce message que si nécessaire, pensez à l'environnement.

This message and any attachments is intended solely for the intended addressees and is confidential.
If you receive this message in error, or are not the intended recipient(s), please delete it and any copies from your systems and immediately notify the sender.
Any unauthorized view, use that does not comply with its purpose, dissemination or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may not be reliable, STET shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary, please consider the environment.

---

From: Travis Spencer <[email-masked]>
Date: Mon, 14 Oct 2019 13:01:44 +0200

On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt <[email-masked]> 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.