UMA telecon 2020-07-30
Date and Time
- Alternate-week Thursdays 10am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar
Quorum was reached.
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:
- Identos FPX
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.
As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)
- Alexander Mense