Subject: [OAUTH-WG] Question regarding RFC 7592

From: Robache Hervé <[email-masked]>
Date: Fri, 13 Sep 2019 05:37:04 +0000

Hi

RFC 7592 introduces a « Registration Access Token ». Are this token and the way to get it similar to what is specified as “Initial Access Token” in RFC 7591/Appendix A ?

If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be extrapolated to RFC7592 as the same way?

Thanks in advance for your clarification.

Hervé ROBACHE
Direction Marketing et Développement

LIGNE DIRECTE
T. +33(0)1 55 23 55 45
[email-masked]<mailto:[email-masked]>

STET (SIEGE SOCIAL)
100, Esplanade du Général de Gaulle
Cœur Défense – Tour B
92932 La Défense cedex

www.stet.eu<http://www.stet.eu/>

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: Fri, 13 Sep 2019 13:29:53 +0200

No. The initial access token is issued by the AS when registration is
protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method
and means by which this is obtained can vary. The registration access token
in RFC 7592 is used to protect the registration management API and allow
updates to the client after it is registered. You might have one (the
registration access token) but not the other (initial access token) when
open registration is allowed (appendix 1.1 in RFC 7591).

HTH!

On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé <[email-masked]> wrote:

> Hi
>
>
>
> RFC 7592 introduces a « Registration Access Token ». Are this token and
> the way to get it similar to what is specified as “Initial Access Token” in
> RFC 7591/Appendix A ?
>
>
>
> [email-masked]
> www.stet.eu
> 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é.
> 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.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Robache Hervé <[email-masked]>
Date: Fri, 13 Sep 2019 12:23:30 +0000

Thanks Travis

I understand that, once the client has retrieved its [client_id] through RFC7591 initial registration, it is then able to ask for an access token that will be used for accessing the RFC7592 entry-points. Am I right?

Best regards

Hervé

De : Travis Spencer [mailto:[email-masked]]
Envoyé : ven. 13 13:30
À : Robache Hervé
Cc : [email-masked]
Objet : Re: [OAUTH-WG] Question regarding RFC 7592

No. The initial access token is issued by the AS when registration is protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method and means by which this is obtained can vary. The registration access token in RFC 7592 is used to protect the registration management API and allow updates to the client after it is registered. You might have one (the registration access token) but not the other (initial access token) when open registration is allowed (appendix 1.1 in RFC 7591).

HTH!

On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Hervé ROBACHE

LIGNE DIRECTE
T. +33(0)1 55 23 55 45

STET (SIEGE SOCIAL)

[email-masked]<mailto:[email-masked]>

---

From: Travis Spencer <[email-masked]>
Date: Fri, 13 Sep 2019 15:18:12 +0200

Ya, this part is confusing. I didn't get it at first either.

The response to registration using RFC 7591 (authenticated with an initial
token or not) typically includes a registration access token; 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 available at
https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse).
With this, the client can update its registration according to RFC 7592
(DCRM). When it does so, the AS will typically return a new registration
token with each reply. This update process is described in section 5 of
DCRM.

On Fri, Sep 13, 2019 at 2:23 PM Robache Hervé <[email-masked]> wrote:

> Thanks Travis
>
>
>
> I understand that, once the client has retrieved its [client_id] through
> RFC7591 initial registration, it is then able to ask for an access token
> that will be used for accessing the RFC7592 entry-points. Am I right?
>
>
>
> Best regards
>
>
>
> Hervé
>
>
>
> *De :* Travis Spencer [mailto:[email-masked]]
> *Envoyé :* ven. 13 13:30
> *À :* Robache Hervé
> *Cc :* [email-masked]
> *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 Sep 2019 19:08:10 +0000

Travis has this correct — the “registration access token” is passed to the client for the express purpose of accessing the client management API, and is not the same as, or entangled with, any access tokens that the client requests through the OAuth process after the registration has occurred. The reasons for this separation are many, but at the core it comes down to the client always acting on its own behalf when it does registration, and acting on behalf of some other party (usually a user) when it’s doing OAuth. Additionally, registration management is a function of the AS, whereas the protected APIs are a function of the RS — note this is a logical separation and there’s nothing stopping AS and RS functions from being deployed in any number of patterns.

A few common questions we got asked when writing this functionality into the spec:

Why use an access token at all? Because it’s a credential for a specific API issued by the AS and handed to the client in a programmatic manner. This is exactly what OAuth tokens were made for.

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.

Why not issue an authorization code? Because then the client would need to make yet another round trip, and not all clients are authorization-code-grant clients to begin with.

Why not make a new grant type? Because then the client would need to make yet another round trip, and we’d have to invent a whole new grant type with a new temporary credential when we could just use that temporary credential directly instead.

— Justin

On Sep 13, 2019, at 8:23 AM, Robache Hervé <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Travis

Best regards

Hervé

