UMA telecon 2020-06-25

Owned by Eve Maler
Last updated: Jun 25, 2020

UMA telecon 2020-06-25

Date and Time

Agenda

  • Approve minutes of UMA telecon 2020-06-11
  • Off-week meeting scheduling
  • Conformance test suite project
  • Kantara webinar: looking for UMA participant
  • New profiles
    • Resource definition profile
    • Wallet profile
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Deferred.

Off-week meeting scheduling

The winning time slot is alternate Thursdays (starting Jul 2) at 10am PT/12 noon CT/1pm ET etc. Eve will get the calendar stuff going. She will invite all of the voting participants and all of the additional participants who said they can make it at that time. Let Eve know if you'd additionally like an invitation vs. just subscribing to the calendar.

Conformance test suite project

This is a more formal project now, with a written proposal from Colin and a funding model. The project is happy to accept donations of resources of all sorts.

Kantara webinar: looking for UMA participant

Alec, Adrian, and Mike are willing to take part. Alec spoke first so he gets to determine the shape of our participation. (smile)  Eve will put them in touch with Colin.

New profiles

  • Resource definition profile status
  • Wallet profile

We worked from the flows and diagrams in Alec's recent email.

Alec has now added both Alice and Bob into the "new spiral" diagram. The RO delegates RS management to the wallet. The RqP now has a flow where they can release resources to the AS. The client is redirecting the RqP to the AS. Depending on how the delegation is managed, authorization can happen at the AS or at the wallet. Adrian asks: Because in his world (HIE of One) the wallet isn't necessarily online, what are the implications? The wallet in this control plane view needs to be online to write policy. So why have "choose wallet" as a dotted line and why not make this the default? Because their AS doesn't even have or need any claims gathering. This is Alec's challenge in generalizing what they've done to cover more use cases. We'll have to test the general-case design a bit.

The setup text has some detail. It says "user" because it means either RO or RqP. The overlap with SSI is that there is personal key management.

There are "furious conversations" currently about what it means to have an SDS wallet. Alice could have four choices for a wallet:

  1. Wallet on smartphone, well secured
  2. Custodial wallet, held by someone else with multi-signature capabilities
  3. Cloud wallet of her own, built into an AS
  4. No wallet, just a feature phone

Thomas suggests describing control-pairs – "who controls what" – in each pair.

(The "alt" boxes in the diagram are asynchronous setup stuff that either the RO or RqP could go through.)

1. AS starts claims gathering. ... 

6. The wallet acts as a client to the RS.

9. The RqP themselves, not the wallet, logs in at the RS using a personal public key that they can sign JWTs with. They put resources under protection here.

Thomas notes that the wallet becomes the control point for all the RS's and all the AS's. If someone wants to go offline for some period, they could potentially delegate a particular RS-AS pair for some resource to someone else to enable someone else to control it for them. This is very much akin to the business-legal "relationship management" model work we've done, with scenarios like having a data subject delegate control to one or more resource rights administrators.

The responsibilities of the "community AS" are to keep the policies privacy-protected, and of the "personal AS" (which the wallet)...

Attendees

As of 23 Jun 2020, quorum is 5 of 9. (Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)

  1. Domenico
  2. Thomas
  3. Eve
  4. Maciej
  5. Mike

Non-voting participants:

  • Alec
  • Anik
  • Adrian
  • Scott
  • Carlos
  • George
  • Tim