https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-28 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-03-12 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12 , 2020-03-26 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26 , 2020-04-02 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02 , 2020-04-23 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23 , 2020-04-30 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30 , 2020-05-14 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-14 Deferred. If someone has a question on the spec What should they do? They can ask on Twitter, if they're on Twitter. That's what we suggest on the FAQ http://tinyurl.com/umafaq. Eve has answered a number of questions there. They can also ask on GitHub. It's a standard category. In the past we added README, LICENSING, and CONTRIBUTION pages to be sure people are aware of the IPR implications of things like pull requests. We should be encouraging people to become participants if they want to get active in actually discussing the specs. Profiling work - Resource description profile status See Alec's flows and nascent profiling text. The resource registration API in his case isn't much used because of the "static" method of resource registration. The profile would probably want to spend a little time discussing static vs. dynamic registration (or however we want to describe this). In his use cases, it's mostly static, but maybe in more general usage, dynamic could end up being used more often. The text suggests that the type field is either required, or the RS has to POST against the AS-broadcasted type. Types come from "semantic APIs", meaning open APIs or their enterprise-standardized equivalent. An example might be FHIR R4. In other words, AS's don't standardize them themselves but they serve as a kind of community repository for them. The addition of resource_location is the key change here. It drives how the AS can tell the client where to go at the RS. It's suggested to be optional, because maybe all three parties "know" (are provisioned with the knowledge) beforehand, but this is the in-band way of doing it. Adrian has submitted a use case https://github.com/agropper/secure-data-store/blob/master/COVID-19_Health_Re... and sequence diagram related to this type of scenario to the DIF Secure Data Storage group https://identity.foundation/working-groups/secure-data-storage.html, which is trying to achieve something similar. This profile's concept of the ticket is that it is a "capability ticket", and it's believed that it doesn't have to be rotated for security; it can be reused. This makes it not like a nonce but more like an access token. It's literally a capability, in other words. Should an access token actually be used instead? Hmm. It would need something like "profile" scope. - Wallet profile options See the two attachments to these minutes. The wallet-component.png attachment https://kantarainitiative.org/confluence/download/attachments/129565246/wall... shows a kind of blending of SSI and UMA worlds in our "spiral". The wallet-sequence.png attachment https://kantarainitiative.org/confluence/download/attachments/129565246/wall... shows a swimlane. But there are some questions. Where are Alice and Bob? What is the verifier role – is it used in the typical case? Adrian's use case document linked above starts to illustrate a similar blending. The intersection point is where each actor gets to choose (and change, if they want) their AS. We have, in the past, looked at "cascading authorization servers" (see issue #260 https://github.com/KantaraInitiative/wg-uma/issues/260, proposed by the VA – though it wasn't strictly intended to empower patients). This profile is intended to enable more choice. Adrian's use case has a notion of a trusted community server that can be overridden by the personal AS. Conformance testing project update Involved folks should plan to meet next week, our off-week from the biweekly WG meeting. AdvCIS update Sal will share with the group about UMA Soup. [image: (smile)] Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Sal 2. Domenico 3. Maciej 4. Eve 5. Mike Non-voting participants: - Scott - Andi - Alec - Adrian - Tim - Anik *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl