[WG-UMA] Draft minutes of UMA telecon 2010-01-07
eve at xmlgrrl.com
Fri Jan 8 17:45:07 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. Lots going on this month -- please take a look and try to do your AIs promptly. Thanks!
Action Item Summary
The action item number is the date the item was assigned, followed by a number. Old closed items will be removed from the list periodically.
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
2009-10-15-3 Gerry Open Write an hData scenario for the Scenario document. Still pending
2009-11-19-1 Eve Open Work with Maciej, Hasan, Dom to produce a slide deck explaining the protocol. In progress
2009-12-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-10-06 Paul B. and Mike Open Provide email comments on Domenico's graphics
2009-12-17-1 Webinar team Open Determine a Jan 29 time slot and work with KI staff to publicize
2009-12-17-2 Webinar team Open Draft slide deck for group review
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-2 Joe Open Submit a protected-inbox scenario.
2010-01-07-3 Eve Open Revise the e-commerce scenario based on 2010-01-07 comments.
2010-01-07-4 Eve Open Mail out scenario text for people's review before next week.
2010-01-07-5 Paul Open Revise the UMA swimlane diagrams.
Joni Brennan (staff)
Quorum not achieved. It's time for Eve to do another round of making some participants non-voting.
Approve minutes of UMA telecon 2009-12-17
Deferred due to lack of quorum.
Action item review
2009-10-15-3 Gerry Open Write an hData scenario for the Scenario document. Likely to be submitted soon; Eve has been working with Gerry on this.
2009-12-10-06 Paul B. and Mike Open Provide email comments on Domenico's graphics Please do this...
OAuth V2.0 telecons are beginning soon; please consider attending if you're interested.
Webinar team/WG Open Publicize the webinar through blogging, tweeting, etc.
Joe Open Submit a protected-inbox scenario.
Eve Open Revise the e-commerce scenario based on 2010-01-07 comments.
Eve Open Mail out scenario text for people's review before next week.
Paul Open Revise the UMA swimlane diagrams.
Webinar planning: time slot, publicity, technologies
The planned time slot is Friday, January 29, 8-9:30am PT (time chart). Joni will help us get this onto the Kantara calendar.
We need to use a webinar system that accommodates Paul's and Eve's computer systems, which means Windows-based solutions are out. Our current plan is to use the WebEx option Kantara has made available to us, and record the presentation. Joni notes that she's had a good consistent experience with it over the last three years.
E-commerce scenario discussion
Mark and Joe commented that, if Maya has a relationship manager that can itself be a recipient of messages from vendors such as "There's a recall on the slow cooker you bought because of a manufacturing defect, and your slow cooker may blow up", then Maya doesn't have to release any other communications endpoints to them. She could then check her relationship manager (personal datastore?) for "inbox messages" such as this coming from vendors. This inbox, just like any other UMA-protected resource, could be made available on a permissioned basis to particular vendors. (This would avoid "spam".)
Do we want to create a separate scenario that focuses on providing a "protected inbox"? Yes. There are many specific use cases where this would be interesting: personal RFP responses, product recall notices, other items from the car-buying scenario, anti-spam techniques for SMTP mail, incoming activity stream subscriptions, etc.
The larger problem of DoS attacks as part of attempts to access protected resources needs a range of (largely traditional) mitigation strategies. Paul has put some thought into the implications for the protocol and implementation thereof. For example, assuming that our protocol retains the notion of the "referral resource", it imposes a burden on (illegitimate) requesters that mitigates the risk. Paul suggests that we might literally utilize the proof of work strategy.
Joe asked if this is really about static aggregation of a set of pointers for reuse (whether it's Atom or XRD or whatever), vs. dynamic aggregation of these pointers. This would have implications for the UX when users register for accounts and such. Eve was imagining static packaging at a minimum, since it seems reasonable to want to treat as a first-class-citizen resource that can have policies attached to it and so on. David has been working on a system that actually does static aggregation (see his email to the ID-WSF Evo list), and his project has learned that users appreciate the ability to tweak such packages in real time. Having a default package of data is probably sensible, but users may want to adjust the contents per requester.
We discussed, once again, how the user can permission sharing of e-commerce purchase/account data in real time if she couldn't pre-authorize that particular requester somehow. The solution using today's web will probably have to lean on redirects, a la OAuth, as previously noted. But the recent trends for "identity in the browser" suggest a much better solution.
Eve needs to change the language to talk about packaging pointers to resources, rather than literally aggregating any data/content. Also, the issue at the end of the one-night stand use case needs to be removed now that a new scenario will focus on the communications issue.
Joe also suggested that we modify the name of the e-commerce scenario. Would "data mashup" instead, or in addition, work? We agreed on "E-Commerce Resource Packaging" as the name, with a caveat that we mean pointers to the resources, not literal data aggregation.
Terms negotiation scenario discussions
Largely deferred. Eve intends to keep the identity-based terms and the role-based terms discussions separate, even though we'll likely solve them with an identical technical approach.
What new scenarios are in the pipeline? How to prioritize review during this month?
The hData scenario is still pending, but we will likely be able to take it up (along with the similar Distributed Services scenario) very soon.
Maciej submitted two scenarios that we should review, and he will be submitting a higher-education scenario shortly.
Eve will mail out the text of all the open scenarios for people's review ahead of next week. Everyone on the call has committed to spend one whole hourreviewing and commenting on these scenarios.
Spec review and futures
Paul's current issues are:
Requester crypto burden: He currently believes that some requester-performed cryptography will be needed for us to meet some of our critical use cases around requesters providing sufficient claims to get permissioned. This may conflict with our goal of avoiding adding a crypto burden. What should we do?
David concurs that this additional crypto is needed, and further notes that we can't allow requesters to get symmetric key material that will enable them to impersonate the subject, so we're definitely into asymmetric crypto-land.
Eve comments that as long as we can handle lower-value use cases where requester self-assertions are useful for some sharing, the higher-value higher-sensitivity use cases (electronic health records, financial data, and so on) are likely to involve systems that don't shy away from crypto.
She also notes that the distributed services and hData scenarios involve some parties serving as both host and requester, we should be cautious not to push complexity (such as a crypto burden) onto hosts and away from requesters. (We already have a goal to avoid adding complexity to both hosts and requesters.)
OAuth and WRAP futures: Our current protocol flow currently is based on "pure OAuth". There has continued to be some movement in the OAuth V2.0/WRAP world during our holiday hiatus, so it behooves us once again to examine the question of the base underlying our spec. WRAP is "in the authentication business" (because the requester/client comes to the host/protected resource bearing a token that's immediately usable for access). If we decide to move onto a "pure WRAP" basis, we can simplify some things, like eliminating our referral resource approach. But it appears OAuth V2.0 won't be "pure WRAP", but some hybrid. And WRAP makes life incredibly simple for requesters/clients by pushing more burden onto hosts/protected resources (in WRAP, clients do no signing whatsoever, using SSL instead), but we've got use cases where a single party may be both.
We encourage UMA folks to get involved in the OAuth/WRAP discussions if they have interest in these matters.
Next Meeting: UMA telecon 2010-01-14
Day: Thursday, 14 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 699 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20100108/efe7909f/attachment-0001.gif
More information about the WG-UMA