As of 28 July 2010, quorum is 5 of 9.
Guests:
Regrets:
Trent, Maciej, Eve |
Open |
Meet to decide on next steps for taking forward Newcastle funding proposal. |
|
Quorum was reached.
Minutes of 2010-07-22 meeting APPROVED.
This group got a commitment from Kantara to offer a US$4000 bounty for the development of a hosted validator, to be offered roughly mid-year (now). In the meantime, the SMART project has been working on a comprehensive implementation of all of the UMA endpoints, and is actually on its way to developing a validator itself through development of an integration testing function. The project is interested in contributing significant resources to a hosted validator and additional developer resources. Newcastle University typically does this with a matching-funds approach. Eve has suggested that we consider approaching the Kantara Leadership Council and Board of Trustees to put the existingi allocation towards a larger amount to be shifted to this purpose. NOTE: Maciej and Lukasz would need to recuse themselves from any WG decision-making on this point.
Summary of points to note:
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.
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.
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.
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:
Eve and Christian will discuss the Steps 1-3 scope flow on Sunday.