UMA telecon 2020-04-30

Date and Time

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

Agenda

Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23
Resource definitions profiling use cases (Alec)
Interop meeting update

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23

Deferred.

Resource definitions profiling use cases (Alec)

Eve had an AI to find our old ecosystem/co-location of parties work. Our oldest writeup is gone, but the new version is on slides 14 and 15 of our Legal Role Definitions deck. Slide 15 in particular shows how a wide ecosystem can be "narrowed" when different Operators are co-located in a single entity. Adrian notes that MyData came out with its Operators paper yesterday. It's not technology-specific but is surely relevant here as well. He also points to this governance paper. The relevance of "ecosystem shape and size" is that the resource definitions profile we might define could apply to ecosystems not of the widest possible size but of potentially limited size or shape. In other words, the profile could make assumptions about co-location of certain services. Jim provides this writeup on fiduciaries.

The goal in ACE for its AS-first flow is to achieve disconnection opportunities for the RS, which is not the purpose of the resource definition profile – but it would probably be a good idea to consider compatible profiling for the two sets of use cases (resource definition and constrained environments) so they could be used at the same time.

Alec has put details about the use cases he provided below as a comment to this page.

The first use case Alec mentions is where the AS enables IdP discovery, where UserInfo is the resource of interest. The AS effectively defines the boundaries of the community. The AS need not be colocated with the actual IdPs. Each IdP is an UMA RS that can register which particular attributes (as, say, UserInfo scopes) it supports. This was the original use case for which the profile was developed.

The FHIR Repo Interop use case is the one we've been talking about a lot, where the FHIR open API is used in specific detail in various ways by different RS's (clinics).

What they're seeing is that a traditional OAuth RS is able to start offloading responsibility onto an UMA AS. A provincial identity management program (IdP), in order to scale out and support thousands of services, can sufficiently "trust" the AS to make the agreement with each RP (UMA client) using this profile. Adrian asks: Who checks the credentials of the RqP, and who checks the credentials of the client of the RqP? It could be the AS in both cases.

Adrian notes that the doctor is currently captive to the EHR system. He wants to make it possible for the doctor to have a choice in applications and to have a secure element for holding their private key (which they need for e-prescribing).

This value to the "requesting side" is apart from the privacy-respecting value. This could even be valuable to a big company with ten different IdPs or other RS's internally, using the same (proprietary) API. So we think there is definitely horizontal/broad relevance to working on this profile Please continue reviewing the use cases in the comments below and discussing on the list.

Interop meeting update

Deferred (but Eve notes that she, Colin, Alec, and Mike met and made some progress towards a plan for putting together conformance testing, and we invite anyone else interested to raise a hand).

Attendees

As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)

Domenico
Sal
Andi
Eve
Mike

Non-voting participants:

Alec
Cigdem
Jim – back in California, working with GA4GH
Scott
Adrian
Colin
Tim

Browser not supported