UMA telecon 2021-04-08

Owned by Alec Laws
Last updated: Apr 08, 2021
3 min read

UMA telecon 2021-04-08

Date and Time

Agenda

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

Deferred

Pensions Dashboard

No update


Events: IIW is Apr 20-22

George reminds us about the UMA 101 session. Will get in contact with the organizers to ask


EIC Sep 14-18 

hybrid event, in-person + remote. Kantara has a workshop scheduled on the first day. Looking for a 10-15min UMA update to be included. 

If you'd like to attend/participate feel free to reach out to Colin/Alec


ONC AGM, the virtual booth did lead to one reach out for a qualified lead for the IAF program (big grin) 


AOB

As a consumer, how is this wallet/consent management technology actual rendered? Currently we have many 'narrow ecosystems' around specific use-cases. Where the user ends up with a 'wallet per use-case'. There is a risk that there is re-centralization to apple/google as the only/main providers for these services. 

One example in travel, there are trust/verification compliance requirements set by the TSA. In US this would be some alignments/assessment against 800-63. And the use-cases within the travel vertical all have different required compliance levels (eg hotel check-in vs airline check-in). Consent is directly in control of the user, today through mobile application or direct with the airlines. Some regions have additional requirements, eg for facial recognition within the airport. Today uses can choose different assurance apps, however there is no interoperability between theses services. Even as passport does't have a digital schema defined internationally (they do have physical/nfc chip standards). 

ANCR is trying to make the consent receipt work across infrastructures, as one way to create interoperability. Concept of two factor consent: notice of risk & recognition of rights. Current consent management solutions do it from the RP perspective, but not the user's perspective.

The standardization of data/schema is a huge issue, beyond what UMA only can solve today. ISO mDL (18015?) captures both today including some minimal disclosure + retention cases (is_age_over_NN, rp_will_retain). Creates some base interop on the core DL attributes, however states are open to add their additional parts. This works until people don't play, eg Michigan(?) who has rejected the interop all-together. 

When do we have a wallet that works across industry? Pointers to my identity provider and associated resource pointers (eg utility bill hosted by my hydro provider). instead of alwys needing a personal data store or copy of resources, leave them with providers that often must retain the information already. One challenge with UMA in this case it assumes the RS is always available! This is why offline use-cases are a huge industry focus, no phone home. States/Govs aren't really interested in becoming fully available services to hold/present data, issuing user held credentials avoids that IT burden as physical creds do today. There is no reason there can't be a hybid where a user has choice about pulling resources into a personal data store or leaving them at some authoritative holders.


Has anyone implemented PCTs is there any requirement that it holds claims? No, the PCT is implementation defined, it can be as opaque as wanted. It's purpose is to allow the AS to recover presented claims/id about the RqP, so only the AS should need to understand its format. Are there interop requirements for the PCT? given that its issued by and consumed by the AS, there is not. Because UMA makes the RqP a first-class role, the PCT represents some RqP context/authN separate from the Client authN. 

One UK Open Banking has relaxed the requirement for re-authenticating every 90days. Use case is the FINTECH must authN against each bank to get Access&Refresh tokens. The re-authentication requirements led to some bad UX. How are expirations determined now? Now set by use-case between the Bank+fintech. A wallet or UMA concept helps move this problem from each use-case behind a user AS service. The RP goes back to one AS relationship across many OB API providers (Banks). This is akin to a health care provider use case, a HCP often has to use many ID systems to provide enough authority to perform some specific jobs.  



Attendees

As of October 26, 2020, quorum is 5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

  1. Michael
  2. Alec
  3. Peter
  4. Sal

Non-voting participants:

  1. Colin
  2. Ian