Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol

[Phil Hunt <[e-mail]>]

We looked at giving clients a public client id they could use to perform an authorize with scope “dcr” to get an AT to be used as an IAT. 

While it works it seems like overkill. The main risk with the DCR endpoint is generating too many IDs ... a DoS issue primarily since having an ID is not authorization. 

Because of the perceived developer complexity and confusion over dealing with a public and confidential client id, my feeling was that software statements are sufficient. They provide a signed assertion the developer can pass in so the DCR can establish what the client claims to be registering as. This is enough to establish some access policy at the DCR endpoint. 

Phil

> On May 16, 2019, at 1:33 AM, Sahler, Frank <[e-mail]> wrote:
> 
> 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 <[e-mail]>
> Gesendet: Mittwoch, 15. Mai 2019 19:57
> An: Sahler, Frank <[e-mail]>
> Cc: [e-mail]
> 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 <[e-mail]<mailto:[e-mail]>> 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 [phone]
> 
> E-Mail: [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> 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 [phone]
> 
> E-Mail: [e-mail]
> 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
>