Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

UMA legal subgroup notes

Notes from the 2015 series were kept in email: 2015-08-07, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16, 2015-10-23, 2015-10-30, 2015-11-06, 2015-11-20, 2015-12-04, 2015-12-11, 2015-12-18.

Date and Time

2016-02-26

  • Resource owners and those acting on their behalf: what language do we need to support the distinction? Any additional use cases? Any additional insight on technical design patterns?
    • We said we'd try to conclude this decision-making process by this week, and then move on to the decisions about RS actions in contradiction.

Attending: ...

2016-02-19

  • Distinguishing resource subjects from resource owners: Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here?

Attending: Eve, Andrew Hughes, Paul L, John, Ann, Adrian, Jon, Kathleen, Sal

Is it valuable to solve for a model where an agent can be working on behalf of resource owner vs. a resource owner?

The protean nature of the word "agent/agency" is troubling. Is there a good substitute word? If not, do we have to define *Agent for all of our terms in an UMA context? We did already have Requesting Party Agent. Perhaps, at best, we should define it operationally but stay away from legal subtleties.

We've said that resource owner = Authorizing Party. Does that work, or is it not equivalent? There are terminology questions and there are UMA architecture questions. Should we just wave away problems by making them equivalent?

  • 1yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a one-year-old kid and their mom has to manage the resources by logging in to the RS? The child is not competent to contract, even if they're old enough to sign their name. Guardian is a good name for the latter.
  • 12yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a 12-year-old kid and they're old enough to manage the resources by logging in to the RS themselves? The child is not competent to contract, even if they're old enough to manage resources online. How to architect the system and name the parties?
  • Intermittently competent adult case: This is another tough one.
  • Competent adult case: What if the "resource owner" (let's say again that they're the "subject" of the data residing in the RS) is actually competent to contract, but wants to have someone else manage resources for them online? There's a paper resource owner, but an online "executor" of resource management. What's a good term?
  • Digital death case: After the "resource owner"...

Adrian's concern is what happens in phase 1. These use cases have different properties in that phase. Eventually (soon), we will be in a position to work on what's supposed to happen when RS's want to take an action in response to an access request that is in contradiction to the permissions contained in an RPT (requesting party token). First, we need to understand exactly "who" configured the AS to 

By the way, all the same patterns could apply whether or not the resources contain PII or not. What if the resource owner created digital media that they want to sell? Is there a reason to distinguish in our terminology at all? What if a resource contains PII "in bulk" for many individuals (in directories or databases or other repositories)? This was the point of Adrian's example. Eve's point was, rather, that individuals might want to be protecting resources that don't contain PII. Okay, now we're on the same page! There are use cases for UMA that span "Alice" and "enterprise".

Let's try to conclude this decision-making process by next week, and then move on to the decisions about RS actions in contradiction.

2016-02-12

  • If you have terminology comments, speak up; issue #240 is closed otherwise
  • Update on overall roadmap: initial priorities settled; new #shoebox use case
  • #RSctrl, #ROctrl, and #shoebox use case are related; let's pick our highest-priority use case and specific set of clauses to work on, and work on them right now! (current clauses) (current relevant issues)

Attending: Eve, John W, Kathleen, Scott, Adrian, Mary, Jim, Ann

Terminology

Shall we leave this till we have specific needs?

We agree that Individual is best, over something like Natural Person. (Meatspace person, bag of protoplasm, ugly bag of mostly water...)

What about "data subject" and "PII subject" (which terms are defined in different standards)? We could refer to them from our Individual definition, or put them in a concordance appendix that is separate. Whether it's "next to" or "separate from" the definition text – and either could work in CommonAccord, because it could be modularized nonetheless, the question is whether we in this WG want to be responsible for keeping that text up to date. We've discussed that we don't want to be responsible for text that isn't UMA-specific. Jim notes that "any law firm that wants to make themselves useful" could keep up a text module like this. We would divest ourselves of any responsibility at all for the freshness or staleness of such text if we simply advised our model-text users of the existence of that third-party model text, rather than pulling it into our own model definition. It appears there are at least two companies that provide this sort of concordance, but they are paid services. Nymity (Toronto) and Privacy Guidance (UK) charge $10K/yr (for content that goes well beyond just this bit).

