On the surface this is fine, but it hides an important detail: you need to have a client registered with the system in order to make a token request, meaning that the “dcr” token was issued to a different client than the one making the registration request. So that just means that the developer is going to have to copy it by hand into a configuration, or otherwise pass it to the instances at runtime.
Is it allowable? Sure, as the RFC doesn’t state (or care) how you got the initial access token for the registration request. Is it standard? Well, the “dcr” scope is specific to this company’s implementation, and it’s a little odd using an automated process to get a token for what will be an automated process. That basically leaves one instance of the application as the “primary” instance and everything else builds off of that. It’s more common to use a software statement, which also locks down a set of client attributes in a signed statement. In fact, in the original version of this part of the specification, which came from the BlueButton+REST project, the “software statement” and “initial access token” were one and the same. This working group decided that the functionality was better separated. — Justin On May 14, 2019, at 1:30 PM, Sahler, Frank <frank.sah...@datev.de<mailto:frank.sah...@datev.de>> wrote: Hello, I read in the dynamic client registration documentation of the company curity (https://developer.curity.io/tutorials/dynamic-client-registration-overview) that they use the scope "dcr" in the authorization request to get an initial access token i.e. a bearer token that only allows access to the registration endpoint. Is this also from your point of view a feasible way to initiate the client registration? Unfortunately the specification says nothing about how to get the token and how its purpose is limited to the registration endpoint. These two points are "out of scope for this specification". Regards Frank Sahler Security Consultant DATEV eG, Nuremberg, Germany ________________________________ Signatur Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit können Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie eine Meldung erhalten, dass die Signatur ungültig ist oder nicht geprüft werden kann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner. Informationen zu Zertifikaten und zur digitalen Signatur finden Sie unter https://www.datev.de/zertifikate im Internet. ________________________________ DATEV eG 90329 Nürnberg Telefon +49 911 319-0 E-Mail: i...@datev.de<mailto:i...@datev.de> Internet: https://www.datev.de<https://www.datev.de/> Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14 Registergericht Nürnberg, GenReg Nr. 70 Vorstand Dr. Robert Mayr (Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Julia Bangerth Prof. Dr. Peter Krug Diana Windmeißer Vorsitzender des Aufsichtsrates: Nicolas Hofmann _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
