Quorum was not reached.
Adrian has news to share; see his document. Eve has been working on an article with Lisa L on consent, and they have struggled with the lack of concrete flows in decentralized identity for consent. George concurs with the lack of concreteness out there; it's a problem for interoperability with DID methods to date. Adrian notes that there is an open meeting planned for tomorrow to discuss (meta-discuss?) how to get started in bringing all the various streams of work to standards bodies. Resolving DIDs and telling wallets what VCs you want and other use cases will rely on commonality communications. It's possible to build POCs to illustrate concepts, but it doesn't build ecosystems.
We walked through Adrian's document. It focuses on the Alice-to-Bob use case to keep things simple (UMAnitarians are very familiar with that). Alice-to-Alice is just a subset. MVP (minimum viable protocol) is represented by the "narrow waist" of the hourglass. Slide 5 introduces an UMA mapping to the entities. Slide 7 makes the resource owner their own issuer, interestingly. The hot conversation in the decentralized community is the two data storage options on slide 8; the bold elements are the complementary strengths on either side, the goal being to not be stuck with just Apple or Google as the wallet choice.
Some discussion ensued about the larger ecosystem/adoption questions surrounding how to privacy-engineer personal data choice and control. Eve shared Bob Blakley's remarks from TechVision Chrysalis on decentralized identity about wallet binding/"evil Alice" concerns (which Eve supported contemporaneously).
Eve described the OAuth 2.1 proposal from the IETF 106 OAuth 1 session and its enthusiasm for code+PKCE (and a further set of protections). George is concerned about this being insufficient for mobile wallet-binding protection. Adrian echoes this concern. How to ensure trust when talking to the correct client (instance, not just class)?
Currently, RAR (along with PAR) is designed to be a relatively lightweight extension on top of today's OAuth. In OAuth, Alice is sent to her bank/ASPSP (AS) to authorize or deny the transaction. In UMA, how would the AS know how to let Alice set her policy, which would be the equivalent operation? That's why we had a resource (and scope) registration step ahead of time. The fact that pre-registration was in the RO context was beneficial (essential) for the various parts of the flow/token ecosystem of UMA. But maybe we can use the RAR JSON data structure to inform our registration step. George says he's "stealing" that structure for what he calls transaction tokens, for internal microservices management.
As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)