https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-21
Minutes
Roll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2021-01-07 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-07>, UMA telecon 2021-01-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-01-14>
Sal moves to approve. MOTION PASSES
Pensions Dashboard status update
Still working through IPR issues, this prevents the PDP from opening their procurement. The Pensions Dashboard Program is still planning to contribute some initial updates to the Origo contributed profiles. One option being explored is a separate Kantara WG for the purpose to working on this profile, that has a different group IPR policy. PDP wants the profiles to be open, so that there are no barriers for suppliers/vendors to implement
Sal notes there always seem to be IPR issues at some point. Changing work group IPR is hard, as the effect on previously created documents is not clear. There is some recent precedent with the proposed ANCR (advanced notice and consent receipt) WG with a different IPR policy from the ISI WG.
LC Speakers Corner topic
There is a new Kantara initiative to have a new once a month session where a WG can share a topic with the wider Kantara community and receive feedback/input. The first session is tentatively scheduled for Feb 17 at 11:30 ET. UMA is up first!
Two current work items to be shared are the UK Pensions Profile and the Wallet profiles
If there are other topics that group members are interested in sharing with the wider Kantara community. Please reach our to Alec or the mailing list!
There was some work on delegation within UMA done by Eve/Lisa that would be interesting to heard at our UMA WG. This would also be a great topic to share more widely with Kantara to get more input
UMA + US Health Care Update
There are some US Health care initiatives looking at decentralized consent. There have been many issues raised with sharing 'consent' between system, specifically in sharing the PHI inherent in any consent record. Instead of 'federated' Sal suggests a 'decentralized' approach which may address some of the sharing of consent. In UMA, the consent record isn't shared, the decision or outcome is. With a 'consent repository' what could be shared is a 'pointer' to the consent, similar to a resource uri, and proper authorization would need to be attained before seeing the content of the consent record. The FHIR consent resource has PHI like all FHIR resources, however the authorization/sharing of 'other' FHIR resources is often dependant on the existence of a Consent resource. The UMA AS or wallet model protects the consent and separates it from the protected resources, however, the pure UMA model get's into multiple ASs hosted by many health care sites, the Person must then manage consent many places. UMA and
UMA + Standard OAuth mix-up attack and mitigation
There is a new IETF Draft (OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response <https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00>) to standardize of the Mix-up attack mitigations. Our current Implementer's Guide references the OAuth BCP <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.4> as additional considerations for UMA implementations. Should we reference this new draft?
Mix-up only relevant where an RP talks to many Authorization Servers, ie a wide ecosystem where a client is introduces dynamically to new AS's. The main mitigation from the BCP is to use a unique redirect uri for each AS. The new draft allows reuse of the callback, by adding a new `iss` param only the callback which the RP must compare to their expect value, ie where the sent the user for authorization.
No major impact on UMA. Alec will update the UMA implementors Guide to reference this new draft to help people find it
AOB
Ian has a topic for next call around FAPI/UMA
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)
Voting:
Sal
Domenico
Michael
Thomas
Alec
Non-voting participants:
Ian
Ken
Nancy
Scott
George
Tim
Best,
- Alec
UMA telecon 2021-01-21
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 2021-01-07, UMA telecon 2021-01-14
• LC Speakers Corner topic
• Pensions Dashboard. continue profile review
• AOB
Best,
- Alec
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
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
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>
