[OAUTH-WG] FW: Review of the Dynamic Registration Draft

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Re-send: my earlier mail seems to have gotten lost. 

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) 
Sent: Tuesday, June 04, 2013 2:21 PM
To: '[e-mail]'
Subject: Review of the Dynamic Registration Draft

Dear draft authors, Dear working group,

I read through the dynamic registration draft and here a few observations I have made: 

* The 'Initial Access Token' is really more a developer identifier. If you give it a different 
name then it might be more intuitive for the reader since the current wording is a bit fuzzy. 

For example, in Section 1.3 you only hint to the fact that this identifier refers to the 
developer later in the text. 

* From the description I have problems understanding the value of the "Registration Access Token". 
I believe you can accomplish exactly the same security benefits if you just use the client 
credentials instead. Do I see this wrong? 

* OAuth 2.0 supports a number of authorization grants and I have assumed that the dynamic 
client registration would focus on the authorization code grant. To my surprise the 
implicit grant also seems to be supported. The implicit grant has weak security properties 
and it's usage should actually be discouraged. Why would you want to support the implicit 
grant for the dynamic client registration? 

* There is a lot of RFC 2119 language in the document but it is used in a way that does not 
relate to protocol interoperability. Every time you write SHOULD or MAY think about whether 
a developer could write some useful code. Just to give you an example: 

"
   client_name
      Human-readable name of the Client to be presented to the user.  If
      omitted, the Authorization Server MAY display the raw "client_id"
      value to the user instead.
"

First, in this sentence what is presented to the user isn't really part of protocol interoperability. 
So, I wouldn't use RFC 2119 language here. What is necessary for protocol interoperability is whether 
the field is optional/mandatory to send by the client-side, and optional/mandatory to understand on 
the server-side. Additionally, do you think that an end user will likely see a lot of meaning in the 
client_id, which is a random string. What is the end user supposed to use that information for? 

Another example: 
"
   Extensions and profiles of this specification MAY expand this list,
   but Authorization Servers MUST accept or ignore all parameters on
   this list.  The Authorization Server MUST ignore any additional
   parameters sent by the Client that it does not understand.
"

In the first sentence you don't want to use RFC 2119 language either. If there are ways to extend the 
functionality via registries then point to the sections that explain how to extend it. The next two 
sentences are confusing. It seems that you want to have any additional parameter to be purely optional 
for the authorization server to understand. That's fine but what does this sentence then mean: 
"Authorization Servers MUST accept or ignore all parameters on this list."?

* An editorial issue: There is an excessive usage of capitalization in the document. If you look 
at previously published RFCs in the OAuth working group you will noticed that the RFC editor 
changes those to lower-case. For example, just use authorization server instead of Authorization 
Server. Same for Client, Developer, etc.

Ciao
Hannes

PS: I obviously noticed that the WGLC had trigger some discussion. In some sense that's good since this 
is what WGLCs are for. On the other hand it would be good to reach an agreement on the open issues.