https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-21 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-01-17 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-01-17> , 2019-02-07 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-07> APPROVED by acclamation. IETF contribution status and presentation prep - Commonalities/touchpoints between drafts (e.g. oauth-distributed, resource-indicators...)? - Ideas based on newer community concepts (sender-constrained...)? - Grant model concept (discussed here <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13> )? The contributions have been made. Some implementers have been indicating enthusiasm about supporting in-person. Maciej and Eve are looking into in-person involvement. Historical topics we should touch on: - The history/background of UMA1 (submitted to IETF and expired) - Dynamic client registration (submitted and influenced OAuth/OIDC) - The "design principle" of sedimenting content into OAuth (slideware exists for this, possibly in 2015) - EIC award (like the OAuth one) - Potentially privacy-protective capabilities of UMA (along with the business model layer) Other useful things to share, in order to contrast with other current work: swimlane flows that illustrate how it solves: - Alice-to-Bob consented sharing (which otherwise OAuth doesn't do) – many are on the cusp of solving it in a nonstandardized way - Alice-to-Alice sharing with centralized management of resources (which otherwise OAuth doesn't do) – point to discussion <http://blog.petrieflom.law.harvard.edu/2019/02/19/oncs-proposed-rule-is-a-breakthrough-in-patient-empowerment/> of laws/regs/rules for the "multiple portals problem" and its relevance to contexts of "open APIs" - Proactive, reactive, and silent Alice (data subject)-to-whoever and enterprise (non-human)-to-whoever sharing in a (relatively) compact single grant Will oauth-distributed <https://datatracker.ietf.org/doc/draft-ietf-oauth-distributed/?include_text=1> get taken forward? Dick has left Amazon and the use cases for this spec came from there. The draft has an AS discovery element and there was some list discussion about possibly leveraging UMA's existing mechanism. We could make a brief mention and point out how we do it. (Eve's presentation on UMA to the OAuth WG some months ago included this.) Cigdem also points out that AS discovery is supported in the ACE framework as well in IETF (ACE Core). It seems that AS discovery is popping up in several places. There are a few implementations. What about the divergence in concepts between UMA resources that get registered and resource-indicators <https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/?include_text=1>? Our RPT is pretty specific in what it contains, while this other draft just audience-binds tokens and forces downscoping and lets the AS do the mapping. Also, since UMA is client-to-RS-first and gets a permission ticket, this makes the purposes different as well; UMA is more capable in limiting the audience already. *AI:* George: Help with the resource-indicators section of the preso. We should also include the implementation status. Meeting logistics We will meet next week (*Thu Feb 28*). No meeting the following week (*Thu Mar 7*) due to the RSA conference. Attendees As of 18 Oct 2018, quorum <https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Cigdem Non-voting participants: - Alec - Colin - George - Lisa (new - welcome!) - Scott - Thomas - Nancy - Bjorn - Adrian Regrets: - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl