Adrian; I think it is the case that one of the comments in the document calls for a discussion/review of the viability of the BLT metaphor for UMA. When I wrote the first draft I used BLT, but on reflection the layers appear to me to be RLT not BLT: *Regulatory: **Involuntary constraints of data flows* imposed by law or regulation on personal information data flows and UMA endpoints. The actors at this level are variously data protection authorities, data subjects, data controllers, data processors, data custodians, third parties and so on depending on the particular regulation. The purpose of this layer is to identify accountabilities and responsibilities related to consent (or other authority), breach notification, cross border data flows and other non-technical issues. *Legal:* *Voluntary constraints of data flows* set out between two or more parties that are participating in one or more of the UMA endpoints. That actors at this level generally the individual or corporate entities that are the operators of the UMA endpoints (RO, AS Operator, RS Operator, etc). The purpose of this layer is to establish the trust relationships between the endpoints of the data flows that are being technically authorized by UMA. It may be the case that this “L” subsumes the “BL” in the BLT model. *Technical:* The UMA Specification. Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john@wunderlich.ca On 4 July 2016 at 14:55, Adrian Gropper <agropper@healthurl.com> wrote:

I'm sorry that I had to miss Friday's call. I just had a chance to read this UMA Legal Primer and I find it inscrutable even as I'm finding the discussions in HEART more confusing week by week. Here's an alternative suggestion:

Let's start with "UMA adds three dimensions of variability to OAuth: - Multi-party (Are clients registered with the AS or the RS? does it need to be both?) - Asynchronous (Alice can start by just delegating and add policies only after she gets some insight into what the Bobs want - forces us to focus on delegation) - One delegation / location (Alice's authorization server is not domain-specific - neither should the legal agreements between RS and AS be domain specific.)

Let's focus on these three dimensions from a legal perspective. The BLT approach does not help. Neither does mentioning HEART help because HEART is even more confused than UMA. Once we get the Legal 3-D core down, a discussion of Business and Technical impacts on the Legal core might be unnecessary or just illustrative.

Adrian

On Fri, Jul 1, 2016 at 1:22 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

I vaguely thought there was a conflict on my calendar for next week, and just realized what it was. I'll be removing that meeting from the calendar. In the meantime, no reason not to go into the Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> to comment!... And if you have a burning desire to set up an alternate time to meet, let me know.

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

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

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

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

-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

I'll field these two important messages in turn. Please see below. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Jul 4, 2016 at 12:55 PM, Adrian Gropper <agropper@healthurl.com> wrote:

I'm sorry that I had to miss Friday's call. I just had a chance to read this UMA Legal Primer and I find it inscrutable even as I'm finding the discussions in HEART more confusing week by week. Here's an alternative suggestion:

Let's start with "UMA adds three dimensions of variability to OAuth: - Multi-party (Are clients registered with the AS or the RS? does it need to be both?)

Remember, this entire document is pitched to a less-technical audience. The text here is in direct reference to just-previous text: "The OAuth standard -- on which UMA is based -- already lets web and mobile apps collect permission from individuals to connect up to services as long as the apps are used only by the same individual (that is, it’s all about Alice, not Bob in addition)." ... "Multi-party: Alice can share access not just with apps she herself uses, but with other parties, such as Dr. Bob and Carlos." Your question about clients being registered is "PhD-level UMA". We haven't built up enough of the story for it to make the slightest sense, and in fact it's completely unrelated to the point. "Multi-party" means "Alice-to-Bob sharing". I'm pretty sure we'll never get to the subtleties inherent in client credentials in this primer given our space constraints. Given all this, is the bullet still inscrutable to you? Do others agree? If so, can you suggest a way to make it clearer? (To answer your question, though, UMA clients do have to be registered with AS's -- that is, they are technically also OAuth clients. In fact, UMA resource servers have to be registered with AS's as well -- that is, they are *also* technically OAuth clients. UMA clients do *not* get "registered with" UMA resource servers in any way as part of UMA.

- Asynchronous (Alice can start by just delegating and add policies only after she gets some insight into what the Bobs want - forces us to focus on delegation)

Again, I attempted to provide a friendly example drawn from many less-technical people's personal experience. "She can set this up with an experience that feels something like clicking on a Share button and choosing options made available in a pop-up style of interface, or she can send the others to a link that’s “closed”, they can attempt access, and she can consider her options at leisure. The paradigm could be similar to sharing access from Google Docs, only with options that are specific to each device type." ... "Finer-grained and asynchronous: Alice can decide in her own good time (well before or after) to grant access and how much access to grant, rather than being stuck with a coarse-grained “opt-in” consent choice in the moment." We don't have a ton of space to play with in this document, but I was hoping the difference between natural control and traditional coarse-grained opt-in flows (like consent boxes for Ts & Cs) should be obvious. The premise on which UMA has always been based is that -- at a bare minimum -- links can be copied and pasted, but a whole UX universe has grown up around apps and push notifications and emails and such, and they have helped to pick up the slack pretty nicely for advertising the availability of data resources. (Not that there aren't still problems to solve and standardize.) Given all this, is the bullet still inscrutable to you? Do others agree? If so, can you suggest a way to make it clearer?

- One delegation / location (Alice's authorization server is not domain-specific - neither should the legal agreements between RS and AS be domain specific.)

Here I believe you mean something like sector- or vertical-specific, right? You're correct that it need not be, but there's no problem if an authorization server is able to handle sector-specific knowledge, for example being HEART-conformant or whatever. Unless you have text to suggest that would improve what's there, I would suggest we move on. We've talked about your concern in this area many times, and I believe we have not uncovered a technical issue previously.

Let's focus on these three dimensions from a legal perspective. The BLT approach does not help. Neither does mentioning HEART help because HEART is even more confused than UMA. Once we get the Legal 3-D core down, a discussion of Business and Technical impacts on the Legal core might be unnecessary or just illustrative.

The three bullets do not correspond to the BLT concept, just to be clear -- and they are not tied to it in the text.

Adrian

On Fri, Jul 1, 2016 at 1:22 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

I vaguely thought there was a conflict on my calendar for next week, and just realized what it was. I'll be removing that meeting from the calendar. In the meantime, no reason not to go into the Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> to comment!... And if you have a burning desire to set up an alternate time to meet, let me know.

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

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

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/