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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
