Child pages
  • UMA telecon 2020-04-30
Skip to end of metadata
Go to start of metadata

UMA telecon 2020-04-30

Date and Time

Agenda

Minutes

Roll call

Quorum was reached.

Approve minutes

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)

  1. Domenico
  2. Sal
  3. Andi
  4. Eve
  5. Mike

Non-voting participants:

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


  • No labels

1 Comment

  1. Having trouble with the mailing list... here are the RS discovery use cases:


    The theme here is instead of all RPs needing to know about specific IDP/RSs, the the RP and RS are decoupled through an Authorization Server, allowing the SP to discover which RS to call after user authorization. This requires all RSs to support a standard API, claims_gathering and JWT tokens


    ## Use Case: IDP discovery, userinfo as a resource

    Scenario:
    There are many similar IDPs which may provide standard profile data to a RP, through /userinfo endpoint
    There are many RPs that would trust any of those IDPs to provide profile data from a user

    Using RS Discovery, an Authorization Server can manage the IDPs (as RSs) and _all_ RPs

    Outcome:
    Reduce integration to only the AS for IDPs(asRS) and RPs
    - IDPs/RPs can still participate with many AS
    - user profile data isn't known to AS

    Notes:
    Possible, but not nessecary, that the IDPs are an IDP to the AS. User login to the AS through one of the IDP

    Similar solutions
    - yes.com which offers bank/idp discovery as a directory/dynamic-ish client registration to the specific IDP
    - gov.uk verify

    Alternate Scenario:
    Even with a single IDP, that IDP can delegates RP onboarding to one or more AS



    ## Use Case: FHIR Repo Interop

    There are several clinics which collect healthcare data and offer a simple portal to their patients. Many of the patients request to share their data with other applications. Instead of each clinic curating and vetting all application, they can delegate this to an Authorization Server

    There are several [healthcare systems] that all support a [FHIR r4] API


    ## Use Case: Prevent Multiple Required Logins/Resources

    An RPs requires a user to login to multiple IDPs to authorize an action (for legal/whatever reasons)
    OR an RP requires data from multiple RSs in order to provide a service

    The AS can issue multiple access_tokens to the RP... and the RP can make API calls to both RSs with the appropriate constrained token


    ## Use Case: Data across FHIR Repos

    A blend of the previous two use cases

    There are many FHIR systems in a region. Each system maintains a specific subset of a patient record. For example there is an immunization repository and lab results repository

    There are 3 example RPs, RP A needs only immunization, RP B needs only lab results and RP C needs both.

    Using resource discovery each RP is registered with a ticket specific to the scope of their needs. In the last case, RP C can make one authorization request and may be granted access to both FHIR repositories