Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

UMA telecon 2021-01-14

Date and Time

Agenda

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

Pensions Dashboard process questions and current status

Kantara templated versions of the profile and design document are now uploaded here. 

What is the WG program to review, and eventually ratify the UK Pensions Dashboards Profile?

  1. Implementor's draft based on the contribution accepted by the WG in December 2020>
  2. WG item(current status) > WG review and comments
  3. Draft Technical Specification/Recommendation > External IPR review and comment period (disposition of comments, and a second IPR review and comment period if substantive comments require normative changes etc).
  4. Kantara Recommendation "Kantara recommends this specification for adoption" following an All Member Ballot to approve it to this stage.
  5. From there, other national or international standards bodies could accept it for 'standardization' as was the case for the Consent Receipt specification into ISO/IEC 29184. 

How does this review process normally occur?

The documents should be added to our UMA Github (word format is fine) for version tracking and for issues/questions and comments to be opened against them. 

The Pensions Dashboard Program has some pending changes against the drafts, and must join the group as a member in order to become the lead Editor of the documents. 

Should the profiles be generalized to not be specific to the Pensions Dashboard use-case?

No, there's no requirement for this right now, the document is an 'Implementers Draft' to facilitate participation in a specific UMA environment/ecosystem. Useful elements of the profile can be pulled into profiles afterwards

Pensions Dashboard profile review

Some upcoming changes, The Pension Finder Service (PFS) may not receive the user information, instead the PFS may be 'merged' with the responsibilities of the AS. Consent to find pensions is recorded at the UMA AS. 

UMA interaction 1: resource registration

How is the PAT being issued, there are RO specific PATs however the RO is not inline with the PAT issuance? (check design document near the end) Does the RS use the token passed to it from the PFS to create a PAT with appropriate context? The PP is acting as a RO, however it creates a unique PAT for each RO.

AI, Ian will provide some additional details around the PAT issuance

UMA interaction 2: resource access

There are two main delegation cases. A) Alice → registered financial provider, B) Alice → "unregulated" guidance person. There is only "read-only" access at this point of the program.

Normal UMA flows, the RqP provides the dashboard with the URI of a registered pension resource. For Alice to delegate access, she interacts with the AS to create a permission for the financial provider to access that specific resource. Alice may be able to search for and identify the correct Financial provider using the existing financial provider registry and IDP.  The delegation could be modelled as a consent receipt at the AS. 

Identity and Delegation:

The AS federates to at least two IDPS, 1) Citizen IDP, IAL login and attributes for Alice 2) Advisor IDP, login and attributes for Bob
When Alice delegates a resource, she must provide enough information about Bob such that the AS can match the permission to Bob's ID at the Advisor IDP service

There is a youtube video demonstration to help make this more real (link to be found!)

Attendees

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

Voting:

  1. Michael
  2. Peter
  3. Alec
  4. Sal

Non-voting participants:

  1. Ken
  2. Patrick
  3. Ian
  4. Anik
  5. Colin


  • No labels