[WG-UMA] Notes from UMA legal subgroup telecon 2015-09-25

Eve Maler eve at xmlgrrl.com
Fri Sep 25 11:26:21 CDT 2015

Fri Sep 25 8-9am PT
Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540#
Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>
Examine/confirm top meta-use cases
RS is concerned about outsourcing protection functions to AS
RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved
Discuss/prioritize business models
Organizational consumer-facing access federation
Industry access federation
Free-love access federation
Determine roughly what our outputs should look like
Develop a list of unknowns without which we can’t finish our work

Attending: Eve, Jon, Adrian, Jim, Thomas, Domenico, Dazza, Ann

Meta-use cases:

1. RS-AS: RS is concerned about outsourcing protection functions to AS.
2. RO-RqP: RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved.

Are these the top pairwise relationships to be concerned about? Adrian is concerned about the case where the technology that is executing the RO’s instructions is sovereign — that is, RO=AS. The analogy with SSO/authentication-as-a-service breaks down when we get to this point, because authentication is a kind of reputation service, authenticating the RO’s identity. It has to be a third party. By contrast, the AS can be wholly "first-party”. Should we add a third item about this? Yes:

3. RO-AS: RO is concerned that the AS fully represent her, and thus seeks to be able to build (vs. run or outsource) an AS so that it will never need to "have a privacy policy” because it’s hers.

Business models:

1. Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS.

2. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.).

3. Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in.

The reason it’s “BLT” is not just because, Bacon!!!, but because business comes first! The draft NIST Privacy Risk Management Framework notes, very sensibly, that you must start with a business goal.

What business model do the HIEs of today represent? Are they focused on a single provider? They’re vertical-specific, regional, and voluntary on the part of the RS (hospital). They struggle mightily to get adoption and achieve a sustainability model. Under HIPAA, they decided to extend HIPAA to treat data aggregators (an HIE is one) as a business associate. This gives flexibility. There are about 80 HIEs around the country, and only NY (as far as we know) has enabled patient access. It’s the province of big hospitals. The HIE only stores identity information for patient matching. Data is exchanged through Direct messaging. An HIE registers encounters, and it manages consent. Eve suspects that HIEs anomalously reflect today’s US HIPAA regulations, and we’re building something specifically patient-centric. Further, that they are a special case of an industry access federation because they are exposing heterogeneous services.

We explored the industry access federation example a bit more by looking at SmartHomeDB <http://www.smarthomedb.com/>.

#1 means you’re “on the plantation”. #2 means the data never even enters the plantation; it stays in its native environment, the way data can stay on a phone.

We agreed to focus first and foremost on #2 because it meets important UMA goals, requires legal support, and appears to be the critical model required for the IoT.

What should our outputs be?

Should we be developing sample pairwise agreements at the “client credentials issuance” stage because the terms and conditions at that stage are so important? There’s a B2B stage, and a B2C stage. The opportunity to issue those credentials always seems to come with a “gate” that has business agreements associated with it.

AI: Dazza, with Eve as backup: Bring a source of contract terms for getting OAuth client credentials.

AI: Jon: Bring preliminary thoughts on IoT liability tensions.

AI: Jim: Pose an answer to the question “ What would a sane, brilliant, non-powerless consumer, with some bargaining power (or friends at the EFF and Justice Department) expect from an agreement?”

AI: Dazza: Create a “business models page” on the wiki, numbering the business models.

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20150925/04038543/attachment-0001.html>

More information about the WG-UMA mailing list