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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 4 Jun 2013 12:06:32 +0000

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: [email-masked]'
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.

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Jun 2013 11:59:47 -0400

> name then it might be more intuitive for the reader since the current wording is a bit fuzzy.
"Initial Access Token" is a name added in the latest draft to call it 
out as a separate object. I'd be happy to have a better name for it, but 
> developer later in the text.
This is because it might not refer to the developer at all. In practice, 
we've seen it tied to a developer, but it could be tied to an 
enterprise's application publishing system or any number of other 
things. At its root, it's an OAuth 2.0 access token that controls 
authorized access to the Client Registration Endpoint. However you want 
to get an OAuth 2.0 token is your own business and out of scope for the 
draft.

> credentials instead. Do I see this wrong?
Yes, you've got it wrong. The lifecycles and targets of these two items 
are different, as explained in the client tokens and credentials section 
(1.3). The registration access token is issued by the registration 
endpoint and used at the client information endpoint. The client 
credentials are issued by the registration endpoint and used at the 
token endpoint. The former is required, the latter is optional.

While it seems like you can just re-use the client credentials, this is 
only true if you have client credentials issued by the server, which 
isn't the case for public clients. There is still a use for public 
clients, though it's very true that clients that used to *have* to be 
public (such as native clients) can now register each instance on its 
own behalf using this protocol and they don't need to be public anymore. 
However, requiring public clients to have client credentials just to do 
registration doesn't make sense and is very difficult to implement. We 
know this because the OpenID Connect group *tried* to do this and it 
doesn't work. I would rather we learn from their well-documented mistake 
instead of trying to repeat it again.

> grant for the dynamic client registration?
The dynamic registration draft should support any and all authorization 
grants, why would it focus on just one? And the use case for a dynamic 
registration of an implicit grant is clear in the case where you have an 
implicit client talking to multiple authorization servers. It needs to 
get its client_id from each auth server in order to talk to them, 
otherwise you've got to come up with some other mechanism to publish an 
agreed-upon client_id for a public client across all auth servers. Why 
do that when you can just register at each one like you would with any 
other grant type?

> client_id, which is a random string. What is the end user supposed to use that information for?
It's a suggestion for consistent user experience at the authorization 
page and letting the developers of the applications on both ends know 
what a server might do with that particular field. If it's better for 
this to be non-normative, we can lowercase all of those.

> "Authorization Servers MUST accept or ignore all parameters on this list."?
That last bit's probably a wording problem, what I'm trying to say is 
that the server can't reject a message with one of the parameters on 
this list. This is for interoperability purposes -- you're allowed to at 
the very least send everything on this list to any server. Some servers 
can accept more, and some might require more and need to document that 
appropriately. If there's a better way to tie that together, let me know.

> Server. Same for Client, Developer, etc.

I was trying to use the terminology as defined and used in RFC6749. I 
can lowercase those.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth