...
- The existing UMA WG budget allocation from Kantara is for US$4K as a bounty to be offered towards hosted validator development, to be offered in mid-2010.
- We have an offer in hand from Newcastle University for £10,500 (~US$16K) to go towards an UMA-related SMART project of their own if Kantara can match this amount.
- The deliverables from the SMART project would be to turn their UMA/j prototype implementation (which has some integration testing) into a true open-source reference implementation with a hosted validator component and an open-source license that is maximally friendly to developers.
- One idea on the table is to figure out how to contribute the original US$4K allocation into a larger Kantara match amount of US$16K in order to enable these deliverables.
Discussion:
Trent: Could Kantara and other parties contribute to make up the US$16K amount? Maciej believes there is no restriction on that, but will check. Thomas: Recalling previous experiences with development of a test harness in TCG, would it be necessary/appropriate to do a call for bids for such development? The Kantara board might want to consciously choose to award a particular bid for development.
Trent: Points out that one way to interpret Newcastle's offer is as a bid for the bounty amount. And they are, in addition, making a proposal to ask for an additional US$12K. Eve: This relates to Thomas's comment in a way; we've been striving towards getting a comprehensive and usable suite of specs partly in order to be able to advertise the bounty. To date, we haven't been a position to advertise the availability of the bounty. Maciej: Comments that his project is looking to provide maximum benefit to the WG, whatever form that takes.
MOTION: The UMA WG is supportive of the offer from Newcastle for UMA development funds/deliverables with some sort of Kantara match. The motion is APPROVED.
AI: Trent, Maciej, Eve: Meet to decide on next steps for taking forward Newcastle funding proposal.
Status reports from the wider UMA world
Maciej reports: The SMART project has now had ~50 participants in the UX study, with ~30 participating in person.
Eve reports: The OAuth list has been touching on UMA-related topics lately, such as "protected feeds" (from the federated social web discussions) and how an authorization server can be made to handle a wide variety of resource servers whose natures differ dramatically.
Dynamic registration I-D (formatted, source)
Eve's new draft was posted at here. Christian has now folded that into the main trunk.
Christian suggests actually quoting the relevant UMA design principles, for clarity. OK.
Thomas suggests changing the mention of "data integrity" to "transaction integrity". Christian agrees. OK.
Thomas comments that the analysis of flow option #1 doesn't really speak to the fact that the burden is always on the authorization server to ensure that the same client correlates with the right metadata (which could, in all honesty, legitimately change its metadata over time). And the resource server certainly doesn't care, since it uses the access token exclusively for correlation. So maybe the rejection of flow option #1 is overstated and should be softened. OK.
Regarding the question of a "registration proxy" approach (Maciej's and Domenico's proposals), should we include both, include both but recommend one, include one, or include none? Let's try and decide by Monday's focus call.
Eve can edit the spec again by Monday. Thomas can do some editing and review; he should therefore go and create a github account. On Sunday, Christian will teach Eve how to use github, and she'll pass on the knowledge in the Monday focus group meeting.
The goal is to have a final spec draft ready by Thursday for group approval and, ultimately, IETF submission.
Resource Registration specifics (existing proposal)
- New SMART model for "pull" (screenshots)
Maciej describes the experimental SMART approach. The host and AM actually need a bidirectional relationship, and this is impacted by both UX and protocol needs. So when the user is at a host and begins to introduce that host to the user's chosen AM, there is a consent button right there (on the host side) to allow the AM to pull resource info from the host once they have met each other. Behind the scenes, the host not only gets a "host access token" to use in accessing host-specific protected endpoints at the AM, but it also gives the AM its own access token to use in accessing protected endpoints at the host.
There are several motivations for doing this. First, the SMART UX study discovered that users tend to want to manage protected resources while they are logged in at the AM, not that the host. Second, the SMART project folks suspect that it could be valuable to register hosts directly from the AM as well, so being able to do fully bidirectional OAuth introductions seems to make sense.
Major RRAPI issues:
- Resource details protocol
- Push (Christian's draft)
- Pull (Maciej's experimental method)
- Resource details format
- Just resources, resource groups, and so on
- Scopes: combination of resources/endpoints and what you can do with them
Eve and Christian will discuss the Steps 1-3 scope flow on Sunday.
Next Meetings
- Focus telecon on Monday, 2 Aug 2010, at 7-8am PT (time chart)
- Special dial-in: Skype +9900827044630912 or North American Dial-In: +1-201-793-9022/room code 4630912
- WG telecon on Thursday, 5 Aug 2010, at 9-10:30am PT (time chart)