Hi Justin, background of my query is that we want to offer in our company the possibility of dynamic client registration. Unfortunately, the topic initial access token - how do I get it and how exactly it is constructed - is not exactly specified - it is out of scope. That is the reason why I searched in internet and found the scope "dcr" in curity documentation.
Central question in the moment: how does the user who want to register a client get the initial access token? My idea: We are using a protected client registration so the user first has to authenticate himself. In the authorization request, the scope "dcr" (or any other?) is transferred to the authorization server and as a result there is the initial access token for this user and this client. So, in my opinion, it is guaranteed that one gets the initial access token, which has also requested it. With the idea to use the software statement, I have to work more intensively. I had not seen that way before. Perhaps the initial access token can even be replaced by this. But also there is the question, how is it requested? Greetings Frank -----Ursprüngliche Nachricht----- Von: Justin Richer <jric...@mit.edu> Gesendet: Mittwoch, 15. Mai 2019 19:57 An: Sahler, Frank <frank.sah...@datev.de> Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol 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 ________________________________ 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 Internet: 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
