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
On Thu, Feb 25, 2021 at 8:04 PM Alec Laws
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-02-25
MinutesRoll 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-04UMA 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
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 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
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 http://kantarainitiative.org/confluence/display/uma/Participant+Roster 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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma