...
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
- Working through use cases per party in the transaction – see last week's notes for the pattern
Attending: Eve, John W, Adrian, Kathleen, Mark, Mary, Sal
Adrian points to this fascinating article introducing the notion of an "information fiduciary". We discussed the merits of this phrase vs. "agent"; in the past, we've had feedback that "agent" is an accurate legal concept, but too academic. Mark concurs. Some give feedback that "fiduciary" may be helpful has a concept. It does have a connotation of totality of trust. This is sitting pretty well with quite a few use cases. What if our model text, if adopted as a whole by an ecosystem, would confer a kind of "safe harbor" (see the reference to this concept in the article) that lets the various service roles declare that they are "fiduciaries" of specific kinds on behalf of the resource owner/Resource Subject. At the least, we could advocate for this to be a standard interpretation among the Pan-Canadian Trust Framework developers, the GDPR regulators, etc.
We're thinking that the budget we have available to use – and must be used by end of year – would best be used in a completion of this analysis.
In fact, do we want to take BCRs and turn them into our text, or go in the other direction, or what?
We have defined Resource Subject with our eyes open to the analogy with Data Subject. Does it make sense to have Resource Controller instead of Resource Server Operator? This seems relatively close, by analogy to Data Controller. But then again, from a rights-granting perspective (where the DS is the rights-holder on whatever basis and the DC works under constraints set by the DS) and what we've done with the design of UMA, we have perhaps split out the Data Controller role into two with our RS and AS. This is part of the innovation of UMA.
And then what about Resource Processor, analogously to Data Processor, for the Client Operator? Is disclosure of data always for some purpose that is "on the DS's behalf", or is it sometimes for the autonomous use of the access recipient? Eve wonders if the "behalf" distinction is just a way of saying that liability, or responsibility, or accountability, is really strong or has a lot of components to it. As long as the regulatory/contractual layer above the technical UMA layer can capture the subtleties of the liability (such as "you can only share this data after a certain time") or even the technical layer can capture some constraints (such as "sharing will end at this time" or "you cannot write data back to the server, only read it from the server"), then the entire requesting side – both client and requesting party (however each ultimately get split out in "party" terms) – could constitute the Data Processor.
What about the challenge of "on-sharing", or re-sharing, or downstream sharing constraints? Here are some thoughts:
- If there is a narrow ecosystem where all users are using the same AS, it's very easy to manage this, because the (singular) AS can keep track, and then you (the RS that publishes APIs) could theoretically invent something like a "no re-sharing" scope on your APIs and then let people set this when they share. (Think of Google Apps's similar "Advanced" feature.) Such a scope, if that's the right place to put it, maybe could be a standard "best practice" scope in various APIs.
- In a medium or wide ecosystem, where everyone uses (say) a different AS, John points out that Alice could at least monitor sharing through a ledger mechanism (he can send the diagram to the group), but you'd need something like encryption or DRM technology above UMA to actually control the re-sharing. John mentions J-LINC and Sal mentions COALA.
AI: Eve: If feasible, approach Scott D about the possibility of funded work to complete our use cases and terminology and analysis around DS/DP/DC.
2016-10-07
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
Attending: Eve, Kathleen, Adrian, Mary
Let's do some use case work today.
Kathleen notes that, working with the US feds, there's a difference between a "contract" and a "memorandum of understanding" (MOU). In an MOU, they're funding a program, so some transaction value is flowing. Many types of contracts do capture some sort of payment. Maybe this has to do with the relationship being formed, and therefore impacts the model clauses most forcefully.
Analogously to the GranteeGrantor/Resource Subject split, we anticipate there needs to be a GrantorGrantee/something split, where there's potentially someone who might request and get access as part of an employment contract on behalf of the real party who's accountable for the access (like the doctor or admin who works for a hospital). Mary brings up "Relying Party" as a candidate for the opposite side of the Resource Subject. Eve has some discomfort because it may cause confusion between identity federations and access federations. But what if the analogy with the sharing specifically of personal data is so powerful that this phrase evokes the right images? Or maybe Receiving Party? Resource Recipient?
RO-side use cases, summarized:
- UC1: RO = Grantor = Resource Subject, where this natural person has legal capacity
- UC2: RO = Grantor, where Resource Subject is a natural person without legal capacity
- UC3: RO = Grantor, where Resource Subject is a natural underage person unable to consent online (yet) and they are also a RqP
- We need a UC3a that maps what happens when the underage person becomes of age
- UC4: RO = Grantor, where ...
What are the RqP-side analogies? Let's try and fill those out next time. We need to build out these lists for every technical role.
AS-side use cases: Adrian's main concern is the AS(O) as an agent of the Resource Subject or Grantor, where there are the strongest possible constraints (technical if possible) on anyone but them seeing their policies and the RS cannot known whether the policies are under the control of either the Resource Subject or Grantor. In this context, he wants to describe the limitations of liability of an RS(O). The issue here is that the service we would call the RS currently has visibility into a sign-off by people in both the resource subject and guardian/proxy roles in some fashion, and since UMA interposes an AS as an "agent", any service becoming an UMA RS would lose this visibility. The legal questions for us are: Is this loss of visibility acceptable? If not, do we have to build a facsimile of the visibility into our model clauses? Are there jurisdictional variations?
AI: Adrian: Add the above as a GitHub issue.
PARKING LOT: One thing we should discuss at some point is the notion of "pushing" content" vs. a typical web pattern of "pulling" content. The usual web pattern we think of is that a client approaches an API unilaterally, which is nominally a "pull". However, there are patterns such as websocket where there is a constantly open channel through which the RS could push content at will. The IoT uses this a bunch, and some other technologies. Kathleen mentioned the AS serving as a content broker – we'd have to discuss what this means more.
...