https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-04 MinutesRoll call Quorum was not reached. Approve minutes - - Approve minutes of UMA telecon <http://Approve minutes of UMA telecon 2019-03-14, 2019-03-28>2019-03-14 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-14 Deferred IETF updates Further updates: Cigdem talked to people post-ACE group meeting about her UMA group involvement, and they were pleased. Ludwig and Hannes were positive. Our inclusion of desired next steps was good. Eve reached out to Hannes (OAuth co-chair) in email and they discussed. He mentioned that a next step for him would be to talk to the AD about a charter change and put out a call for adoption of the documents (presumably the UMA docs and other new ones) on the list. Pedro was on-site. The presentation was so detailed that it may have overwhelmed a bit. People may not have really understood the use cases and motivation behind it. Doing more work around this would really help. There are some solutions in other specs that have some overlap. In ACE there is the offset info piece. Should the mechanism align with the permission ticket, or not? Cigdem talked to Ludwig about it, and they were thinking that it's just different from UMA. However, the new AS discovery solution happens at the same time as UMA's permission ticket flow, and that could be interesting to look at. Hannes suggested that a specific draft on this particular communications path for resource servers/clients/tickets (or other). Some of our language continues to be confusing. Someone asked at the presentation why it was "RPT" (that is – *requesting party* token), and maybe we should have just called it simply "access token". Though George points out that we could consider it to have a somewhat different semantic: it has different contents, and it's strongly bound to more entities. Thomas adds: Because the token's entitlements (permissions) are targeted to a requesting party, it's important for the client to be able to reuse the RPT for access to multiple resources. The philosophical argument about calling it something same or different helping the case may be a different matter. The top most confusing topics: permission ticket flow and claims collection flows. - *Permission ticket:* In hindsight, given that we're seeing others with this use case/challenge, UMA is not so complicated. Torsten L presented this https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md... related to FAPI recently, and "Lodging Intent" relates to UMA – except it doesn't involve human interaction. The AS sends the RS to get claims from the client. See the last slide here https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-se.... Fine-grained or richer authorization requests, a la the Keycloak extension, are where they seem to be going. Call it "pulled claims" through the RS. - *Claims collection:* This is a great place to do a better job on the use cases, and maybe we can also add flowcharts and/or state diagrams – something along those lines! If we support our docs getting adopted, we would need to advocate for them. Those who, especially, are comfortable reading OAuth-related specs and commenting should strongly consider joining the OAuth WG https://tools.ietf.org/wg/oauth/charters(joining the list and being active) – and attending the thrice-yearly meetings – and advocating for the desired direction for the specs. If someone says it's possible to just take OAuth as it is now, maybe with a series of smaller specs, to solve the use cases we have, we might have to have that demonstrated to us to show that it's interoperable. IIW preparation Eve is going to "spell" George and is doing the UMA 101 session this time. She will revise the OAuth presentation and we'll improve along the lines we've discussed above. Any profiles/extensions work to consider in the short term Should we look at standardizing the Keycloak extension as discussed above, since it's a pattern that may very well be broadly useful? Sounds like yes. Also, how is the IDENTOS extension going? Is that something they would like to bring to the WG? Sounds like it's moving in that direction. Charter refresh discussion - The current charter https://kantarainitiative.org/confluence/display/uma/Charter as of 27 Feb 2018 Deferred. Planning upcoming business model work AI: Eve: Reach out to the lawyerly contingent to find out when they can attend and dedicate one or more whole sessions to this topic. Q2 meeting schedule - We are meeting *Thu Apr 4* but not *Thu Apr 11* (already cancelled). - Need to cancel *Thu Apr 25*. - Need to cancel *Thu May 2* due to IIW. - Need to cancel *Thu May 16* due to EIC. - Need to cancel *Thu Jun 6*. - Need to cancel *Thu Jun 27*. Come to the ZZ Auth and the Love Tokens (and others?) gig at the closing party! 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. Sal 2. Eve 3. Cigdem Non-voting participants: - George - Lisa - Nancy - Scott - Alec - Adrian - Thomas Regrets: - Andi - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl