[WG-UMA] Authorization-Enhanced Mail System

[Igor Zboran]

Hello UMAnitarians,

I'd like to ask if someone from WG UMA would be interested to participate in the Authorization-Enhanced Mail System proposal. Please see the attached document.
It is an early draft proposal I've been working on for over a month.

Please send your questions, comments and suggestions to the WG-UMA mailing list.

Regards

Igor Zboran

[Adrian Gropper]

Hi Igor,

I welcome your initiative and framing of the problem with email. We certainly are seeing new tech encroaching on email including Slack and text messages even as innovation continues around how to triage email into various levels of urgency. Slack is particularly interesting as it has now crossed over into Zoom territory. With the rapid pace of improvement in Jitsi and slower pace of improvement around ActivityPub, open source and open standard messaging will need the document integration features associated with the resources in your proposal.

From the protocol perspective, the relationship between messaging and access control to resources is currently undergoing a lot of innovation. In the self-sovereign identity standards (SSI) workgroups we have efforts like DIDComm that I will not attempt to explain to anyone as well as discussions of so-called service endpoints linked to decentralized identifiers. Notification and Authorization service endpoints seem likely to be standardized.

In the UMA group, the question of how to handle notification comes up every once in a while. Notification is necessary when the Authorization Server needs to ask the Resource Owner a question because the policies it has are insufficient for an autonomous reply to a request. Notification is also necessary when a Resource Server invokes the "Adrian Clause" and ignores or acts differently than what the Authorization Server expects.

Going forward, I see the need to converge the SSI standards and practices with the OAuth-y standards and practices (SIOP is well on this road already) and this will likely open new opportunities to consider the role of messaging (where identifiers are clearly first-order objects) relative to authorization (where resources are clearly the first-order objects). My work under the Gold Button flag is an attempt to merge authentication and authorization protocols into the same interoperability badge. Here are two links https://github.com/w3c/did-use-cases/issues/101 and https://docs.google.com/document/d/1kZ7_Skcn4zb3zOfEu7XZDrYAmLR1T_pbBoSk8AEfrSg/edit#

My question to you and our group is about RS-first vs. AS-first flows and how they might relate to the email-specific problem you are addressing in your paper as it relates to the broader issues of blending messaging with authorization that I describe above.

- Adrian

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

[Igor Zboran]

Hi Adrian,

Thanks for your comments. I didn't know about the self-sovereign identity standards initiative. I'll take a closer look at that.

To your question about RS-first vs. AS-first. It depends on the use case. In my case I would prefer to use both flows to cover a wider range of use cases; the flow instructions would be stored in incoming emails along with resource links.

UMA is great and I was pleasantly surprised at how UMA and the mail system fit together perfectly. I think it’s because UMA can protect email resources – files – without interfering with the existing email infrastructure.

What’s even more surprising is that there is the ubiquitous “UMA Relationship Manager” aka email-client where users (unknowingly) set up access to email resources in the "To", "Cc", "Bcc" fields. I know this because I’m doing this right now, setting up access to this message for you and all UMAnitarians. If you're reading this email, the UMA idea works :)

Igor

[Alec Laws]

Hi Igor,

This looks great! Really cool to see more use-cases for this policy/relationship manager extension

A lot of the points in your draft ring very true, both around phising links and more generally that attachment sizes have no kept up with demand.  The ability for mail clients to automatically protect resource access through UMA seems quite natural (as you show) and holds a lot of benefits. Especially since the attachment wouldn't go through SMTP and instead flows directly from RS->RqP

Many times I've had to a. upload a file to google drive b. using google's sharing mechanism, share the file with the recipient ( and only to other google emails?) c. include the link in the email. 

Apple even offers this type of service directly in their client, "mail drop"[1].

Best, 

- Alec

[1] https://osxdaily.com/2014/11/14/use-mail-drop-email-large-files-mac-os-x/

[Igor Zboran]

Hi Alec, It's nice to see the idea of UMA hidden within the email ecosystem waiting to be revealed.

Igor