UMA telecon 2020-04-30
Date and Time
- Alternate Thursdays 6:30am 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
- Approve minutes of UMA telecon 2020-03-12, 2020-03-26, 2020-04-02, 2020-04-23, 2020-04-30
- Profiling (and turning it into projects)
- Conformance testing project update
Quorum was not reached.
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.
As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)
- Stephen Payne (solution architect for ForgeRock, focusing on healthcare in west, central, Rocky Mtn)