"Model definition" is a good name for the specific kind of model text that contains a full term or abbreviation definition. If we want to put a "comment field" in any of these, what would be the purpose? It apparently shouldn't render in a "final" legal agreement; it should just be there to guide how a legal agreement builder should use the definition.

Not just about terminology but about "agency"

Is the RO always the data subject (etc.)? If elderly RO Alice gives access to her protected resources to adult child Bob to help her manage them, UMA makes him her RqP. How do we understand "agency" in this light? Note that UMA calls it "resource owner" only because OAuth does, and "ownership" is problematic as a term. "Resource controller" is more accurate, and it maps nicely to the old WG concept of the "split RO" problem. Note that we have introduced the Authorizing Party phrase on the legal side of our terminology to help get around the "owner" problem, which aligns nicely with the concept of who has the "authority" in each context.

Scott introduces the "legal capacity" phrase. Every jurisdiction has a different definition of the point at which a natural person has it, and different kinds of health data are regulated in each jurisdiction. Sometimes legal capacity is down to age, and sometimes it's determined by other criteria. John mentions tests that a physician can perform to determine capacity. In the case of "aging-in" or certain other automatic types of capacity tests, if resources can have standard data taxonomies applied to them when RS's register the resources at AS's, then it might be possible for automatic policy changes to take place.

Kathleen mentions that HL7 wants to use our deliverables for FHIR contracts. This is for its work coming out in September. They'd be interested in both the model definitions and the model definitions, for "substitute decisionmakers" – Alice would be the grantor, and Bob would be the grantee. In some other contexts, Eve has heard terms like subjects and delegates, and citizens and proxies, etc.

AI: Adrian: Write up ROI form concerns wrt to UMA phase 1 implications for the group's consideration.

Next up

We need to ensure we have a very firm handle on the legal capacity in our terminology (and possibly clauses). And then we need to make good progress on our beta model text timeline, for all sorts of reasons (both IDE and customers).

2016-02-05

Attending: Eve, Scott, Paul, Jim, John W, Adrian, Ann, Jon N, Mark, Kathleen

Regulation of consent

