...
We'll get together on the UMA scope etherpad and work on this.
• Should resource set descriptions list action identifiers, as currently specified, or full action description URLs?
Should we rename the parameter name of resource set descriptions to "resource_set"? Yes. We don't want people to equate it with an actual concrete resource.
We clearly need to add an Example section that walks through the matching-up of descriptions, IDs, PUTs, GETs, etc.
What if different hosts register similar "reading"-type actions called different things, or what if they're different but called the same thing? This is treated in a totally host-specific manner so far. Domenico's wireframes show how this could work. Eve brings up the example of FireEagle, which has several quite distinct "reading" actions/scopes.
What if we were to encourage the standardization of APIs and their actions by allowing descriptions to be provided by reference instead of by value? Of course, there's a lot of value add in proprietary APIs and that's okay. Let's make this a NEW issue.
- Flesh out the UMA-level error response section.
Sal notes that this is a specific example of a general category of "invalid request" error. This might be a better error message, possibly with some detail supplied about the host ID being wrong. Maciej notes that at the HTTP level, the right error is a 401: Unauthorized. Is this what we should use? We could add an UMA-specific header indicating the problem. Susan notes that the AM is probably going to want to audit events like this.
Separately, Alam wonders about the possibility of DOS attacks and other security issues when the host tells the requester in Step 2 which AM to go to. Maciej notes that the requester/client has to do some work to indicate that it is trying to interact on an OAuth/UMA basis in its request message, and only then does it learn the AM location. We've discussed this general issue before.
- Should the host hint at an appropriate action description to the requester, or since actions are supposed to be well-known should we leave it out?
Let's save this for the core spec portion of the discussion.
- Note that there are new security and privacy considerations sections.
Susan is our new "privacy czar" 
, and will be reviewing this material to see what improvements can be made.
Next Meetings
- WG telecon on Wednesday, 22 Dec 2010, at 9-10:30am PT (time chart)
- No meeting on Thursday, 30 Dec 2010
- WG telecon on Thursday, 6 Jan 2011, at 9-10:30am PT (time chart)