[WG-UMA] Draft minutes of UMA telecon 2010-01-21

Eve Maler eve at xmlgrrl.com
Fri Jan 22 01:45:08 EST 2010


Minutes: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-01-21
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!

	Eve


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.	 

Attendees
As of 12 Jan 2010, quorum is 9 of 17.

Adams, Trent
Akram, Hasan
Bryan, Paul
Catalano, Domenico
Fletcher, George
Holodnik, Tom
Lizar, Mark
Machulak, Maciej
Maler, Eve
Smith, Bill
Regrets:

Joe Andrieu
Minutes
Roll call
Quorum reached.

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.

New AIs:

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.

Spec review
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.

Implementation news
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)
Dial-In:
Skype: +9900827042954214
US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)



Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100121/e5877b4b/attachment-0001.html 


More information about the WG-UMA mailing list