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é <herve.roba...@stet.eu> 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:travis.spen...@curity.io] > *Envoyé :* ven. 13 13:30 > *À :* Robache Hervé > *Cc :* oauth@ietf.org > *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é <herve.roba...@stet.eu> > 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 > > herve.roba...@stet.eu > > > > > > > > > [image: cid:image003.png@01D14327.707582F0] > > > > 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 > OAuth@ietf.org > 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
