- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2020-01-14
by Alec Laws 13 Jan '21

13 Jan '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-14> Date and Time • Alternate-week Thursdays 10am PT • Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 • United States: +1 (224) 501-3316, Access Code: 485-071-053 • See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda • Approve minutes of UMA telecon 2021-01-07 • Pensions Dashboard. continue profile review • AOB Cheers, - Alec

1 0

Agenda for UMA telecon 2020-01-07
by Alec Laws 06 Jan '21

06 Jan '21

Happy New Years! https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-07 Date and Time • Primary-week Thursdays 6:30am PT • Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 • United States: +1 (224) 501-3316, Access Code: 485-071-053 • See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda • Approve minutes of UMA telecon 2020-12-03, 2020-12-10, 2020-12-17 • Pensions Dashboard profile review + next steps • Queuing up policy manager / reference definitions profile / "trust types" next steps • These discussions can help with our charter refresh thinking • AOB - Alec

1 0

Draft minutes of UMA telecon 2020-12-17
by Eve Maler 17 Dec '20

17 Dec '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-17 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-12-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-03> , 2020-12-10 <http://Approve minutes of UMA telecon 2020-12-03, 2020-12-10> Deferred. Queuing up Pensions Dashboard profile next steps (This description is legally non-normative!) Looking at the IPR policy for this WG ("RAND <https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=41025…>"), the contributions we make and the drafts we produce are licensed to each other for development purposes. Final specs ("Recommendations" that have been approved by the Kantara membership) are ultimately licensed to arbitrary parties in such a way as to enable faithful reproduction and implementation. The Recommendation stage reflects a process of 45-day IPR review. There may be timeframe pressures around getting to that final specification stage. And yet it's been observed that there is a potential design pattern behind the PD profile that could be valuable to capture as a "class" of which PD is an "instance". Healthcare might be yet another "instance". Notice that CIBA went through something similar, where FAPI and MODRNA ultimately became profiles in different sectors of the base spec. We might be able to factor out the common elements more readily having made the observation now. Getting the PD profile (essential as-is) into the form of an UMA Work Group output, as discussed last week, will help even if we decide to revise the profile subsequently. Speaking of CIBA, this profile could stimulate some additional discussion and work that we've never fully completed around the CIBA/UMA relationship. The UMA concept of PCTs could – Ian surmises – supplant CIBA given the PD profile approach. This is because step one enables Alice (same person as RO and RqP but strongly authenticated on RqP side) at the dashboard to vouch for herself. It seems like this could be true. In the past we have discussed additional/alternate mechanisms to solve this problem, such as an extension to UMA that leverages some proof or claim about Alice flowing over some existing AS-to-client channel that UMA already has so that Bob can be assured about her identity, without the "two-step" UMA dance of the PD profile. Peter's company has an UMA-like approach that involves identity documents (like passports) proving Alice's identity in use cases such as Global Entry. We've heard tell that GNAP could make Bob's self-proof for purposes of access to Alice's resources and Alice's self-proof for purposes of Bob's (say) auditing very symmetrical in their operation. Speaking of the potential for a common design pattern, in the PD use case, the motivation for the "step 1" was discovery and aggregation both. It has a "Pension Finder service". What might be the motivation(s) in other cases? Is this the test for whether the design pattern applies? This seems to relate to the relationship manager/policy manager work, which could be done with a "step 1" for Alice (that is, using UMA itself) in preparing her to share resources out to Bob ("step 2"). Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve) 1. Michael 2. Domenico 3. Peter 4. Alec 5. Eve Non-voting participants: 1. Colin 2. Ken 3. Scott 4. Ian 5. Anik 6. Tim 7. Bjorn *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-12-17
by Eve Maler 17 Dec '20

17 Dec '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-17 Date and Time - *Alternate-week Thursdays 10am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-12-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-03> , 2020-12-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-10> - Queuing up Pensions Dashboard profile next steps - Queuing up policy manager / reference definitions profile / "trust types" next steps - These discussions can help with our charter refresh thinking - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-12-10
by Eve Maler 10 Dec '20