Should we be concerned about EU regulators "regulating away" the potential power of UMA around proactive enduring consents (e.g., policies that are indefinite until revoked) because on subsequent reference to them by an AS they're not "explicit"? Is there a way to influence the thinking of regulators and/or have two-way conversations with them so that implementations and deployments can give individuals the right buttons and knobs and UX's? It's certainly possible to make appointments with regulators. The US regime has a property basis, whereas the European basis is human rights. Revisiting one's consent in context (monitoring one's consent) would theoretically be a powerful way to exercise one's rights.

In the healthcare world, coming from paper vs. digital, notice was expensive. But in the digital world, notice is free at the margin.

Mark notes that: "We are working on a model practice papers to send to regulators wth the Kantara sponsored workshops." He will send a note to the list with more information as required. He thinks we  don’t think we need to worry about regulators regulating away consent directives, as consent is regulated by purpose and notice.

AI: John W: Find ways to reach out to regulators to start conversations.

Digital Contracts, Identities, and Blockchain - new event at MIT

This event has very limited seating and is invitation-only. If you want to attend, let Jim H know soonest! The notion is secure, DRY, peer-to-peer text objects handled as if they were software objects.

Term definitions

Our term definitions of record are here.

We can define whatever terms we want, but we don't want to "chase our tails". Agency (here meaning legal agency, the ability to take responsibility) is different from being a hunk of, say, software; software isn't a thinking thing. We're in the business of helping services that want to be, say, IdPs and merchant services and healthcare services also be UMA services to create the legal agreements they need, and since they'll be UMA clause novices, we're providing starter UMA clauses for them.

Note that an UMA authorization server operator is different from talking about a data processor or data controller. The the former term is an "UMA legal" term of art, and the latter are regulatory terms of art. Wherever we use the latter, we would have to refer to our source of the definition – ISO 29100 is what CIS refers to for consent receipts.

The pairs we currently have are:

  • resource owner:Authorizing Party
  • requesting party:Requesting Party
  • authorization server:Authorization Server Operator
  • resource server:Resource Server Operator

Where things break down:

A use case: Alice (Individual) wants dentist's office (Legal Person) to get access to her calendar for the purpose of scheduling a root canal. The dentist's office receptionist (Individual acting on behalf of the Legal Person, as an employee or contractor) tries to access the resource, using a client (Client). 

Questions: Let's not overcook this. Think in terms (ha) of the next strawman iteration. Since no one expressed strong feelings about making any changes, we will leave the terms as they are till changes are forced on us.

  1. Should we give a generic name to the clients, authorization servers, and such? Are they Non-Person Entities as a general category now? What would be the usefulness of this? Don't add.
  2. We've called the receptionist in this use case a Requesting Party Agent to date. Is that right? What benefit does it confer? There is actually an UMA flow (or possibly several flow options) to which it correlates. Eve suggests: Keep for now and try to use it in practice to see if it works.
  3. Does UMA want to trace duties to preserve the rights of the Individual? No further discussion.
  4. Does Individual want to be Natural Person? Don't change.
  5. Is the ability of the Individual to consent constrained in the circumstances of the transaction, e.g., by regulations? (Think in terms of term definitions for now. This is a much bigger question!) Don't change anything..

It seems we have nothing more to discuss on issue #240 unless problems arise.

2016-01-29

Attending: Eve, Domenico, Jon, Jeff, Kathleen, John, Dazza

Regarding #RSctrl, John W notes that Russia is one case of a jurisdictional constraint where the cloud service has to be located in-country and that would have to override the RO's choice. Adrian has brought up healthcare-related constraints regarding delays in fulfilling the access request. In the case of cross-border transfer, EU adequacy rules for offshore transfer come into play. This is why cloud services have data sovereignty plays and data centers are coming up in All The Countries.

The actual UMA Core spec has a clause, which Eve has dubbed the "Adrian clause": UMA Core Sec 3.3.3: "The resource server MAY apply additional authorization controls when determining how to respond."

Essentially, at a T (technical) level, IF the AS and the RS are run by different operators, we have very little direct control over the RS going against the RO's wishes as expressed by the artifacts produced by the AS. This is why it's so important to look at the L (legal) levers we can control. The #RSctrl use case is on pretty firm ground when it comes to legal compliance. How firm ground is it on in cases outside compliance?

How far could we take mandating the usage of our clauses? It depends on the compliance situations and the jurisdictions. There are also technical solutions that can be layered on top of UMA, such as encryption. If regulation of encryption use is already present in an ecosystem, then very likely both the clauses and the complex technology can be mandated. (If it's an unregulated environment and/or some element of the ecosystem is commoditized and "free-wheeling", potential partners at the edge may walk away because encryption technologies are complex and add cost and friction.)

We looked at Scott D's mapping exercise. Kathleen knows of a similar mapping exercise having been done and will point us to it. How might we be able to leverage such work? Jon suggests that we can look at the breakdowns of common text vs. factored-out differences to help us structure the elements of our model text that, of necessity, get into jurisdictional specifics. We can hopefully structure our common vs. factored-out elements in the same way.

Eve suggests taking on the term definition work first, taking the many healthcare use cases as examples – and possibly writing the needed model clauses to motivate the right definitions. E.g., what if Alice needs to share access with a hospital, or hospital department, and Dr Bob gets access as an employee of that organization? There are questions around how a "Requesting Party Agent" would get defined, and possibly also "Client Operator". While health isn't the only set of use cases for this, it's 1) the hardest case, and 2) ready to try out our work!

It sounds like we need to have focused text-bashing working sessions; our calls are the times we have available to do this.

2016-01-15

Attending: Eve, Ann, Adrian, Jim, Jon, Mark, Sal, Thomas

What Eve calls the "Adrian clause" is this part of UMA Core Sec 3.3.3: "The resource server MAY apply additional authorization controls when determining how to respond."

