Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

Minutes

Roll call

Quorum was not ? reached.

Approve minutes

tbs

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.

Conformance testing project update

tbsDeferred.

Profiling (and turning it into projects)

We're ready in the case of the resource description profile, at least, to start truly writing a spec profile in the WG. The preference among people in the group is to use markdown (vs. what we used to use, XML) to write this stuff in. OIDF uses markdown and a tool that automatically converts it to RFC format – possibly customized to get OIDF formatting. Let's try and use that tool – possibly (further?) customized to get Kantara formatting. Alec is willing to be the editor. (Here are other tools and more advice.)

It would be valuable for us to produce additional specs that may contain non-normative text as well. While this is broader than profiling, it would expose existing valuable content in a form that would widen its audience. Examples include the resource description profile use cases we discussed last week, the UMA Implementer's Guide material (which is akin to OIDC implementer's guide material though not identical), and even our voluminous UMA use case and case study material on our wiki.

With regards to the consent management work currently going on, there is a GDPR receipt profile that is underway on the consent receipt in the consent and notice project group, Andrew is also working on a framework for ISO. And at OpenConsent Joss is on the Advisory Board and they are tracking MyData. On the SSI front Mark L is working with others on a distributed ledger consent specification, which came out of the Hyperledger effort.

Do we also have an opportunity to write a claim profile, or similar, to ensure interoperability of getting a requesting party claim in the form of a verifiable credential? Adrian has talked about the need to pass a "request triplet". His HIE of One Trustee implementation integrates uPort identities from the "Bob" side. IDENTOS also uses UMA to fill some of the holes in the SSI technical protocols where human trust comes in. It can bridge all the diverse technical implementations. What's the best way for us to try and write such a profile? Inspect the code, quiz Michael Chen...? That project is currently working to put together a new fork and better documentation. We could achieve a lot of value by writing a profile where a VC functions as an authorization token. It is sort of a powerful kind of "PAR" (pushed authorization request) and we might even be able to go AS-first.

UMA represents a viable solution to "dashboards" and MyData operators. So if we can provide legitimate specs illustrating solutions that integrate well with other pieces of the ecosystem, we anticipate it will be adopted.

Conformance testing project update

We are currently gathering offers of financial and development resource donations towards this effort, which would result in a test harness for self-certified conformance somewhat similar to others we're familiar with. It would test AS conformance first. The intent is to secure a dedicated consulting resource so we can do this development timely. 

Attendees

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

  1. tbsDomenico
  2. Eve
  3. Sal
  4. Mike

Non-voting participants:

  • tbsAlec
  • George
  • Stephen Payne (solution architect for ForgeRock, focusing on healthcare in west, central, Rocky Mtn)
  • Colin
  • Anik
  • Lisa
  • Adrian
  • Tim

Regrets:

  • Nancy
  • Scott