UMA telecon 2021-02-25

Owned by
Alec Laws
Last updated: Feb 25, 2021
3 min read

UMA telecon 2021-02-25

Date and Time

Agenda

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

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

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/ 

Is there a path to having this attachment protocol as an extension to the existing SMTP protocol? 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

  1. A resource server that holds Alice's data, however does not have an end-user authentication mechanism. 
  2. 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 is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

  1. Micheal
  2. Alec

Non-voting participants:

  1. Scott
  2. Ken
  3. Ian
  4. Anik
  5. Nancy
  6. Colin

Regrets:

  • Eve
  • Andi