10 Dec '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-10 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-12-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-03> Deferred. New Pensions Dashboard profile The profile was originally developed about a year ago and reviewed by a few UMA experts. The Pensions Dashboard Program leaders are studying the implications of the contribution path that's been taken. We are thinking it would be valuable to get the contributions into work streams that reflect the WG's intention to work on them soon, and so the editors are interested to put them into report/specification form as appropriate. A sample report looks like this <https://kantarainitiative.org/download/7568/>. A sample specification looks like this <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html> (but these would be editors' drafts initially, not recommendations). Style doesn't matter, just presence of metadata and correct headers and footers. The Operating Procedures <https://kantarainitiative.org/confluence/download/attachments/37750179/KI%2…> provide guidelines for publication and branding, and there are logos and templates <https://kantarainitiative.org/confluence/display/GI/Logos+and+Templates> that can be used. This will help WG members review the material in a familiar form. There may be a few changes forthcoming. Sal noted that "PDP" is an acronym that has multiple definitions, and could be misunderstood! It might not need to appear anywhere in the flows. There are a number of questions and issues embedded in the profile text. Ultimately these could be collected in GitHub. Charter refresh Our charter <https://kantarainitiative.org/confluence/display/uma/Charter> hasn't been refreshed in nearly two years. Nominally it's not too out of date and might just need a bit of brushing up. We've had ambitions about interoperability and conformance testing that haven't borne fruit, but the charter wording wasn't too specific. The PD work may require some interoperability testing. On the other hand, the work we've been doing on the resource definition, policy manager, etc. profiles seems pretty consequential for ensuring that the "negative trust" between RS and client can hold; it could be considered significant new UMA work. This, along with the PD work, seems significant indeed as a body of work. How much should this be reflected in the charter? Alec and Eve should confer a bit on this and come back with a recommendation. Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve) 1. Michael 2. Domenico 3. Sal 4. Thomas 5. Alec 6. Eve Non-voting participants: 1. Ken 2. Ian 3. Colin 4. George 5. Scott 6. Nancy 7. Vlad *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-12-10
by Eve Maler 10 Dec '20

10 Dec '20

Hope everyone can make it today. We’re still working on Pensions Dashboard next steps. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft Profile for UK Pensions Dashboards
by Kenneth May 07 Dec '20

07 Dec '20

All, Eve mentioned that she was expecting a new profile contribution to support the UK Pensions Dashboards Programme. This initiative is one of enormous ambition and has a real social purpose. Origo has created a profile of UMA to support the specific requirements of this use case. This was authored for us by Mike Pegman, who some of you may know. We are pleased to now contribute this profile to the UMA Working Group for consideration. We hope that the group is encouraged about the use of UMA in a project of national importance and international interest that will benefit millions of people. The draft profile we have supplied is a result of many years of collaborative work between Origo, the UK Government's Department for Work Pensions (DWP), the UK's Government Digital Service and others (including some UMA working group members) to develop and demonstrate the architecture. We are proud to have worked with Industry and Government stakeholders in developing a truly world-class solution using UMA. I have attached 4 documents. A short introductory Background document that describes the context. This also explains why we are asking the working group to accept and progress this contribution as a matter of some urgency. A Design Document to accompany the draft UMA profile. This document: * provides the context, rationale and explanations for the non-normative aspects of the Pensions Dashboard profile and the ecosystem digital architecture being proposed; * explains important design decisions; * provides guidance on what we believe is required from UMA vendors/implementers that will facilitate onboarding of pensions providers and in doing so create a market for UMA. The draft Profile Document with three sections: * Section 1 for the Pensions Dashboard UMA Grant draft profile; * Section 2 for the Pensions Dashboard UMA FedAuthz draft profile; * Section 3 for wider security considerations. There are sequence diagrams embedded in the Design Document to illustrate and explain each flow. If you would like to view / edit these separately then this can be done using the links in the attached Sequence Diagrams document. My colleague, Ian Muir, and I will join today's call. We would be happy to explain some of the history and background to the group. We look forward to speaking with you shortly. With best wishes, Ken Kenneth May Chief Architect Origo Services Ltd 0131 451 5181 0131 451 1152 (Direct) kenneth.may(a)origo.com<mailto:kenneth.may@origo.com> www.origo.com<http://www.origo.com/> E-mail disclaimer The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful. Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents. It is your responsibility to scan for viruses. Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control. When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited. If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender. The contents of this e-mail are protected by copyright. All rights reserved. Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 7 Lochside View, Edinburgh Park, Edinburgh, EH12 9DH Origo Services Ltd.<https://www.origo.com>

