[WG-UMA] Draft minutes of UMA telecon 2010-01-21
eve at xmlgrrl.com
Fri Jan 22 01:45:08 EST 2010
Action items: http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes
Attendance record: http://kantarainitiative.org/confluence/display/uma/Participant+Roster
The open action items and minutes are also pasted below, for your convenience.
Please don't forget to register for the Kantara F2F meeting, if you haven't already done so!
Action item number Assigned To Status Description Comments
2009-10-15-2 Eve Open Write a "Hey, Sailor" scenario to illuminate the needs around Requesters that ask for resource access without the User expecting them. Still pending, though partly covered by "requester identification" terms negotiation scenario
03-02 Eve Open Reach out to developers and deployers of OAuth consumers. In progress
2009-12-03-04 Eve Open Add terms-negotiation scenarios to Scenarios document. In progress
2009-12-10-03 Eve Open Get in touch with contacts uncovered by Mark W.
2009-12-17-4 Eve Open Propose a requirement or design principle about constraining our V1 scope to "full-blown" sites
2010-01-07-1 Webinar team/WG Open Publicize the webinar through blogging, tweeting, etc.
2010-01-07-5 Paul Open Revise the UMA swimlane diagrams.
2010-01-14-2 Eve Open Revise requester definitions for review.
2010-01-14-3 Domenico Open Develop wireframes for approved scenarios.
2010-01-14-5 Eve, Paul, George Open Construct a draft use-case email for OAuth IETF group consumption.
2010-01-14-6 Maciej Open Revise custodian scenario
2010-01-14-7 Mike M. Open Check on whether he should be writing an information card use case.
As of 12 Jan 2010, quorum is 9 of 17.
Approve minutes of UMA telecon 2010-01-14
Motion to accept minutes APPROVED.
Action item review
2009-10-15-3 is closed.
2009-12-10-06 is OBE.
2009-12-17-2 is closed.
2010-01-14-1 is closed.
2010-01-14-4 is closed.
2010-01-21-1 Eve Open Put hData scenario in Scenario document.
2010-01-21-2 Webinar team Open Flesh out the slides and merge the PDFs and upload the resulting file.
2010-01-21-3 Webinar team Open Register for the webinar.
2010-01-21-4 Eve Open Reach out to legal contacts to research the question of requesting users vs. other requesting intermediaries when it comes to terms negotiation.
Webinar planning and review of presentation materials
We reviewed the draft sent this morning, slide by slide. The next draft will include many wording suggestions made on the call and edited directly into the document.
Discuss our input to the OAuth process
We need to delay our submitting of the email a bit. The first OAuth telecon will be held today.
The spec needs a typographical fix; we have two instances of Step 1b.
We are currently relying heavily not only on OAuth (which is having V2.0 throes) but also XRD (not settled yet but getting closer) and LRDD (very much not fully baked). We should treat our draft spec as a bearer of use cases for all of these, not just OAuth all by itself; wherever we have to profile or extend one, presumably this will be good input for those working on it. If XRD, and LRDD in particular, don't get settled before we have to do strawman implementations, there will probably be some mismatches around this. E.g., common webfinger implementations use an old version of XRD.
The hData scenario, now sent to the list (but not yet incorporated into the scenario document), has a diagram that illustrates how UMA could be used to protect a metadata endpoint, both against parties that want to add their own entries and against parties that want to be given a set of metadata to find the resources of other parties. Eve and Paul have talked with John Bradley a little bit about this, and George has separately done so as well. Perhaps we'll end up having an "UMA profile of XRD" for trusted XRD discovery and population, as well as profiling XRD in UMA for UMA's own flows.
Steps 5 and 6 are the newest pieces here. Step 5 lets the requester find out the requirements for obtaining resource access authorization. The requester indicates the format of claims they're prepared to respond with; it could be IMI-style, or anything else.
George asks: Who is the "consumer" here, given that a consumer key has been supplied in the example? Paul: The consumer key was publicly supplied, so it could nominally be seen as "three-legged" but really it's a two-legged flow. The token here establishes a shared secret (durable identifier) for further negotiation. Proving anything about the "subject behind the requester endpoint" (around which we still have an ongoing conceptual discussion) is not the job of the OAuth layer, but rather the claims layer.
The parties trying to come to terms, when there's a requesting person Bob who is trying to use (say) Google to access Alice's resource hosted on (say) Yahoo, are the requesting person and the authorizing person. So Paul's position is: The only party Alice can hold accountable for Bob's access of the resource is the end of the line: the requesting person. Thus, any promises Alice wants made should be made by Bob. Bob can perhaps make claims about the infrastructure he's using, but there could be arbitrary layers of infrastructure, and he may not even be aware of some of them. Google could outsource certain jobs to other cloud providers, and so on.
Paul explains that the idea of caching authorization decisions is an optimization that hosts can use, and in similar fashion, requesters don't need to keep providing the same claims. The cycle of claims-requesting might go back and forth a bit, to allow the AM to ask for further claims based on the initial claims received. But once the requester has jumped through all these hopes, they can reuse the authorization token thus established.
Eve wonders if requesting intermediary is a good phrase for the possibly arbitrary (nested, chained) numbers of parties in between the requester endpoint and any requesting user.
Newcastle University will be hiring a full-time software developer for 15 months to support UMA protocol implementation! The goals will be to work on higher-education use cases, and to run an AM at Newcastle. Eve has appointed Maciej "implementation coordinator" for keeping track of all of our implementation and interop efforts.
Details on next F2F meeting
We're meeting in Portland, OR on March 9 and 10. Don't forget to register! In addition to others already identified, Tom H. believes he can attend.
Next Meeting: UMA telecon 2010-01-28
Day: Thursday, 28 Jan 2010
Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)
eve at xmlgrrl.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-UMA