De : Travis Spencer [mailto:[email-masked]]
Envoyé : ven. 13 13:30
À : Robache Hervé
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [OAUTH-WG] Question regarding RFC 7592

HTH!

Hervé ROBACHE

LIGNE DIRECTE
T. +33(0)1 55 23 55 45

STET (SIEGE SOCIAL)

---

From: Dick Hardt <[email-masked]>
Date: Sat, 14 Sep 2019 22:05:16 -0700

Curious why the client management API uses bearer tokens rather than JWTs
per RFC 7523 for the client to authenticate. The client management API
seems more similar to a token endpoint than a resource.
ᐧ

On Fri, Sep 13, 2019 at 12:08 PM Justin Richer <[email-masked]> wrote:

> Travis has this correct — the “registration access token” is passed to the
> client for the express purpose of accessing the client management API, and
> is not the same as, or entangled with, any access tokens that the client
> requests through the OAuth process after the registration has occurred. The
> reasons for this separation are many, but at the core it comes down to the
> client always acting on its own behalf when it does registration, and
> acting on behalf of some other party (usually a user) when it’s doing
> OAuth. Additionally, registration management is a function of the AS,
> whereas the protected APIs are a function of the RS — note this is a
> logical separation and there’s nothing stopping AS and RS functions from
> being deployed in any number of patterns.
>
> *Why use an access token at all*? Because it’s a credential for a
> specific API issued by the AS and handed to the client in a programmatic
> manner. This is exactly what OAuth tokens were made for.
>
> *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.
>
> *Why not issue an authorization code*? Because then the client would need
> to make yet another round trip, and not all clients are
> authorization-code-grant clients to begin with.
>
> *Why not make a new grant type*? Because then the client would need to
> make yet another round trip, and we’d have to invent a whole new grant type
> with a new temporary credential when we could just use that temporary
> credential directly instead.
>
> — Justin
>
> On Sep 13, 2019, at 8:23 AM, Robache Hervé <[email-masked]> wrote:
>
> Thanks Travis
>
> *De :* Travis Spencer [mailto:[email-masked]
> <[email-masked]>]
> *Envoyé :* ven. 13 13:30
> *À :* Robache Hervé
> *Cc :* [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Sep 2019 02:36:28 +0000

I don’t see a reason to use an assertion here. JWT authentication would require at least a secret if not a key of some type for authentication for all clients, and it was determined that dynamic registration shouldn’t require the clients (even public clients) to support things they weren’t already capable of doing. Besides, the management endpoint isn’t a token endpoint (though I’m curious to hear why you’d say that) — it’s an API you can call to manage a client’s registration data over time. Sounds like an RS, if you ask me.

— Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Curious why the client management API uses bearer tokens rather than JWTs per RFC 7523 for the client to authenticate. The client management API seems more similar to a token endpoint than a resource.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=5c4bbc80-1f00-4351-9a9b-954805e3d560]ᐧ

On Fri, Sep 13, 2019 at 12:08 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Travis has this correct — the “registration access token” is passed to the client for the express purpose of accessing the client management API, and is not the same as, or entangled with, any access tokens that the client requests through the OAuth process after the registration has occurred. The reasons for this separation are many, but at the core it comes down to the client always acting on its own behalf when it does registration, and acting on behalf of some other party (usually a user) when it’s doing OAuth. Additionally, registration management is a function of the AS, whereas the protected APIs are a function of the RS — note this is a logical separation and there’s nothing stopping AS and RS functions from being deployed in any number of patterns.

— Justin

Thanks Travis

Best regards

Hervé

HTH!

Hervé ROBACHE

LIGNE DIRECTE
T. +33(0)1 55 23 55 45

STET (SIEGE SOCIAL)

---

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Sep 2019 21:40:04 -0700

The registration supports the client having a jwks, so if the client
provides jwks, then using them to sign an authentication request seems
easier than trying to manage an access token.

The token endpoint is an API as well. We would agree that it is not a
resource, but a management API. Similarly, I see the client's management of
its registration to not be a resource operation, but a management API.
ᐧ

On Mon, Sep 16, 2019 at 7:36 PM Justin Richer <[email-masked]> wrote:

> I don’t see a reason to use an assertion here. JWT authentication would
> require at least a secret if not a key of some type for authentication for
> all clients, and it was determined that dynamic registration shouldn’t
> require the clients (even public clients) to support things they weren’t
> already capable of doing. Besides, the management endpoint isn’t a token
> endpoint (though I’m curious to hear why you’d say that) — it’s an API you
> can call to manage a client’s registration data over time. Sounds like an
> RS, if you ask me.
>
> — Justin
>
> On Sep 15, 2019, at 1:05 AM, Dick Hardt <[email-masked]> wrote:
>
>> Travis has this correct — the “registration access token” is passed to
>> the client for the express purpose of accessing the client management API,
>> and is not the same as, or entangled with, any access tokens that the
>> client requests through the OAuth process after the registration has
>> occurred. The reasons for this separation are many, but at the core it
>> comes down to the client always acting on its own behalf when it does
>> registration, and acting on behalf of some other party (usually a user)
>> when it’s doing OAuth. Additionally, registration management is a function
>> of the AS, whereas the protected APIs are a function of the RS — note this
>> is a logical separation and there’s nothing stopping AS and RS functions
>> from being deployed in any number of patterns.
>>
>> *Why not issue an authorization code*? Because then the client would
>> need to make yet another round trip, and not all clients are
>> 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.
>> 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.

