As of 21 Apr 2011 (pre-mtg), quorum is 8 of 14.
Non-voting:
Regrets:
Quorum was reached.
Minutes of 2011-04-21 meeting APPROVED.
2010-11-18-4 Eve Open Capture new user stories in the wiki.
2011-03-02-1 Nat Open Put together JWT-compliant examples of Claims 2.0 and Simple Access Authorization Claims. Pending. Eve will reach out to Nat.
2011-04-07-2 Frank, Kirk Open Match constellations to scoped access diagrams to see what happens. Frank will do more work tonight.
2011-04-07-3 Thomas Open Turn the results of the ad hoc call on scoped access into core spec text. Thomas, Eve, and Maciej met and made some progress.
2011-04-14-1 Maciej, Alam Open Build list of FAQs (both questions and candidate answers) on the wiki. Alam has made some progress.
2011-04-21-1 Eve Open Update the scoped access proposal into I-D form for discussion. This will be in "slide form" first.
2011-04-21-2 Eve Open Revise the dynamic client registration spec again.
2011-04-21-3 Cordny Closed Look at scoped access flow for error conditions we've missed.
Blogging: The SMART team is planning three blog posts. Eve is planning to blog the scoped access ideas to start getting feedback.
Sessions and conveners: Maciej M. and Eve agreed to co-convene a "New Stuff in UMA" session. The SMART team will convene a couple of other sessions, including a demo/technical implementation session (Lukasz) and a UX session (Maciej W. will preview the SMART interface, their research, and the factors that made them change the interface).
"Assignments": The SMART team agrees to be assigned the task to collect FAQ. Maybe we can give an assignment to Cordy. In general, we should be prepared to compare notes during breaks and such. We should all keep our eyes and ears open for use cases and scenarios.
It turns out George will be there and Susan won't.
What should the "elevator pitch" be when we try to convey UMA's technical proposition? We seem to like "phases" and agreed to use this wording consistently in all our new materials:
Cordny made a few comments about error conditions in the 'pad. What is the right thing to do if there's an HTTP-level error? We're assuming that the invoking application just has to deal with things like proxy gateway failures etc. in its own way. George prefers UMA messages about tokens being invalid and such to return HTTP success (200), but OAuth has chosen to use 400 and 401 for such conditions.
Note that our AM has a token validation endpoint that's UMA-specific and not part of OAuth, whereas our host needs to respond to the client/requester about invalid tokens in a way that is OAuth-compliant (ideally). So if we choose to use 200 in an AM's "token-invalid" response, it might look inconsistent next to the message that the host has to turn around and give the requester, but we could choose that direction. There is a sharp difference of thinking among web protocol designers around this. It seems to relate to requiring the requesting side to do more work to dig into the guts of a message when HTTP says something is "OK". Thomas and Eve agree with George in protesting this as a layer violation. However, we're in agreement that, with fully mature RESTful interfaces, an HTTP failure when you're trying to PUT something (like a requested scope) makes sense.
We got consensus on the following TOC:
Thomas will indicate clearly in the spec where we:
We made some changes and additions to the 'pad on the call.
Eventually, once we're able to profile JWT for our uses, the token can contain enough information to identify a user, which could theoretically solve the problem of the requester approaching the host and attempting to access a resource that is "shared" among several users (such that the access attempt may be ambiguous wrt the specific user at the host). Without that, UMA is making a very large simplifying assumption that the nature of the access attempt can do this disambiguation for now.