UMA telecon 2018-07-12

Date and Time

Thursdays 9am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/857787301
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes: Approve minutes of UMA telecon 2018-06-14
Leadership team elections: chair, vice-chair for annual term
Note: New issue 361: OAuth AS metadata spec is final (no action now)
Discuss/compare HEART use case Alice Shares Clinical Records With Her Spouse and Origo use case for cross-sector implications of the "multi-portal problem"
- May relate to issues 53 (Assess interest in making AM a formal client of APIs for policy servers, interaction services, etc.) and 106 (Have an API to let an RS register the user’s sharing preferences/policies directly)
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2018-06-14: Deferred.

Vermont's new law

David worked on Vermont's new S.269 ensconcing Personal Information Protection Companies (PIPC) (see the news). The law sets up a basic framework for PIPCs, but there is a lot of room for the specifics. Tim had a role in the work as well. Sec. 5 in the law calls for a FinTech Summit to be held, and the Department of Financial Regulation to take further steps. There could be appetite for learning how UMA can provide value in separating "personal information" services from "protection" services.

Thomas served as a moderator at the DC blockchain caucus. The blockchain startup CEOs mentioned Vermont as leading in the area of "blockchain sandboxes", but being blocked at the federal level. Propy is a new company in Vermont doing land registry/real estate recording. Because of the US blockages, the first POC was in Ukraine.

What about UMA with and/or vs. DIDs? Eve's recent answer when asked:

"I know of a couple of projects that combine them, and I consider them complementary. UMA has long had a design principle about being “ID-agnostic” (see the Charter) and it seems to work. Also, the actual consent, permissioning, and access control mechanisms built into SSI-type systems, as far as I can see, aren’t directly related to their blockchain tech but are part of the rest of their app stack. So they [the consent/permissioning/access control mechanism] could be proprietary, OAuth/UMA-based, etc." More specifically, UMA has several places where identifier/claim sources come into play: How a RO identifies themselves to the RS, how a RO identifies themselves to the AS, how the AS gathers claims from the RqP interactively, and how the client conveys a claim token to the AS token endpoint. Mike notes that a DID is a reference to what UMA calls a claim token and, we think, doesn't specify a format.

The BSC DG report has a figure illustrating the role of blockchain tech (potentially necessary, but always insufficient) in an app stack.

Leadership team elections

The current leadership team roster is here.

MOTION: Sal moves: Eve to serve as chair for another annual term and Maciej to serve as vice-chair for another annual term. APPROVED by unanimous consent.

New issue 361

Next time we open up the specs, we'll take a look at this.

Discuss/compare financial and health "multi-portal problem" use cases

Discuss/compare HEART use case Alice Shares Clinical Records With Her Spouse and Origo use case (see their architecture description, adoption recommendations, and performance testing news) for cross-sector implications of the "multi-portal problem"
- May relate to issues 53 (Assess interest in making AM a formal client of APIs for policy servers, interaction services, etc.) and 106 (Have an API to let an RS register the user’s sharing preferences/policies directly)

Maybe new UMA infrastructure (Eve had been imagining that you need a formal policy API and a "consent API access token" or CAT!) isn't strictly necessary, at least for now. Looking at the Origo solution (see the two-part UK Pensions Dashboard scenario in the "Legal role definitions" slides), its Pensions Dashboard service is the unique client app that then presents a policy-setting service to the RO. It needs the two-step approach that Origo uses, but it works for then sharing with RqPs who aren't equal to Alice, and for centralized policy setting with a client where the business climate (as in US healthcare today) wouldn't be friendly to each AS not working with competitor RS's running policy interfaces. This solution may be a common design pattern.

AI: Eve: Intro Nancy and David in email to pursue the topic further prior to the next call (which is July 26).

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

Sal
Maciej
Eve
Mike

Non-voting participants:

Thomas
Nancy
Bjorn
David Thelander - lawyer - licensed in Vermont, SEC background, Gravel & Shea, blockchain and identity trust companies

Regrets:

Domenico

Browser not supported