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
