Subject: [OAUTH-WG] My earlier comments on the dyn client reg draft

From: Eve Maler <[email-masked]>
Date: Tue, 4 Dec 2012 09:25:46 -0800

Hannes suggested that, for transparency, I should share with the list the comments that I had earlier sent to Justin. Here they are. I believe these have all been addressed in one way or another by now.

	Eve

====

General

- Authorship: I suspect that Christian Scholz really won't mind if you move him to the acknowledgments. He actually had not that much to do with the original UMA-based draft, but was our official spec editor of the group at the time. (I wrote the bulk of the requirements, and Maciej wrote the bulk of the request/response stuff.)

1. Introduction

- Para 2: s/meta information/metadata/ to match other references.

2.1. Client Association Request

- Could you make it a bit clearer that the parameters you list are actually defined in Section 3? I found this confusing at first.

2.2. Client Association Response (and following)

- Is it worthwhile defining a media type application/json+something for the various JSON-encoded responses defined in the doc? I'm not sure if the OAuth spec has been going to this trouble. The UMA spec does -- which means that eventually we'll have to submit to IANA for registering those types...

- client_secret:
 s/us used/is used/
 s/not required/OPTIONAL/ ?

- registration_access_token: Is there any reason not to call this simple "access_token"?

2.3. Client Update Request

- Para 1: Why is the empty-value interpretation a SHOULD rather than a MUST? It would seem that we'd want interoperability in how to replace/wipe metadata.

2.4. Client Update Response (and following)

- For client_id in responses, does it make sense to say something like "A unique Client Identifier matching the one in the request"?

2.5. Rotate Secret Request

- Having it be an error if the client never originally had a secret, and the question about rotating the access token, makes me think that we should keep things as simple as possible, and make this operation be something like "client_refresh", which always refreshes the access token and -- if it was issued a secret -- the secret as well? There's sort of a recursiveness to managing meta-secrets used to issue client identities, and the last thing we want is to embed a full-blown OAuth mechanism that makes it token turtles all the way down...

2.7. Client Registration Error Response

- Trying to think of additional error conditions: invalid ID? Invalid token? These don't seem covered by the existing options. Of course, it's possible this detail shouldn't be exposed in the error response for security reasons.

3. Client Metadata

- In "token_endpoint_auth_method": Is "unspecified or omitted" redundant? What's the difference?

5. Security Considerations

- I assume that, eventually, the RP/IdP language from the OpenID Connect draft will need to be genericized.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 04 Dec 2012 22:24:17 +0000

We are working with one of our users on the support for pre-authorized 
tokens which can be checked by AS at the initial end user redirection to 
this AS before requesting the end-user authorization.

My assumption is that if the pre-authorized token exists then the client 
provided scope, if any, is basically ignored, because the end user has 
already pre-authorized a given client with a specific token which will 
have a scope set as requested by the end user at the pre-authorization time.

Is that right ? IMHO yes and the best AS can do in this case is simply 
log what scope the client is actually requesting but reply with the 
token containing the pre-authorized scope, please correct me if not

thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 05 Dec 2012 16:03:01 +0000

> token containing the pre-authorized scope, please correct me if not

We've decided to treat this case similarly to the client-driven 
down-scoping request with the help of the refresh grant...