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 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/