UMA telecon 2021-03-04

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

Agenda

Approve minutes of UMA telecon 2021-02-04, UMA telecon 2021-02-11, UMA telecon 2021-02-18, UMA telecon 2021-02-25
ONC Annual Meeting, UMA Content For a Virtual Booth
Pensions Dashboard, any updates
UMA/Email proof-of-concept
Profiles Discussion, relationship manager
AOB

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

Approve minutes of UMA telecon 2021-02-04, UMA telecon 2021-02-11, UMA telecon 2021-02-18, UMA telecon 2021-02-25

Deferred

ONC Annual Meeting, UMA Content For a Virtual Booth

https://www.healthit.gov/news/events/2021-onc-annual-meeting (free registration for attendees)

March 29-30. If you're interesting in helping at the booth or there's any UMA content that you'd like shown related to healthcare use-cases, please reach out to Alec

Not clear exactly how the booth works at this time, eg what content we can upload or when we need to be 'available'.

Maybe a very short demo (5mins) would works well, advertise as a reason to visit the booth.

Pensions Dashboard, any updates

Very close, all good news. Have a path forward to address any IPR/license concerns.

General question, would Kantara be on the hook for any vulnerabilities caused by profiling or implementations? In dashboard use-case, risk is a Bad user can see Alice's pensions data. Aside from the 'risk profile' of the use-case, the protocol was what is being 'relied' on to secure the resources. However, the protocol creator can't(?) be liable and our license should protect Kantara and the UMA WG(?). The responsible party is the operator or implementor. The protocol can't cover all use cases, and this why best practices and implementers guides are provided in addition to the core specs.

The current licensing conversation is about confirming that Kantara and/or Origo can't prevent the open use of UMA and the specific profile by the implementors in the Dashboard Program. Kantara need to balance that need with our needs to protect ourselves from the above. There are specific objections to the RAND policy.

Should UMA consider changing its IPR? Quite difficult to do for an open group given all the previous contributions. There has been some 'transfer' of ownership between Kantara WGs with different IPR policies (RAND → NAC(?)). Had to get all the contributors to the original WG to agree to this.

Is there something Kantara can do to better support this program (and hopefully all the new UMA WG members)? For example, revive the UMA test-suite conversations? Part of the challenge with the UMA test suite is how broad the cases are, maybe a test suite around this specific profile reduces that scope to get this off the ground. There is a demo AS that implements a proof of concept of the pensions dashboard (~2018), any further assistance that could be offered to the PDP would need to be based on the new iteration of the profile. However, this would be a first step to build a PDP RS conformance suite? .Our test suites should have specific 'modes' for the different profiles (HEART, PDP)

UMA/Email proof-of-concept

https://github.com/uma-email/poc

Igor was able to respond to some of our questions from last week: https://kantarainitiative.org/pipermail/wg-uma/2021-March/006124.html

Profiles Discussion, relationship manager

Is there any purpose for a single RS to be protected by many ASs? For different RO's: yes.

Is there any purpose for a single RS to be protected by many ASs for a single Resource Owner? These use-cases are more 'theoretical', and there is no limitation in the core UMA design. Maybe the RS would only support specific AS's for certain resources (eg high sensitivity)

How would a RS get a RO specific PAT in this mode? RS must be a client of the AS. PAT protects an 'offline' API, so there is preference to a long-lived token to reduce the frequency that Alice must re-establish the relationship. The more AS's a RS is registered at for Alice, the more she'll have to re-establish the PAT.

PFS@AS → RS: AT, access token with demographics (JWT) Is this a discovery mechanism at the RS?
RS → AS: POST /token body = AT
AS --> RS: PAT

So in this use case, the AS "tells' the RS to get a PAT.

Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

Alec
Eve
Michael
Domenico

Non-voting participants:

Nancy
Scott
Tim
Ian
Colin