UMA telecon 2010-01-07

Date and Time

• Day: Thursday, 7 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)

Attendees

Voting participants:

1. Adams, Trent
2. Akram, Hasan
3. Andrieu, Joe
4. Bryan, Paul
5. Catalano, Domenico
6. Chadwick, David
7. Lizar, Mark
8. Machulak, Maciej
9. Maler, Eve

Guest:

• Joni Brennan (staff)

Regrets:

• Tom Holodnik
• Iain Henderson

Agenda

• Administrative
  • Roll call
  • Approve minutes of UMA telecon 2009-12-17
  • Action item review
  • Note: OAuth V2.0 telecons beginning soon
• Webinar planning: time slot, publicity, technologies
• Review and approve/defer/reject scenarios and use cases
  • E-commerce
  • Terms negotiation scenario discussions
  • What new scenarios are in the pipeline? How to prioritize review during this month?
• Spec review and futures
  • Claims format
  • Core spec
• AOB

Minutes

Roll call

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

Other administrative

OAuth V2.0 telecons are beginning soon; please consider attending if you're interested.

New AIs

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