[WG-UMA] Draft Minutes for UMA telecon 2021-02-25

[Alec Laws]

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, UMA telecon 2021-02-11, 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

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

[Igor Zboran]

Thanks for taking the time to review AEMS. I learned a lot from the minutes. See my comments below:

    • AEMS is a real electronic mail system with a UMA Mailbox, it is better to compare it with the classic electronic mail system than with secure messaging systems.
    • AEMS allows a user with a single email address to work simultaneously with multiple distributed UMA Mailboxes (RSs). Healthcare UMA Mailbox at the clinic, government UMA Mailbox hosted in the .gov domain, business UMA Mailbox at acme.com, ... all addressable via one email address. The corresponding UMA Mailbox is automatically selected by email category. Think about it, this is the most valuable UMA/Email feature.
    • Don't focus on attachments, let's take it that AEMS can deliver any digital asset in any quantity.
    • AEMS is about UMA protocol and has nothing to do with MIME, SMTP or IMAP. This old stuff is only used as a means of sending and receiving authorization or registration emails.
    • The POC/demo available at: https://www.federizer.org/ is not ready yet.
    • Both the sender’s and the recipient’s mail services have to support AEMS. If the recipient doesn't support AEMS, there is a fallback mode. I'll explain this later when the proof-of-concept is ready.
    • There is as yet no reason to use discovery or federation mechanism.

Here be dragons, we can fight them :-)

-Igor

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma

[Igor Zboran]

The AEMS idea is now very simple. We have an UMA Mailbox – UMA email-specific RS – for storing email resources. User correspondence takes place between RSs via the HTTP protocol. The existing email infrastructure is only used to route system emails.

It took some time to clarify this. Thanks for your patience.

See the attached document.

-Igor

On Thu, Feb 25, 2021 at 8:04 PM Alec Laws <malcol...@gmail.com> wrote:

[Igor Zboran]

During the data transit from sender to recipient, AEMS uses the existing email infrastructure to ensure authenticity[1] of the authorization email, and the UMA protocol to control the recipient's access to the sender's email resources.

[1] https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

-Igor