UMA telecon 2020-04-23
Date and Time
- Alternate Thursdays 6:30am PT (this meeting was moved from Apr 16)
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
- See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar
- Should we meet next week? It's virtual IIW
- IDENTOS extensions
Quorum was reached.
Meet next week?
Yes, let's meet next week. IIW is creating session times across the globe so people in different locations can join.
Alec's questions for the "resource definitions profile" are: What are the next steps? He hasn't prepared anything today for the "wallet profile" (they consider it as potentially an SSI wallet, doesn't have to be, but it's an OAuth client type that can evolve).
The first step in determining fully if/how we want to take up the first profile is: What are the use cases we want to solve?
The increasing "horizontalization" of use cases, where vertical sector use cases mix together (as in payments and health care), might encourage us to take up a profile in this area so that it can help open APIs in different sectors work. Eve showed a map of global open banking (lowercase) efforts. Alec noted that some people refer to "client-directed banking" to avoid talking about any specific jurisdiction's effort.
AI: Alec: Propose different use cases he has seen, including in open banking.
How important is it to include delegation use cases (requiring UMA) in open banking/client-directed banking from the get-go? We've had these discussions, and there has been little motivation. Typically the motivation has been to solve security and very minimal consent use cases as a base layer, and that's been the focus for the last three years. Who here is involved in open banking efforts? Mike, Eve, Alec, George keeps one eye on it.
AI: Eve: Find and share our old UMA ecosystem design patterns document.
The language around consent vs. delegation/directed sharing/(something) is coming up more and more. Eve tried for a long time to connect UMA to traditional (opt-in/opt-out) consent. "Consent directives" in healthcare is the only line that can be drawn between (e.g. proactive) asynchronous sharing and "consent". It's possible to implement traditional consent flows, a la OAuth authorize/deny, with UMA, but you get more value out of the UMA version if you are (e.g.) loosely coupling the AS and RS. UMA enables licensing on the RO's terms. We haven't defined the terms. Lisa points to the licensing spec work of IEEE P7012. Mark suggests we check out a great eConsent video by Meg Doer. Thomas notes that the word “consent” needs to be qualified, just like "trust".
Mike worked with Michal, who prepared the demo for Identiverse 2018 that Mike showed. Michal could be available to build a test suite. Gluu is willing to host it. Here are the top-level requirements:
- Test harness in an OIDC test harness style
- Produces "red light/green light" types of answers for particular test assertions
- Could be considered unofficially to be testing "self-service conformance", until we decide it's official
- Tests AS interop at first, then eventually RS interop, then client interop
Nancy suggests doing a connectathon. Some comments on that approach: It can tend to be expensive to participate, and the challenge is that the API chosen is specific to the industry.
Colin has some ideas for building funding ("up" or "down"). Mike believes the test harness shouldn't be as bad as OIDC since there are fewer conformance profiles and options in UMA. Eve is a bit concerned about the fact that UMA sort of incorporates OAuth in a sense, but maybe we can carve out and "not do" pure OAuth testing, or alternatively entice others into covering that part.
AI: Colin, Alec, Mike, and Eve to meet some time prior to next week's UMA WG call to do UMA interop wrangling.
As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike)