UMA telecon 2020-12-17

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://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2020-12-03, 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

Minutes

Roll call

Quorum was reached.

Approve minutes

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"), 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 is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Michael
Domenico
Peter
Alec
Eve

Non-voting participants:

Colin
Ken
Scott
Ian
Anik
Tim
Bjorn

Browser not supported