2 1

Agenda for UMA telecon 2020-12-03
by Eve Maler 02 Dec '20

02 Dec '20

I'd like to encourage people to attend this week's and next week's call if you can; we have an interesting new topic to consider, and these are our last two calls of the year. Talk to you soon! https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-12-03 Date and Time - *Alternate-week Thursdays 10am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-11-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19> - New Pensions Dashboard profile - Expecting a new profile contribution and proposal imminently - Closely related to our Pensions Dashboard use case from business-legal work (see slides 22-23 <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> ) - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-11-19
by Eve Maler 24 Nov '20

24 Nov '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-10-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-01> , 2020-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-15> , 2020-10-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-22> , 2020-10-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-10-29> , 2020-11-05 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-05> , 2020-11-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-12> MOTION: APPROVED by acclamation. MOTION: Moved by Domenico, seconded by Andi: The Working Group recognizes and appreciates the significant contributions made by the outgoing vice-chair, Maciej Machulak, to the development and progress of the UMA specifications. APPROVED by acclamation. Continue Policy Manager / Trust Model discussion and agree on use cases The discussion last week was about how UMA fits into existing trust models. Identos's motivation in developing the draft user stories was that having even more OAuth-like flows could promote adoption. UMA AS's have have trust schemes for all the parties but needs to have knowledge of the resource semantics. That's where the user story elements of "recognized standards", "resource types and scope", and "push RARs" come from. The last user story came out of a discussion with George. Alec has seen some work in GNAP around this, but it's difficult to do. With permission requests, there can be multiple resource IDs and scopes, and you may not know what RS they originally came from. It's a no-no to give a client a token that it can redeem in multiple places. The reason we care about this, since this would have been impossible in "regular UMA", is because we're inventing something new here: The client could request a resource by type, and that means all of the resources that satisfy that type could span resources. Reminder: We are enabling C → AS first. The "community AS" has become a virtual registry of resources on each RO's behalf that can cross RS's. (Shades of Liberty Discovery Service.) It's not just C → AS, it's actually enabling the RqP to do something new at the AS, and that's where we have higher-level user stories: *As RqP Bob, I want to be able to request access to a set of Alice's resources directly from Alice's AS without knowledge of their location, because I don't have to bother getting or caring about all the locations from Alice first.* *As client C used by RqP Bob, want to be able to request access to a set of Alice's resources directly from Alice's AS on Bob's behalf without knowledge of their location, because I don't have to retrieve the locations first.* Maybe there are more low-level/technical stories here to do with request_submitted and different ways of handling it, but we can deal with that later. In our 2020-11-05 call, three "models/degrees of freedom" were defined. The ecosystem gets further and further constrained with each choice. They function as profiling – and compliance – choices. There's 1) a *data model* underlying the API being used by the client (by analogy think of a "media type"); 2) the *authorization protocol* protecting that API, such as OAuth (by analogy think of a "scheme"); and 3) the *trust model* that actually constrains access by that specific client in making API calls using that authorization protocol (back to a CA). There is a persistent desire to get more distributed about that last one. Resource Definitions is one distinct deliverable we want to have. "Trust model" isn't a spec deliverable, but we think we should ponder the concept and see if it generates any (e.g.) security considerations for each new spec we do generate. As an example of walking through every (pair of) entities/parties, the old "binding obligations" spec shows how we did it back in the old days. Next time: Domenico's EU report (and UMA implications), and Alec's user stories docs. Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve) 1. Michael 2. Domenico 3. Peter 4. Thomas 5. Andi 6. Alec 7. Eve Non-voting participants: 1. Scott 2. Lisa 3. Tim 4. Colin 5. Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: no UMA WG call this week
by Eve Maler 24 Nov '20

24 Nov '20

This is due to the US Thanksgiving holiday on Thursday. (We’ll also have no call on December 24 or 31!) For those celebrating, hope you have a great holiday and a relaxing, healthy, and hearty long weekend. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0