[WG-UMA] Improving the rreg spec
Eve Maler
http://mrtopf.clprojects.net/uma/draft-uma-resource-reg.html
Please let me know if you have any further comments. The first issue below for section 6, in particular, needs some discussion. (SMART project folks, if you have additional rreg comments based on your implementation efforts, now is a great time to share them.)
1.3 Requirements Analysis:
- Based on our conversations of the last couple of weeks, I can see that requirements are slightly over-specified in terms of dictating a design solution for scoped access tokens. Here's how the wording can be softened:
. Bullet 6: Change "The host needs to be able to validate that a requester's access attempt in step 3, accompanied by an access token, matches the resource set and action set for which that access token was granted." to "The host needs to be able to validate that a requester's access attempt in step 3, accompanied by an access token, matches a resource set and action associated with that access token."
. Bullet 7: Change "The AM therefore needs to associate each requester access token with a resource set and action set." to "The AM therefore needs to make an association between requester access tokens and resource sets/actions."
4. Action Description:
- Nit: Change "(vs. creating them or edit them in some fashion)" to "(vs. creating them or editing them in some fashion)".
5. Resource Set Description:
- Nit: Indenting in the example is inconsistent.
- Should the definition of the {resourcesetid} point explicitly to section 6 where the privacy and uniqueness implications of this ID as a URI path component are discussed? What's the right way to divide spec details between sections 5 and 6 when it comes to this ID? (Note that TODO item #1 relates to this spec text.)
- Do we have to say anything about what the AM should/could do if it can't successfully retrieve action descriptions, or can we rely on this being an HTTP-level problem that leaves AMs able to handle the situation in whatever UX way they want?
6. Resource Registration API:
- By making a simplifying assumption that the {hostid} has to be the host's client ID, we're eliminating "anonymous" client credentials as an option. This seems unfortunate. Is there a "cheap" option for picking some other hostid that's guaranteed to be unique, without requiring the AM to send something to the host previously that amounts to a unique assigned ID? Can we use domain name, or does that have too much variability? Of course, the host's access token uniquely distinguishes it, but the token is exchanged out of band wrt URI path components. (Note that TODO item #4 relates to this spec text.)
- Should we say somewhere explicitly that the AM is REQUIRED to support all five methods listed? We imply it but don't say it.
- Change "The AM MUST respond to host requests using HTTP methods other than those listed" to "The AM MUST respond to host requests using unsupported HTTP methods".
Other TODOs:
- Can I interest someone (Paul Bryan?) in proposing what a list of resourcesetid's should look like in section 6.5? TODO item #5 is about this.
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma