UMA F2F 2013-07-09

Date and Time

• Ad hoc F2F meeting on Tuesday, July 9

Agenda

1. Introductions and goal-setting (IP rules are in place)
2. Describe overarching scenarios of interest (broadly, but including Respect Network -- others besides RN will be present)
3. UMA architecture and profile overview
4. RN architecture overview (see information-flows doc Dan sent out)
5. Select no more than 3 force-ranked specific use cases to tackle (to ensure we have some concrete deliverables from the exercise)
6. For each use case (till we run out of time!): Walk through current flow as we best understand it, identify gaps, and propose solutions where possible

Minutes

Introductions and goal-setting

• Dan: understand intersections between UMA and Respect Network's Personal Clouds; look at the protocol flows from a security POV – to meet assurance requirements.
• Drummond: Respect Network – walk through proposed Respect Connect flow – understand intersections between XDI endpoints and UMA AS/RS.
• Dave: ID DataWeb – have built an AXN – some of the services requested by pilot participants would benefit from UMA – how to offer an RP service that leverages UMA
• Steve: want to understand why Drummond and Phil care about UMA as much as they do.
• Les: Neustar – working with Respect Network – looking for where to use UMA in the personal cloud network they are working to set up.
• Eve: UMA lead – understand how UMA can work better with other technologies; get to a level of clarity of concrete examples of UMA working with other tech; optimization opportunities to smooth the path for individuals to use the system – adoption.
• Peter Davis: security architect for Respect. With Neustar; recognized that UMA’s capabilities fulfill some of the requirements that Respect has.
• Adrian: interested in healthcare use cases – Patient Privacy Rights – interested in patient identity and consent management
• Domenico: Old-time UMAnitarian.
• Markus: XDI2 project – how to use UMA for XDI – want to get up to date on UMA status.
• Thomas: working to build an open source implementation of UMA.
• Ken: Internet2; has an NSTIC grant; InCommon; wants to implement now. Building a Privacy Manager – nudging users to a better place; see UMA as a very important back end – after user consent/release is obtained, push it to UMA; GPII is interesting – usability is very important; want to develop an academic research community around this.

We noted that we have a great opportunity now for convergence between themes and initiatives. We identified a number of liaison connections among the participants: XDI TC, AXWG, TSCP, IDESG, and UMA WG. Regarding TSCP, the concept of device:device sharing came up. Anything with an identity, such as a device, could be the Resource Owner.

Personal cloud definitions

In order to talk about scenarios of interest, we needed to do some definitional work around "personal cloud". RN uses this term a lot, but so do others.

Discussion and proposals:

• A personal (or business) cloud represents data that an entity owns or controls, its "digital self".
• The entity can be a "person, place or thing", where the thing can be a device or a web or native app.
• A personal cloud separates apps and data, and is controlled (owned, managed, governed...) by the user.
• A personal cloud is like a personal computer in the cloud. There are use cases for personal cloud-to-personal cloud sharing.
• It deals with objects in the cloud; to prove your access rights to those objects, you may have to perform an action.
• The access controller may not always be the data originator; an example is reputation data.
• A personal cloud is distinguished from a business cloud in that the entity that owns it is a natural person acting on his or her own behalf.
• In RN, a personal cloud maps to an XDI namespace.
• In RN, a peer cloud covers both personal cloud and business cloud use cases. We suspect every entity will ultimately have a cloud.
• The distributed nature of a cloud is a fundamental concepts. This includes the very real possibility of a personal having multiple personal clouds. It's not ideal for a person to be forced to have multiple clouds by providers, but we anticipate that competition among domains and "walled gardens" will continue to produce some of this.
• A personal cloud differs from a random collection of distributed objects and their APIs in that it offers centralized orchestration of objects, through a "cloudOS".
• In RN, there is a notion of primary vs. secondary clouds, where there must be a single primary ID among them for accountability.
• NIST SP 162 – Attribute based access control; they talk about objects in the cloud not data/user/etc; the idea is that you push objects into the cloud but then you need to have an API to it and be able to assert access control policy over that API.
• In contrast to personal clouds, personal data stores (at least the way most people talk about them) are aggregators of information.
• In RN, any peer cloud has one XDI endpoint and a single XDI graph. The nature of XDI graphs is that discovery works from any node.
• Some constraints on how personal clouds operate if they are to be successful: REST-friendly, open source-friendly, and revenue-friendly.

We came to agreement on these (non-RN) distinctions. RN makes certain technology choices and simplifying assumptions, but uses the same basic underlying notion of a personal cloud that others do.

Describe overarching scenarios of interest

We agreed to start our scenario discussion by considering a single personal cloud, not a business cloud and not any of the more esoteric scenarios. We collected a number of scenarios that fit different "sharing constellations", all starting with Alice the resource owner (the "who/what" column; it's assumed Alice is the entity who crafts access authorization policy).

If Alice has a login on the requesting side, in an importance sense the data sharing is with the Client Operator as well as with herself (or rather, with the client so that it can do something on her behalf). If Alice does not have a login on the requesting side, Alice may not be around when the access request happens – so her independently running authorization server needs to take over.

***section is incomplete; stay tuned

UMA architecture and profile overview

***section is incomplete; stay tuned

RN architecture overview

***section is incomplete; stay tuned

Attendees

• Eve Maler
• Dan Blum
• Les Chasen
• Drummond Reed
• Andrew Hughes
• Steve Fulling (for Phil Windley)
• Ken Klingenstein
• Joseph Boyle
• George Fletcher
• Dave Coxe
• Adrian Gropper (remote)
• Peter Davis (remote)
• Thomas Hardjono (remote)
• Domenico Catalano (remote)
• Markus Sabadello (remote)