As of 2 Jun 2011 (pre-mtg), quorum is 6 of 11.
Guest:
Regrets:
Eve, Maciej |
Open |
Plan webinar content. |
|
|
Susan, Dervla |
Open |
Test WebEx system/account to ensure we can record the webinar. |
|
Quorum was reached.
Jacek is a new member of the SMART team. He's been studying IT and CS. He'll be helping out with the UMA protocol, implementation, and the SMARTAM software.
Minutes of 2011-06-23 meeting APPROVED.
They are thinking about abstracting the IdP-side functionality of the AM, so as not to be too closely tied to Facebook. Perhaps Google+ Circles could provide another alternative. They have just upgraded SMARTAM to be able to show you a history log of how people have been accessing your resources. It's in "wall" format. You also have a means of modifying access from this view. They also added the ability to track and respond to unilateral access requests for which the authorizing user hasn't made a policy yet.
Sal attended. He didn't have a good time slot to present UMA, as we thought he might, but we distributed the prepared slides to Jeremy Grant. The workshop was two days. People from EFF, Microsoft, etc. attended – an interesting mix of industry and others. The discussion about "why privacy matters" was mostly significant in that it allowed the program office to stress its commitment. (The first workshop was on governance.) There will be a technology workshop in September on the west coast.
The workshop went into breakouts to discuss technology approaches. UMA came up a couple of dozen times over the course of the event. Zero-knowledge proofs came up a couple of times. The workshop was webcast and that recording may still be available. The first day's panel is probably worth listening to. Also look at the presentations online. If they consolidate the reports coming out of the breakouts, that would be valuable too.
The webinar will now be held on Thursday, July 14, at our regular call-in time of 9am PT, for one hour. We'll plan to send out the press release by Thursday, July 7. We're collecting quotes from people who are implementing or planning to implement UMA or need it uniquely.
We now have a Facebook page! Everyone should go and "like" it. It's called User-Managed Access. We'll get a nice URL for it when enough people have liked it.
We should use the #UMAWG hashtag going forward. #UMA has too many overlaps and unrelated stuff.
Eve and Maciej M. will be the webinar presenters by default. We'll see if Alam can also join to do a demo of his stuff.
Here is a list of venues where we want to get the news out, and responsible people:
MOTION: Approve the UMA core spec in its current form, with instructions to the editors to continue incorporating open items. APPROVED by unanimous consent.
We can continue to revise it going into the future, of course.
Lukasz and his colleagues will plan to finish their edits by tomorrow (Friday). Thomas and Eve will prepare the draft on July 3 for submission by July 4.
Discussion of ISSUE #12: George was advocating option B, and Eve now agrees. We gained consensus to go with option B for now (UMA error and HTTP error when token is invalid). Lukasz's current work on the error messages just has an error message for "invalid token". Let's go with that for now. We can add detail as required in future, while being careful not to expose to the host any information that it shouldn't necessarily know.
This closes ISSUE #05 as well!
Maciej points out that it has to be possible to return an empty array of permissions when the token is valid but isn't associated with any permissions yet. Agreed.
Discussion of ISSUE #16: Domenico and Eve will try to flesh out the spec text on trusted claims, or at least link to the separate document Domenico has prepared.
Discussion of ISSUE #30: We say the {hostid} has to be the client ID, but what if the host is in the position of using anonymous credentials for some reason? Is that even a possibility in the case of hosts (vs. requesters)? Should we identify this more obviously as a constraint? Lukasz and Eve think it should be identified as a constraint, meaning that if dynamic registration is used, it has to support truly unique client credential issuance. We gained consensus to go with this approach for now.
Discussion of ISSUE #31: SCIM sends RESTful CREATE/UPDATE responses that contain the whole JSON structure. We gained consensus that we should do the same.
The SMART team is willing to present if this event jells.