...
- Approve minutes of UMA telecon 2021-01-07
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 profile?
- Implementor's draft >
- WG item(current status) > WG review and comments
- WG Recommendation(?) > External comments
- Kantara Recommendation "Kantara recommends this specification for adoption".
- From there other standards body would accept for 'standardization' eg Consent Receipts at ISO.
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 'Implementor's Draft' to participate 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 PFS service 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:
- Michael
- Peter
- Alec
- Sal
Non-voting participants:
- Ken
- Patrick
- Ian
- Anik
- Colin