Page Comparison

...

• 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

1. TBS

Minutes

TBS

Next Meetings

...

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

1. Adams, Trent
2. Alam, Mohammed
3. Catalano, Domenico
4. D'Agostino, Salvatore
5. Fletcher, George
6. Hardjono, Thomas
7. Machulak, Maciej
8. Maler, Eve
9. Moren, Lukasz
10. Morrow, Susan

Non-voting participants:

• 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.

MOTION: Sal moves, and Thomas seconds: The bounty award should be split $2500/$1500 to Cordny and hData, and in the event that hData can't accept the award, the WG requests of Kantara that $1500 be allocated towards developing a validator in 2011. Carried by unanimous consent.

JSON token status (George) and implications for trusted claims

The latest draft is here; a new one is expected soon. The expectation is that a token will have an envelope, a claims segment (a "body"), and a signature. The body doesn't actually have to be a JSON object; at the IIW meeting, it was agreed that a JSON form would be standardized but other forms could be used. The signature is over both the envelope and the body, because the envelope is extensible. Nat has done some work around accommodating multiple signatures, and that will be supported, though it's not currently documented. There's a proposal for how to add encryption to the token. Breno from Google demonstrated how the sign-first and encrypt-first patterns could solve different problems.

Thomas feels that the IIW discussion just replayed the old S/MIME discussion in a way, and he's concerned that the lessons previously learned may not be absorbed if there isn't enough overlap in the people having a discussion. This is something to keep an eye on.

How can UMA use all this stuff? Several places:

1. A JSON token could allow a host to validate a requester access token locally and not outsource that job to the AM in real time.

1. A JSON token could be used as a claim inside a claims document as we define it in the Claims 2.0 spec. If UMA defines a privileged set of claims, then it could namespace those claims.

1. A JSON token could be an UMA-protected resource, which plays into the trusted claims scenario.

For starters, let's look at the Claims 2.0 spec and see how it matches up. Sal, Eve, and George will think about this, and Eve will ping Paul on it as well.

Resource reg spec revisions

We reviewed the TODO section at the end.

• NEW issue: How should a RESTful API indicate that a particular method is unsupported? Do you get a particular error code?

Maybe 401 is appropriate. Eve will check with Paul about his preferences.

• Consider the question of i18n of resource set and action "name" strings in addition to the newly proposed extension-parameter mechanism.

We looked at the extension mechanism and it looks fine. We can wait on the i18n question until someone really needs it.

• Would implementers expect the "list all" methods to return just a list of IDs, or the whole set of structures? If so, do this through a query parameter? E.g., "?mode={short|verbose}"

The motivation to "list all" is mostly to help the host diagnose and remediate problems if the host suspects that it has gotten out of sync with the AM. The host could, of course, get all the IDs and then do a GET on all the suspicious ones. Maciej notes that actions will tend to be a small set, so it would seem more efficient to have the AM reply with the full descriptions by value. But would the same be true of resource sets? And what should the by-value returned object look like? He'll make a recommendation here.

• In the core spec, we have to say how a {resourceid} plus one or more {actionid}s gets used and flows around as normal OAuth scope information. Base64-encode a JSON representation? Extend to allow a resource parameter? Something else? (See the Requirements Analysis above for guiding requirements.)

We'll get together on the UMA scope etherpad and work on this.