This is a great list to add (to the spec or a use cases document).

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Sep 21, 2020 at 5:20 AM Igor Zboran <izboran@gmail.com> wrote:

To follow up my previous comment – you may be wondering why the hospital didn’t send an email with a link to the radiographs stored somewhere on the server. Here are the file-link-in-email issues:

    • expired, unknown, blocked, phishing or malicious link
    • masked link target using a URL shortener
    • content deleted
    • content updated – not the version you are expected
    • content changed – forgery
    • access control – UMA – not yet implemented
    • content encrypted – you need a password
    • link requires a signup or sign in
    • consent phishing attack

A lengthy list. You are buying a “pig in a poke” with each link to the file in the email message.

Documents, images, audios and videos must be an integral part of the email. The concept of keeping a recipient-owned-copy of sender’s resources is absolutely critical for documents and images with medical information. AEMS breaks down the email into individual resources, separately transfers them through the UMA channel to the recipient, where the integrity of the resources is checked using a hash function. You get what the sender sent you.

-Igor

On Fri, Sep 18, 2020 at 10:26 AM Igor Zboran <izboran@gmail.com> wrote:

Hi Eve,

thanks for putting AEMS on the WG-UMA agenda.

My initiative is not for its own sake. AEMS is a business-driven proposal. During my career as a solutions architect, I came across several business requirements that I had no idea how to fulfill them. Let's look at the first real case:

A German tourist broke his leg in Prague, Czech Republic. He was X-rayed and treated at a local hospital. The Prague hospital needed to send digitized radiographs – hundreds of MB – to his home hospital in Germany. The Dropbox service was not allowed to use, the physician couldn’t handle FTP and email didn’t work. Finally, the radiographs were sent on a CD by courier. If only AEMS had existed at that time.

To Sal's note: AEMS is far from just a “REST SMIME”. On the contrary, AEMS literally breaks apart MIME format and transfers email resources by its parts. Not only large attachments but all attachments and also the message itself are transferred separately through the UMA channel. That’s more flexible then the archaic (S)MIME format.

… and not a mail client but the Mail Fetch Agent (MFA) pulls all email resources, including the message. There’s another asynchronous action in an AEMS workflow. The first one is the UMA AS-sender, RS-sender, MFA-recipient interaction with respect to sender’s instruction and the second one is MFA-recipient, RS-recipient interaction with respect to recipient’s instruction. After that the email is ready to be shown in the recipient’s Webmail client. The recipient is not involved in the UMA process and doesn’t see the shared links. Both sender and recipient use email in the usual way. No links, just the message and attachments.

Igor

On Thu, Sep 17, 2020 at 4:58 PM Eve Maler <eve@xmlgrrl.com> wrote:

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-09-17

Minutes

Roll call

Quorum was reached.

Approve minutes

MOTION: Moved by Andi: Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23, 2020-07-30, 2020-08-06, 2020-08-13, 2020-08-20, 2020-08-27, 2020-09-03, 2020-09-10.

APPROVED by acclamation.

Thank you to Andi for his stalwart service!

Policy Manager extension spec

• Let's get formal about working on this spec
• Discuss adopting a timeline/schedule for it
• Its current name is Policy Manager, and it's described as an extension
  • It resides in GitHub
    • Please use GitHub issues with appropriate labels to raise issues with it
      • There is a new "policymgr" issue label unique to this spec but there are other labels you can use for further categorization
  • As a habit, please review the spec and try to provide major comments and questions in email ahead of calls

The status of this draft is "editor's draft". If the voting participants of the WG vote to approve it, it becomes a "WG draft". It could then proceed to various levels of Kantara approval.

Regarding our issue backlog, it appears there is a cleanup step we need to perform. Then we need to review them all for substantive issues we would like to bring forward from the backlog. We have a process for step 1 and we'll proceed to step 2 when we have backlog clarity.

AI: Andi and Eve: Work through the issue backlog cleanup step, reaching out to Alec and Kate as required. Andi will set up a call with Eve to start the process.

AI: Eve: Add descriptions to all of the issue labels.

Eve's promise to the WG: Agendas 24 hours or more ahead of time, highlighting what spec text has changed in that timeframe from the previous call. Eve's ask: Any issues/comments to be framed in terms of "being the solution": New text proposals, new sets of options, etc.

Our first formal issue, likely, should be scope. It's hard to decide a timeline until we decide that. The current draft only has the RO-AS component (policy API). Let's call that option 1. Option 2 would also include the RO-RS component (manage API). Option 3 would also include the cascaded AS component ("trusted claims"), where there is a hierarchical directive about claims collection. The policy languages could still be internal to each source and don't have to be standardized, but new set math would have to be specified around a new source that we can think of as "trusted claims".

AI: Alec: Put in a new issue around extension scope for policymgr label, using the three-option language and including the pretty diagram in the issue.

Authorization-Enhanced Email System draft

• Brief discussion of Authorization-Enhanced Email System: any next steps?

Igor's document (see this WG list email thread, ironically enough at several levels) is about, instead of sending large attachments through SMTP, pushing a link to an UMA-protected resource and having mail clients pull the attachments as UMA clients performing REST pulls.

Eve suggests trying to use some of the graphical patterns of the draft in our auxiliary materials because they would be particularly helpful for conveying the "trusted claims" concept, at the very least.

In the world of health IT, SMIME has been used/tried for secure messaging, with mixed results. Sal notes: It's a little like REST SMIME.

Let's refer to this as "AEMS" (authorization-enhanced mail system).

AI: Everyone who is invested in this type of use case: Please put together thoughts on how to make the case for solving it in this fashion and to whom to make it.

What to do about GNAP

Liaison question raised by Adrian. We've discussed this before; what action is being requested?

He provides a MyData Korea call doc link – the call is at 9pm ET tonight.

He also asks what our relationship is to UDAP. Let's put this on the agenda for next week; Eve will put thoughts together.

Attendees

As of September 3, 2020 (pre-meeting), quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve)

1. Michael
2. Domenico
3. Sal
4. Thomas
5. Andi
6. Eve

Non-voting participants:

• Alec
• Nancy
• Adrian
• Scott
• Kate Downing (OSS veteran, startup veteran, ex-Deloitte, available to help!)
• Vlad

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

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