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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to