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

[Eve Maler <[e-mail]>]

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
[phone]                         http://www.twitter.com/xmlgrrl