UMA telecon 2010-12-16

Date and Time

• WG telecon on Thursday, 16 Dec 2010, at 9-10:30am PT (time chart)
  • Skype line "C": +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

• Roll call
• Approve minutes of 2010-12-09 meeting
  • Upcoming meetings: special UMA WG telecon on Wednesday rather than Thursday; no meeting Dec 30; first meeting of 2011 is Jan 6
• Action item review
• UMA validation bounty program: award decision time
• JSON token status (George) and implications for trusted claims
  • Refer to etherpad and trusted claims proposal 08b
• Resource reg spec revisions
  • Review TODO/issues list
• Review conformance testing questions
• AOB

Attendees

As of 16 Nov 2010 (pre-meeting), quorum is 8 of 15.

...

• Kevin Cox
• Cordny Nederkoorn (latter half)
• Anna (staff)

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2010-12-09 meeting

Minutes of 2010-12-09 meeting APPROVED.

Note: Upcoming meetings: special UMA WG telecon on Wednesday rather than Thursday; no meeting Dec 30; first meeting of 2011 is Jan 6.

UMA validation bounty program: award decision time

Sal, Susan, Maciej, and Eve had an offline discussion. Sal believes the hData use case is more directly useful than having a conformance test suite, but they could also be used in concert. Eve believes they're both valuable in different and complementary ways. Cordny's original indication of submission interest estimated the work at 40-50 hours.

...

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)