Below:

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

On Fri, Dec 11, 2015 at 2:45 PM, Adrian Gropper <agropper@healthurl.com> wrote:

Hi Jim,

I'm suggesting a few things:

1 - that the UMA legal framework must clearly serve to limit the RSO liability. I think indemnification is too strong a statement although it would add even more value to UMA adoption.

There are several layers here. There's an UMA-specific layer that we are trying to provide tools to help solve because UMA is new and potential "scary", and some lower layers that are (probably) business-as-usual in a lot of ways. In fact, Dazza's great work on federations of all sorts, including identity federations, with the canonical B-L-T structure, would be good practice for anyone who hasn't written any of this up before. But many sets of organizations (such as those contemplating RSO/ASO roles) may have existing relationships under other roles, with existing agreements already in place.

 

2 - that the contract that results in Resource Registration (a case of pure Agency Law with RO, RSO, and ASO as principal, third-party, and agent respectively) can be divided into 4 separate kinds of clauses. This separation might be a nice way to structure the linkage between the legal and technical aspects of UMA.

3 - that the RS has the final say in data release to a particular Client / RqP and that UMA technology must enable "good faith" and "notice" in the sense of Agency Law. It might be good to highlight this aspect of UMA technical in order to make it easier for RSOs to justify adoption.

"Final say" (at whatever minimum level we think is appropriate, which the users of our clauses can beef up at will) is a good thing for us to capture in a new clause that doesn't currently exist in the 2013 Binding Obs doc, driven off this spec text:

UMA Core 3.3.3: "The resource server MAY apply additional authorization controls when determining how to respond."

Note, however, that we follow it with "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization. To ensure the integrity of the ecosystem in which the resource server, authorization server, and resource owner are participating, it is RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level."

This is where the original Binding Obs clause called Respect-Permissions was supposed to come in (I've modified it here to remove the temporal aspect), although I think we should revise it to cover just the negative case:

"[T]he Resource Server Operator [agrees] to respect the permissions that the Authorization Server has associated with the RPT when the Resource Server subsequently allows or disallows access by the Client that presented that RPT."

 

I don't think I'm posing any legal questions but then I'm not even "a poor country doctor".

Adrian

On Fri, Dec 11, 2015 at 5:07 PM, James Hazard <jh@hazardj.com> wrote:

To help me understand, I presume we are UMA 2013, including:

ASO to RSO obligation:

http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md#4.2.Sec

and perhaps add indemnification from ASO to RSO against any liability to RO.

The question, if I understand it, is whether the RSO becomes legally protected from claims by RO that info was improperly sent to RqP.

That sounds like a legal question, and the answer is probably "that depends."  As a strict matter of contract law, it seems easy enough to make that happen.  The RSO makes sure that the ASO has language in its contract with RO that releases RSO, and looks to ASO for indemnification.  But depending on the nature of the information and the relationship of RSO to RO (outside the pure data administration) RSO, the law could impose a duty on RSO that cannot be waived and RSO might be worried that ASO is financially fragile.

 Have I understood the question?

      

On Fri, Dec 11, 2015 at 8:49 PM, Adrian Gropper <agropper@healthurl.com> wrote:

I'm trying to understand the essence of an UMA Legal framework by picking a very simple but real-life use case and premise.

Premise: The resource server operator (RSO) installs UMA because it limits their liability due to clients interactions. In other words, they are transferring some risk to an authorization server operator (ASO), otherwise they would just implement OAuth.

For simplicity, presume:

• a single resource: https://uma.rso.com/adrian/weight/readonly

(This would be an odd choice of resource URI, containing within it the scope like that, but that's neither here nor there for the topic at hand.) 

• terms of use: the data is only to be accessed by anyone, including rso, via the resource above

This is interesting. Does this mean that even if the RS accidentally or deliberately exposes the resource through another URI, no one is allowed to use it? The RSO should bear responsibility for securing its interfaces to the outside world, so that only the "protected resources" that it registers as "resource sets" at the UMA AS resource set registration endpoint are considered part of what is covered by the agreement among the RSO / ASO / Authorizing Party.

• clients will present a valid SSL certificate and a token verifiable at the authorization server

Resource set registration is done in the context of a PAT (an OAuth token with the right scope), meaning that it's about the RSO / ASO / Authorizing Party. We could state that the token needs to be valid (active). Do we have to go into the layers "upstream" from (or put another way, "lower" than) UMA into our model clauses? Or could we provide some commentary along with our clauses to suggest additional text that might be advisable?

• this contract between RS and RO expires after one year or upon notice by either party

I don't think I've ever seen a relationship like this (between a human and an online service) expire in real life. I'm not sure how it would work. Would all the resources be deleted? archived? Would any related tokens have to expire?

Under these circumstances, the RSO has transferred most of the liability for interacting with a particular client to the ASO. This, I believe is the UMA Legal MVP.

Agree. 

In a real-world use-case, the RSO may not be allowed to duck this much liability. For example, the RSO might be required by law to notify the RO that a particular Client / RqP is on an industry watchlist.

Can you give an example? Why would the RSO specifically, vs. the ASO, be required to notify the RO (the Authorizing Party in our binding obligations parlance)? Is the law that clear?

Unless the RS actually avails itself of the right/burden to do its own client vetting, it wouldn't (have to) know anything about the client. And I thought that the whole point of the "Alice is sovereign" use case is that Alice is sovereign; doesn't that go for sharing too? If she proactively shares with somebody (which is barely a feature that anything lets her do now), are there really laws about that? (Goodness knows there are a lot of laws, so...)

In this case, the Client / RqP is providing attributes to both the AS and the RS. The RSO bears somewhat greater liability unless it can warn the RO via UMA the same way it might warn the RO via OAuth.

Why does the RS have to warn via UMA? The RO has a login to the RS through normal channels (a regular online service relationship). How does the RS warn the RO via OAuth? If there is any kind of a warning, it would actually come from the AS. (Although in OAuth there isn't a heck of a lot of light between the AS and the RS, it's still the AS that does all the client-vetting work, and the RS that receives the resulting token, same as UMA.)

Can the ASO bear the responsibility of warning the RO or must the RS warn the RO directly?

Answered above, I think. AS vetting results in either policy-based access/denial or regulation-based warning through UMA; RS vetting results in either policy-based access/denial or regulation-based warning outside of UMA.

As far as I can tell, this is the essence of UMA legal. Everything else is just an elaboration on one of the four bullet points above. This, incidentally, is the use-case I'm discussing with the US Office for Civil Rights.

Adrian

--

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