Minutes

Roll call

Quorum was not reached.

Approve minutes

• Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23

Deferred.

Around the horn: industry activities

Access Now has been holding its RightsCon conference. Tim spoke, and briefly mentioned UMA. It has relevance for the group's work. We could potentially speak on specific use cases in future in a formal fashion.

Adrian has some updates on MyData activities. Sixteen vendors were accredited/anointed as "MyData operators" in its first round of such activities. This process is relevant to UMA in that it does not require standards.

UMA implementations and interactive claims gathering

New UMA implementation work: Scott mentions a new containerized UMA environment from ForgeRock known as frdp-containers-uma, a "repository that provides a Ready-2-Run environment for testing the User-Managed Access (UMA) Reference Implementation".

Michael will add an entry for the EmpowerID implementation of UMA to the Implementations page.

We are looking for information about implementations that support UMA interactive claims gathering. We now know of three:

• Gluu
• Identos FPX
• EmpowerID

Perhaps there is specific relevance to verifiable credentials in interactive claims gathering (as is SIOP; see the recent meetup). But then also of pushed claims? UMA Grant doesn't define any canonical claim token formats; Sec 3.3.1 suggests one in an example but it's non-normative. Could a VC-friendly format be defined in a profile? Absolutely. Airside Mobile had gone in a profiling direction like this at some point but now have a JSON-LD-ish implementation.

What about using PKCE with ICG? Alec will send his question to the list.

AI: Eve and Maciej: Look into structuring the Implementations page more, using our old questionnaire. Turn it into a Google form or similar?

Wallet → Relationship Manager profile

This name might not stick for long, but it's mostly converted over in the new spec text. This thing is a real client, to be used through whatever user agent is defined.

There is a "policy API" that the AS presents, and a "manage API" that the RS presents. So far it's suggested that these be OAuth-protected. Should the policy API be UMA protected? Should the manage API be OIDC protected? Where we defined the UMA protection API in UMA FedAuthz, we said in Sec 1.3 that OAuth is required for security protection of that API, but if identity context is required, OIDC is RECOMMENDED to get an ID token. That's one solution. Alec already has a placeholder for that kind of language just below.

Is it necessary for us to prescribe a lot about user experience in the fashion of what Open Banking has done? They have jurisdictional regulations and an industry context guiding them, and we have neither. This spec has no intention of standardizing anything about the interaction of an individual with the wallet/RM; rather, its purpose is to record policy through the policy API. (Etc.)

Is the form of the policy extensible, or is it fully specified? The intent is for it to be the former. It could be a little similar to our claim_token_format approach, e.g.

Attendees

As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)

1. Michael
2. Domenico
3. Peter
4. Gaurav
5. Eve

Non-voting participants:

• Tim
• Adrian
• Alec
• Scott
• Lisa
• Alexander Mense