https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-25 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-06-11 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-11 Deferred. Off-week meeting scheduling The winning time slot is alternate Thursdays (starting Jul 2) at 10am PT/12 noon CT/1pm ET etc. Eve will get the calendar stuff going. She will invite all of the voting participants and all of the additional participants who said they can make it at that time. Let Eve know if you'd additionally like an invitation vs. just subscribing to the calendar. Conformance test suite project This is a more formal project now, with a written proposal from Colin and a funding model. The project is happy to accept donations of resources of all sorts. Kantara webinar: looking for UMA participant Alec, Adrian, and Mike are willing to take part. Alec spoke first so he gets to determine the shape of our participation. [image: (smile)] Eve will put them in touch with Colin. New profiles - Resource definition profile status - Wallet profile We worked from the flows and diagrams in Alec's recent email https://groups.google.com/g/kantara-initiative-uma-wg/c/g9ajr1z9ZXQ. Alec has now added both Alice and Bob into the "new spiral" diagram. The RO delegates RS management to the wallet. The RqP now has a flow where they can release resources to the AS. The client is redirecting the RqP to the AS. Depending on how the delegation is managed, authorization can happen at the AS or at the wallet. Adrian asks: Because in his world (HIE of One) the wallet isn't necessarily online, what are the implications? The wallet in this control plane view needs to be online to write policy. So why have "choose wallet" as a dotted line and why not make this the default? Because their AS doesn't even have or need any claims gathering. This is Alec's challenge in generalizing what they've done to cover more use cases. We'll have to test the general-case design a bit. The setup text has some detail. It says "user" because it means either RO or RqP. The overlap with SSI is that there is personal key management. There are "furious conversations" currently about what it means to have an SDS wallet. Alice could have four choices for a wallet: 1. Wallet on smartphone, well secured 2. Custodial wallet, held by someone else with multi-signature capabilities 3. Cloud wallet of her own, built into an AS 4. No wallet, just a feature phone Thomas suggests describing control-pairs – "who controls what" – in each pair. (The "alt" boxes in the diagram are asynchronous setup stuff that either the RO or RqP could go through.) 1. AS starts claims gathering. ... 6. The wallet acts as a client to the RS. 9. The RqP themselves, not the wallet, logs in at the RS using a personal public key that they can sign JWTs with. They put resources under protection here. Thomas notes that the wallet becomes the control point for all the RS's and all the AS's. If someone wants to go offline for some period, they could potentially delegate a particular RS-AS pair for some resource to someone else to enable someone else to control it for them. This is very much akin to the business-legal "relationship management" model work we've done, with scenarios like having a data subject delegate control to one or more resource rights administrators. The responsibilities of the "community AS" are to keep the policies privacy-protected, and of the "personal AS" (which the wallet)... Attendees As of 23 Jun 2020, quorum is 5 of 9. (Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Thomas 3. Eve 4. Maciej 5. Mike Non-voting participants: - Alec - Anik - Adrian - Scott - Carlos - George - Tim *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl