https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-02-25
Minutes
Roll call
Quorum was NOT reached.
Approve minutes
Approve minutes of UMA telecon 2021-02-04, <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-02-04>UMA telecon 2021-02-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-02-11>, UMA telecon 2021-02-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-02-18>
Deferred
Pensions Dashboard, any updates
All positive. No major changes, IPR issues are progressing. PDP may contribute their profiles directly to 'Kantara' (ie not the WG) to avoid challenges with the RAND license
UMA continues to be required by the program
UMA/Email proof-of-concept
https://github.com/uma-email/poc <https://github.com/uma-email/poc>
How does this compare with existing 'secure messaging' products? This is made to ride onto of the existing SMTP/IMAP protocols. There is a POC/demo available here: https://www.federizer.org/ <https://www.federizer.org/>
Is there a path to having this attachment protocol as an extension to the existing SMTP protocol <https://tools.ietf.org/html/rfc5321>? Would have to work through IETF.
Do the two mail services both have to support the extension? likely yes, maybe need a discovery mechanism. If the recipient doesn't support could fallback from claims pushing to interactive claims gathering. However, this pushes the RqP authentication question as the senders AS would need to allow federation to the RqP email domain. This could use the 'Trusted Claims" profile, however there is no standard way that a mail server must authenticate the user? ie not all are OIDC providers. This would need further exploration.
Profiles Discussion, relationship manager
Three "real" use cases to design around
A resource server that holds Alice's data, however does not have an end-user authentication mechanism.
A resource server that can authenticate Alice (somehow), and wants to offer resource managed integrated in other client applications
FPX profile:
the RS offers an OAuth API to authenticate the end-user, the RS like (1) would federate to another IDP (Trusted Claims??)
PDP profile:
The RS offers an AT protected 'find' API. The AS, after getting Alice's consent, hits the find API with Alice's verified claims, packaged in the AT, at every registered Pension Provider RS. If the RS has pensions for Alice, it needs a PAT to start registering resources with. It "exchanges" the AT provided by the PFS with the AS for a RS-audience PAT. The RS can then register the found pensions.
Since the RS and the AS are in a secure eco-system and the RO is authenticated to the AS at the time of the resource discovery , the RS can use temporary credentials specific to the RO at the AS to obtain the PAT. It is proposed that the AS will issue an authorization token for use by the RS for grant type "urn:ietf:params:oauth:granttype:jwt-bearer" as in [RFC7523] Section 2.1
Can to two interactions use the same APIs mechanisms?
GET /resources → returns available resources for Alice
\{
as defined by UMA Fedz with the addition of an optional "authorization_server" attribute, which points to the specific AS this resource is currently registered with
}
POST /resource/_id/ \{ at_as: url_to_my_AS }
GET /authorization_servers → return list of supported authorization servers, either for Alice or in general
This is where the intersection between UMA (API based resource) and w3c VC issuance starts to work. GET /resources == GET /credential offers, POST /resource_to_as = issue me this credential. This also comes around to wallet = personally controlled UMA AS.
How can we design to support many Authorization Servers (ie a wide-ecosystem!)?
The PFS was built to not exclude many AS's. A AS's would be hosted out of the gate, however the expectation is towards the more "open-finance" model where many Financial Institutions would host an AS for their customers/users. The 'governance registry' (as specified in the report) and federated identity service becomes the common trust sources for the ecosystem. How woudl pension rsources previously registered at one AS, be moved to a second one? What if the AS is the 'gateway' to the service where Alice wants to make her pension available
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:
Micheal
Alec
Non-voting participants:
Scott
Ken
Ian
Anik
Nancy
Colin
Regrets:
Eve
Andi
