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 protected]> 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 protected]> 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. >> ᐧ >> >>> On Fri, Sep 13, 2019 at 12:08 PM Justin Richer <[email protected]> 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. >>> >>> 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 protected]> 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 protected]] >>>> Envoyé : ven. 13 13:30 >>>> À : Robache Hervé >>>> Cc : [email protected] >>>> 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 protected]> >>>> 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 ? >>>> >>>> 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 protected] >>>> >>>> <image001.png> >>>> >>>> >>>> >>>> <image002.png> >>>> >>>> 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 >>>> >>>> >>>> >>>> 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. >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> 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. >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
