Page Comparison

• 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 Grantee/Resource Subject split, we anticipate there needs to be a Grantor/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 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. 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.