What does the "RS authorization discretion" use case mean? Should the AS be made officially aware that the RS still didn't give access (similar to the "Shoebox" technical idea), or could the RS somehow need some other assurances that it can be compliant? This goes right back to the Adrian clause, and complementarily, to the Shoebox idea. The RS could either warn Alice, or could verify the requesting party on its own. Is this broad-based, or truly healthcare-specific? To how many jurisdictions does it apply? Adrian suggests another case of a warning. A data processing process might take some time to complete, and only licensed practitioners can receive in-process results.

Would it be useful to develop a model clause, or even a pair of model clauses? Sounds like it's useful to try, and then go back and see if it's getting used.

What does the "RO access limit discretion" use case mean? There is something of an opposite to the Adrian clause in the same section: "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization."

A way of looking at it is:

  • Conditions: RO wants sharing to happen; AS executes those directions appropriately, such that the RPT is valid and is associated with sufficient authorization data:
    • RS gives access - normal case
    • RS doesn't give access
      • To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION?
      • For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE?
  • Conditions: RO doesn't want sharing to happen; AS executes those directions appropriately, such that the RPT is invalid or is associated with insufficient authorization data:
    • RS doesn't give access - normal case
    • RS does give access
      • To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION?,
      • For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE?

The idea of getting notices is that the RO could severe the relationship with the RS if they want. Of course, sometimes there are legal constraints on even getting a notification.

Can you ever trust the AS to serve the RS, versus the RO? Only at the business agreement level could an AS start to consider jurisdictional issues that RS's care about.

Please note: No meeting next week! We'll resume the week after.

2016-01-08

Attending: Eve, Ann, Jim, Adrian, Jon, Mark, Thomas, Bill Wendell (guest - ears only), Andrew Hughes, Sal

Mission and timeline discussion

A proposed mission and timeline were sent in this message.

Jon speaks in support of the three goals. Is "model clauses" the right phrase, given that "EU model clauses" is something of a term of art? We're free to call it whatever we want. RoboClauses? (smile)  Maybe the connection to EU model clauses is helpful to us.

Regarding meeting scheduling, if text review is paramount in the early going, availability of interested parties is the most key. Offline review and reporting of comments by others could work great.

"Model text" was Eve's temporary phrase covering not just the clauses but also the definition. "Model T – you can start with any color you want, as long as it's black!"

We're thinking that the "standard" meeting time of Fridays at 8am PT would be okay for starters in working on the model text. Note that Eve can't make January 22, so maybe we can move or skip that one.

Andrew's project is holding a F2F in January, and by February will possibly be really ready to need our outputs. Right now they're wrestling with different views on what "authorization" means. Is it authorization to release information? access to an API? (UMA would rely on the semantics of the API being protected for the definition.) Mark notes that consent and permission definitions should come into the picture as well. This does actually impact our term definitions because we use the word "Authorization" as part of our UMA role names, and so we may have to define Authorization, or at least define it in a limited sense so that a context in which the word is defined in a different sense is not incompatible or confusing wrt our usage. If there is, somewhere (EU?), a standard vocabulary, can we leverage it? Or is it too backwards-looking?

Let's add this to our open issues.

AI: Eve: Add model text issues to our issues backlog and tag them appropriately, including the issue of defining authorization, consent, etc.

Consenus on the mission is positive. What should our timeline actually be? Jim recommends that we target a real version number of 1.0. We can achieve this sooner rather than later if we have real review by people who really need this text!

Eve has been collecting external reviewer candidates. We did some more brainstorming.

The right time for a beta version of the model text for review: end of March 2016.

AI: Eve: Send continuing calendar invitations.

Requirements discussion

Some proposed high-level requirements were sent in this message.

Eve did a quick reading of the proposed high-level requirements. People started dropping off, but it sounded like there was at least some weak rough consensus. (smile) We'll work with this list for now until it proves problematic.

Draft model text

The latest model text for review, with commentary, was sent in this message. It lives persistently here.

We took a quick look at the message sent out.

  • No labels