---

From: Neil Madden <[email-masked]>
Date: Tue, 17 Sep 2019 07:11:05 +0100

The choice of using an access token here did provoke quite a lot of questions from developers. Does the token have a scope? Who is the resource owner - the client itself? Can the token be introspected? Revoked? Exchanged? Can it have PoP/sender-constrained restrictions?

That said, I think it makes sense to use an access token here, especially if there is a different party doing registration and management on behalf of the client. That party can retain the RAT without needing to impersonate the client. 

— Neil

> On 17 Sep 2019, at 03:36, Justin Richer <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Sep 2019 15:09:48 +0000

I think this is where we disagree about the nature of “resource”, as I would classify a management API as a resource. Specifically, the client’s own records at the AS.

The “IF” in your statement is a big if, and one that is uncommon even today. Also, I want to note that if the client can’t "manage an access token” very well, then it’s going to have a very hard time being an OAuth client once it’s done registering. In other words, the goal was to take a piece of universal functionality that all OAuth clients would be guaranteed to have.

I’ll agree that it’s a bit weird having an access token issued as part of a response, but the alternative was to invent a new flow to force a client to go through another round trip to the token endpoint to get its management token. If you’re already directly giving the client a temporary credential that it can use at the AS, then just give the client the final token to do the job directly instead. At least, that was the thinking, and I still agree with that line of thought today even with its quirks.

— Justin

On Sep 17, 2019, at 12:40 AM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

The registration supports the client having a jwks, so if the client provides jwks, then using them to sign an authentication request seems easier than trying to manage an access token.

The token endpoint is an API as well. We would agree that it is not a resource, but a management API. Similarly, I see the client's management of its registration to not be a resource operation, but a management API.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=2f153226-16c8-47cf-917d-a04714e9a474]ᐧ

On Mon, Sep 16, 2019 at 7:36 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I don’t see a reason to use an assertion here. JWT authentication would require at least a secret if not a key of some type for authentication for all clients, and it was determined that dynamic registration shouldn’t require the clients (even public clients) to support things they weren’t already capable of doing. Besides, the management endpoint isn’t a token endpoint (though I’m curious to hear why you’d say that) — it’s an API you can call to manage a client’s registration data over time. Sounds like an RS, if you ask me.

— Justin

— Justin

Thanks Travis

Best regards

Hervé

HTH!

Hervé ROBACHE

LIGNE DIRECTE
T. +33(0)1 55 23 55 45

STET (SIEGE SOCIAL)

---

From: Travis Spencer <[email-masked]>
Date: Wed, 18 Sep 2019 10:56:21 +0200

> 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.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Sep 2019 07:24:15 -0700

I think of cloud infrastructure having control plane, and data plane.
Control plane APIs are for managing the things that use the data plane. The
data plane is the resource. Not trying to change your mind, just sharing my
thinking.

On related efforts, in FastFed, we are looking at using a JWT to access
other control plane APIs.

I agree on first take, that storing an access token is easier than
working with a key pair. I should have more context, which is managing the
credential life cycle. What happens if the access token is lost or
compromised? Does the app need to be completely re-registered? With a
jwks-uri, the client can rotate their keys and continue to make API calls
if the private key is lost or compromised.

ᐧ

On Tue, Sep 17, 2019 at 8:10 AM Justin Richer <[email-masked]> wrote:

> I think this is where we disagree about the nature of “resource”, as I
> would classify a management API as a resource. Specifically, the client’s
> own records at the AS.
>
> The “IF” in your statement is a big if, and one that is uncommon even
> today. Also, I want to note that if the client can’t "manage an access
> token” very well, then it’s going to have a very hard time being an OAuth
> client once it’s done registering. In other words, the goal was to take a
> piece of universal functionality that all OAuth clients would be guaranteed
> to have.
>
> I’ll agree that it’s a bit weird having an access token issued as part of
> a response, but the alternative was to invent a new flow to force a client
> to go through another round trip to the token endpoint to get its
> management token. If you’re already directly giving the client a temporary
> credential that it can use at the AS, then just give the client the final
> token to do the job directly instead. At least, that was the thinking, and
> I still agree with that line of thought today even with its quirks.
>
> — Justin
>
> On Sep 17, 2019, at 12:40 AM, Dick Hardt <[email-masked]> wrote:
>