Child pages
  • UMA telecon 2021-01-07
Skip to end of metadata
Go to start of metadata

UMA telecon 2021-01-07

Date and Time


  • 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


Roll call

Quorum was reached.

Approve minutes

MOTION: Approved

Identiverse Call for Presentations

Closes TOMORROW, Friday 8 Jan 2020. Would be great to see some proposals around the new extension/profile work. George has submitted a couple already

Healthcare News

Nancy has submitted comments to the CMS 9123 RFI Request for Information (now closed). This RFI was raised by the PP2Pi workgroup, including legal/policy/business. Included all Kantara workgroups, and highlighted UMA, and the new draft works around consent wallets for UMA, NIST and consent receipts. Looking to share more with CMS/ONC/HHS to keep UMA in their authorization conversations. How can we continue to share this message with them? 

Lumedic? has reached out to Colin around assurance and the relation to the TOIP (trust over ip) work. Looking to define assurance requirements for this new decentralized solution. Specially NIST 63b (authentication) has additional challenges in a decentralized architecture. IDENTOS has seen the loosely coupled nature of the UMA matches well with the SSI model. UMA can provide the assurance/implementation to meet existing assurance requirements. 

Nancy notes that most UMA implementors have implemented all roles/components. Wonders if interop testing could be done at a component (vs entire solution) level. Colin, most of the time determining the security/privacy/assurance of a solution happens at the gaps/interfaces between components.

Are there specific "implementation" profiles required for healthcare? This is an interesting contrast to the Pension design document and UMA profile, which gets into complete e2e descriptions of flows and system interactions.

Pensions Dashboard profile review + next steps

No large update on the Profile process with UK Gov. Profiles have been re-templated for Kantara with appropriate headers and license, no longer a blocker to the RFP process. We can expect some update to the Profile to come from the profile itself. 

AI: Alec/Eve to upload the new templated profiles (add/replace the current upload on Third-Party Profiles and Extensions)

Will the procurement be limited to UK companies only? Ian believes it's open to the world. TBC as the procurement process changed recently given the evolving UK/EU relationship. The procurement will be for the build of the Pension finder service, the UMA Consent and Authorization Service and the Governance Registry components from the design document

There will be a number of dashboards: banks, and one provided by the Program. A user will start their journey at a Dashboard.

The Pension Finding service orchestrates the find request against the registered Pension Provider systems. This component is out of scope of the UMA profile. Before running the find request, the PFS first verified the ROs identity with the AS. The AS federated authentication to other ID Services. When the PFS finds resources, it asynchronously tells the dashboard the location. After the find request, the PFS is no longer needed.

The dashboard never receives the 'verified' identity attributes and is not 'trusted'. User ID attributes from the ID Service → UMA AS → PFS → Pension Provider. The UMA AS links a Dashboard provided identity to the 'verified' identity. The AS will use a PCT to provide the dashboard the ability to retrieve many Pension Dashboard resources without sending the RO through interactive claims gathering each time. 

Ian suggests that maybe a second review call for the profile could be setup outside the weekly WGs calls


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


  1. Andi
  2. Domineco
  3. Michael
  4. Alec
  5. Sal

Non-voting participants:

  1. Ian
  2. Nancy
  3. George
  4. Colin
  5. Tim
  • No labels