https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-03-14 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-14 , 2019-03-28 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-28 , 2019-04-04 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-04 , 2019-04-18 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-18 , 2019-05-23 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-23 , 2019-005-30 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-30 Approve minutes of UMA telecon 2019-03-14 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-14 , 2019-03-28 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-28 , 2019-04-04 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-04 , 2019-04-18 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-18 , 2019-05-23 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-23 , 2019-005-30 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-30: APPROVED by acclamation. Meeting times and upcoming schedule Peter is checking his schedule to see what he can do about joining us. But hey, he's here today, so we can hope. We're off *Jun 27* (Identiverse) and *Jul 4* (US holiday). Business-legal framework people: Also please note that we're off *Jul 2* (chair vacation). Continue IETF 105 and OAuth.XYZ/transactional authorization discussion We need to decide our plan prior to IETF 105, being held in Montreal Jul 20-26 https://www.ietf.org/how/meetings/105/, ideally by this call. We haven't asked for an agenda slot at this point. Our past data/analysis about going the Independent Submission route is in our 2015-10-15 UMA WG telecon minutes https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-15 – please read! We're pretty concerned about mitigating risk of UMA2 changing in some kind of backwards-incompatible way. This is a key reason why the appearance of "XYZ" on the scene has made us do some rethinking. If there is interest in a bigger rethinking of OAuth2 (which could take some time), we might want to rethink UMA2 only on that time scale. In the meantime, there are some interesting UMA2 profiles and extensions floating around. The interesting work in IETF happens either at the three F2F meetings or on mailing lists. If we were to turn to an Informational RFC path, that's not a "dead end", in that it could be updated with new versions as we see fit (the authors, not work group product). Is the Alice-to-Bob use case worked on at all in IETF? Maybe the ACE WG is the only place, but the normative specs don't really go there much; the Actors and Use Cases specs have some material (see here https://tools.ietf.org/html/draft-ietf-ace-actors-07 and here https://tools.ietf.org/html/draft-maler-ace-oauth-uma-00). The UMA WG may be frustratingly (nearly) unique in this. Then again, e.g. in healthcare (signs around the ONC Interop Forum https://www.healthit.gov/news/events/interoperability-forum-3), there seems to be a new realization that there is little standardized other than UMA to help with Alice-to-Bob. What we've observed in other standards is that 5+ years are needed for true deployment depth. SDKs, other deployment tools, profiles, extensions, and other enablement tools are the best thing to help. JP notes that transition into OAuth has been slow. UMA1 came out in 2015 and UMA2 came out in 2018, so changing things is risky. Awareness is only just starting. What we recommended at IETF 103 was: - We propose for the OAuth WG to adopt the UMA2 specs as work items - Operational interop and business model work currently continue at Kantara - The UMA WG can continue technical profiling and/or work out transition efforts as required - We can figure out WG-WG liaisons/communications; there are several mutual participants Having contributed two I-Ds, we could do the following: 1. Let the specs expire and do nothing else (beyond telling the OAuth WG chairs that we rescind our previous proposal) 2. Decide to do an independent submission and go for an informational RFC instead in the Security Area 3. Talk to the Application Area Directors and consider starting a new UMA Working Group at IETF 4. Continue with our previous proposal – this one is clearly out Are there any pros to option 3? We don't think so. The question is: Do we want the IETF community to work on UMA, or not? (Or: Do they show any signs at all of wanting to work on UMA?) IETF seems to specialize in security. What privacy work it does is strictly around DNS at the moment. OIDF is focused pretty closely on authentication of identity. Kantara does a lot around privacy of identity/ies. We're working way up at layer-7 privacy (and selective sharing). A security review from the ADs could be helpful, so we're inclined towards option 2 at the moment. We could further discuss that while still taking action to tell the OAuth WG chairs about our decision not to press ahead with our previous proposals (action item for Eve). Attendees As of 19 Jun 2019, quorum https://kantarainitiative.org/confluence/display/uma/Participant+Roster is 6 of 10. (Domenico, Peter, Sal, Rich, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Peter 2. Rich 3. Thomas 4. Maciej 5. Eve 6. Mike 7. Cigdem Non-voting participants: - Adrian - JP Rowan (Auth0 - consultant to clients - previously at JanRain - met Eve at IIW) - Colin - Alec - Bjorn - Nancy - Lisa Regrets: - Domenico *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl