UMA telecon 2010-01-28

Date and Time

• 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)

Attendees

As of 22 Jan 2010, quorum is 9 of 16.

1. Adams, Trent
2. Akram, Hasan
3. Bryan, Paul
4. Catalano, Domenico
5. Davis, Peter
6. Fletcher, George
7. Hanson, Michael
8. Lizar, Mark
9. Machulak, Maciej
10. McIntosh, Michael
11. Maler, Eve

Agenda

• Roll call
• Approve minutes of UMA telecon 2010-01-21
• Action item review
• Upcoming F2F meetings
• Webinar material: final review (to be sent to list)
• Spec review
• Scenario review
  • "E-commerce"
  • Protected inbox
  • CV sharing
  • Health data
• Lexicon discussion
• AOB

Minutes

New AI summary

Roll call

Quorum reached.

Approve minutes of UMA telecon 2010-01-21

Motion to accept minutes APPROVED.

Action item review

• Webinar team/WG Open Publicize the webinar through blogging, tweeting, etc.: Close this one.
• Paul Open Revise the UMA swimlane diagrams: Consider it closed; Paul's slides will be more authoritative than the current swimlanes on the wiki. We have outgrown WebSequenceDiagrams.com for the moment.
• Eve, Paul, George Open Construct a draft use-case email for OAuth IETF group consumption: Need to make progress on this ASAP.
• Maciej Open Revise custodian scenario: Maciej has privately sent a revision for Eve to incorporate on the site.
• Mike M. Open Check on whether he should be writing an information card use case: His current thinking is that information cards can help provide a solution to any of the use cases. And the R-card notion is so close to the use cases that it seems covered.
• Eve Open Reach out to legal contacts to research the question of requesting users vs. other requesting intermediaries when it comes to terms negotiation: Closed because this is in the works.

Upcoming F2F meetings

Please register very soon if you're attending the Kantara (including UMA) F2F. So far it appears the UMA contingent may be small.

It looks like a lot of exciting stuff will be happening at the EIC event. We'll have a half-day public meeting with very good UMA participant attendance, and Eve will represent the UMA approach on a privacy-enhancing technologies panel she's putting together.

Implementation update

Hasan reports: Fraunhofer has decided to engage heavily in UMA implementation, and will have a full-time development resource for a year, to work on a C# implementation. Excellent!

Webinar update

Webinar materials are being stored as attachments off the UMA Explained page; proper links will be added when the final versions are uploaded.

The webinar is full. Do we have a couple of WG volunteers to join late or drop off?

E-commerce scenario

Eve made final edits based on Joe's recent email comments.

Motion to accept this scenario and its use cases APPROVED.

Protected inbox scenario

Eve wonders if providing some concrete examples of what would be sent to such an inbox would be useful. Also, it may be a bit too technically detailed.

Mike notes that there may be interesting policy-setting implications to controlled such an inbox (Iain had provided some detail coming out of privacy regulations, which would be good to add here). Since this controls data inflow vs. outflow, it's a distinctive aspect. (The location scenario, still pending, has a read/write access aspect to it, but we haven't looked at it in a long time.)

CV sharing scenario

Maciej explains: This scenario tries to capture a package of resources that are known to be fairly volatile. A student might create some resources, and might point to resources that others are authoritative for (such as proficiency certificates). A job search website or a prospective employer might be a requester. Employers often require trustworthy information such as reference letters, and information available from previous employers such as previous employments.

Eve notes that, in the US at least, giving out your resume to an unscrupulous recruiter who then, unbeknownst to you, puts your name in for job requisitions, can put you at risk if you then want to apply for the same job personally later. So controlling access to your CV to reputable recruiters who make reasonable promises is important.

Mike observes that this is a reputation-protecting scenario rather than a data-protecting scenario. Disclosure of my resume to the wrong party is not a hugely high-value data breach.

Hasan asks for clarification on the "trustworthiness" that appears in the title. Things like reference letters, when provided today, have to be signed and faxed so that they can't be faked. Data coming from a trusted host can match this need. Hasan notes that a list of publications one has written also has this aspect. Eve notes that UMA's ability to allow requesters to get data directly from trusted hosts means that the host need not necessarily sign the data, which is a nice convenient benefit.

(Tangential discussion: Do we anticipate that the ability to sign will disappear from OAuth V2? No; we think it will stay as an option, alongside the WRAP pattern of requiring SSL alone. George notes that the requirement to ensure that the site and user are known and trusted – true authentication of the parties – requires signing.)

Motion to accept the CV scenario APPROVED.

Health data scenario

This scenario paints a picture of "chained" (or "nested") UMA protection (metadata as well as data), which is likely the most complicated of all of the scenarios so far because, as Mike notes, the mere existence of the resource and its address are sensitive, as well as its content. (The hData standard uses in-the-clear URLs that malicious parties could use to probe a value space, or that could reveal PII.)

UMA protection might very well be a solution to trusted discovery. Peter notes that, in the XRI group, trusted discovery has been discussed many times. He hasn't seen any resistance to the idea of providing tailored XRD responses depending on the requester. Perhaps multiple XRDs would be available, some that are UMA protected and some that aren't. George notes that the infrastructure would have to create these on the fly and sign them. There may be a performance impact, but lots of systems do that today. Caching of the usual sort can handle some performance issues. Is it acceptable to require OAuth-style headers to access an XRD? Surely for a health scenario, it seems like a reasonable burden.

What about the "break-glass" scenario (where the person is unconscious in an emergency room somewhere and can't consent in real time)? One response is that a person's control of access to their health data isn't absolute, and will probably never become so. Paul suggests that the right way to do this is to "go around UMA". The custodian of some health record won't defer to the patient's policies in all cases; there are contractual and regulatory regimes may override the patient's rights. Another response is that UMA can help the patient set up policies that allow for access without real-time consent in extraordinary circumstances. From an application development perspective, George would prefer not to have to use an exception process.

Eve observes that the (still pending) employer/employee scenario has a problem that's very similar to this, in that employers may have reasons not to do exactly what the user-chosen AM tells them to. Is it just a case of having a policy clause that allows the host to release data without real-time consent? Paul thinks it's more than that. An AM may build one barrier in front of a resource, but there may be multiple AMs, or multiple other types of barriers. UMA is a discretionary access control mechanism; other mechanisms may be mandatory.

Mark asks if a loop-back can be added to the UMA protocol flow somehow. Mike thinks this doesn't feel "stacked right", since there are parts that aren't under the user's control.

Maciej had also worked on a scenario in his earlier research work on employer constraints and unique needs on information sharing. He will share it with Paul.

Next Meeting: UMA telecon 2010-02-04

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