Some groundwork on developing legal use cases for discussion next week is
forwarded below. More general background on the law of agency is available
at: https://en.wikipedia.org/wiki/Law_of_agency
---------- Forwarded message ----------
From: Dazza Greenwood
Date: Fri, Aug 21, 2015 at 2:59 PM
Subject: Re: [WG-UMA] Reminder: UMA legal subgroup telecon 2015-08-21
To: Eve Maler
Cc: Mark Lizar , Adrian Gropper
Following up:
For the next meeting, it sounds like the question is:
What 2 or 3 use cases would "flesh out the AS possibilities"? The essence
of two distinct alternative possibilities we discussed are:
1) Its an AS world and Alice just lives in it; and
2) The AS works in Alice's Restaurant.
Eve, as always, you posed a really good question and I'd be happy to work
on it for input to the next meeting. My own instinct is usually to go into
the weeds of fact specific contexts like in HIPAA or the EU privacy
directive. But upon reflection I like your proposed next step more and more
because it logically is the first brick of an otherwise uncertain
foundation.
Here is my thinking:
Currently, most of the legal context and basis for establishing rights and
obligations of parties using UMA will source from the economic sectors and
verticals in which UMA is deployed and used. This however is complex and
confusing to analyze. The focus for next week is therefor to develop use
cases that are not vertical-specific to any particular vertical. This also
means keeping identity-federation-agnostic. This is a narrow scope focused
on identifying, describe and defining the "base-case" legal roles and rules
between Alice and the AS.
The fundamental assumption in Scenario A is that the AS "works for" Alice
in the sense that it "serves the interests of" or "is answerable to" or
"directed by" or "the legal Agent of" etc Alice in some meaningful way.
Examples of these relationships between individuals and organizations
include investment banks who transact money or other assets of an
individual and law firms who advocate for an individual.
Identifying the legal dimension of the use cases from the perspective of
generic "agency law" would give us traction to make good progress on the
task for next week. It is possible to apply the rules of agency law
without reference to other more specific legal relationships arising from
roles associated with any particular economic sector or industry vertical
context.
Applying the rules of agency law is one way to credibly address the
question of who will prevail in a dispute between the parties over
protected resources. That means it provides a basis for concluding what
bundles of rights or responsibilities any given use case actor has with
respect to the other actors and to the protected resources at stake with
UMA use cases.
For a sound legal analysis it is important to have a sense of the nature of
the thing at stake. If is a family member we have one analysis (maybe we
can limit their TV watching but not take their TV) and if it is a city we
have another (maybe we can out it into receivership but not under
occupation). The most relevant legal aspect of OAuth 2 (hence UMA)
protected resources is that they are property. These resources are basic
boring normal property. They happen to be intangible property and that has
been normal and boring for decades. No big deal. The nature of basic
property is not specific to the idea of "intellectual property". That is
another context that may or may not be important or even apply to any given
intangible property, depending on the context. What definitely applies and
provides a direct, simple and complete cross-walk to regular old vanilla
agency law and heaps of other well understood and widely agreed legal fact
patterns is the fact that these resources are also property. There exists
a long tradition of roles and expectations about property rights and all
that can usefully be vectored directly into the equation for Alice.
It may be helpful to connect the dots and make a clear surface area for
application of things like business models, legal terms and technical
protocols. Among other things, data and other protected resources like
services or rights to service levels etc are also property and people have
"property rights" to buy, sell and otherwise slice and dice property
rights. UMA legal use cases that focus on the specific rights or
obligations linked to protected resources are tractable and totally avoid
the needless debates about what "ownership" does or should it could mean if
only everybody would agree to that definition. The question of ownership
has been asked in many a personal data and electronic transactions forum
and it is very definitely the case that everybody does not agree on a
definition of ownership. And yet, it is frequently possible to find
agreement on named rights and obligations with respect to data and other
property. The concept of ownership suggested it is the sum total of all
rights to property. One could say that "exclusive control, possession and
enjoyment" of property is full ownership. Yet, much of the value and fun of
having data and other stuff comes from sharing it. Most people would not
have a home if the value was not shared with whomever hold their mortgage.
Who owns the home when the mortgage is worth 90% or even 110% of the
economic value of the property? The deed would says title owner is Alice
and yet the word ownership is not really very important to the practical
questions of who can do what.
The basic roles are Principal (which is a reasonable fit with with UMA's
happy Alice and 29100 Principal as well), and Agent and Third Party. It is
as good a starting place as any I can think of and better than most. The
authoritative source of agency law is the "Restatement" and it is both a
source of voluminous case law and also boasts a lot of law school and other
pre-argued "fact patterns" with broadly agreed legal "answers" and
reasonably expected dispute outcomes. The presence of a lot of well worn
fact patterns based on generations of case law and codified/formalized
rules (ie the "Restatement") is very valuable for the purposes of this
workgroup. The value of such fact patterns is they are carefully designed
in a way that can be cross-walked to technical use cases pretty
easily, providing
a source of existing agreed legal scenarios with named roles and expected
legal results to get us started. Coming up with that stuff from a blank
slate and getting broad understanding and agreement on the expected legal
results can be a daunting long term task and therefore makes it less likely
this legal group could achieve its adoption oriented mission.
As a side-note, part of what makes the UMA flavored Alice to Bob flows
interesting is precisely that they shed light on the nature of roles
individuals have in relationship to "service" providers. There are many
layers of connotation around the legal concept of a "service provider" and
decades of law school text books and bar exam fact patterns that routinely
position such parties as agents providing a service for or on behalf of
principals. This gives tools for lawyers to deliberately structure
transactions by defining defining roles and corresponding legal rules to
create predictable and beneficial legal outcomes for their clients. By
contrast, typically in the modern mass-market networked economy it is the
individual who works for and is the legal "agent" of one or more
organizations which are the legal "principal" in that context. These are
legal terms that apply to the "roles" of the parties and from which
"relationships" can be revealed. Employment relationships, as an example,
carry some predictable sets of rights and obligations and also vary to some
degree depending on factors like the applicable jurisdiction(s), and other
relationships the parties may also have with one another or with others
(like when somebody is your patient but also your boss or your student but
also your auditor, etc).
In doing an AS relationship analysis that "non-vertical-specific" we have
an opportunity to start with a very clean slate and just ask the
level-setting question: what is the basic legal relationship and which
roles in the relationship is played by each "party" (aka actor or entity or
person) identified in the use case? This is a great question to level set
for the call next week and provides a sound foundation upon which to
clearly layer vertical-specific relationships and other important sources
of context. It is possible to identify, clarify and simplify the context of
use cases by just naming the legal roles/relationships of parties
conducting transactions or other interactions. Once the legal dimension of
context can be refined down to a few defined roles and interactions it is a
lot easier to speculate on and have an opportunity to successfully
deliberately structure the relationships and transactions to achieve more
predictable intended legal results.
Layering on "vertical-specific" financial services, educational, clinical
care, municipal, commercial, law enforcement, workplace, etc contexts will
provide a well of known and named sets of legal relationships corresponding
to definite and repeating roles which can therefor be linked to each
identified party in any use case.
Typically a technical use case provides to little information to
assign vertical (or other) specific legal roles to a given party with high
confidence. This is signaled when a lawyer says "it depends..." when asked
what legal roles applies. That goes double for the evrn more ambiguous
question "who 'owns' this or that data or other property" in a use case.
The good news is that by at least by answering Eve's question about
non-vertical-specific and then some vertical-specific use cases and
developing some consistent documentation of roles and other terms we will
have built a tractable legal fact pattern. With that traction we can make
progress to resolve the key sources of ambiguity needed for lawyers to make
conclusions like "in use case xyz, Alice is the Principal, the AS is the
Agent of Alice" and "in use case abc the AS is a "covered entity" under
HIPAA and has a legal obligation to share Alice's resource with Bob upon
Alice's signed consent and request to share". This is good and such
traction is one way to achieve the mission statement of this legal
subgroups.
When a lawyer says "it depends" the opportunity is to elicit the factors
upon which a legal conclusion about the situation depends and therefor to
structure (aka architect) systems, relationships and activities to get
intended legal results.
The opportunity this workgroup had is to surface the important and
potentially outcome changing factors upon which legal determination of use
case by use case roles depend. The purpose of creating a sound basis for
assigning any/all potentially applicable legal roles to parties in use
cases is chiefly to deliberately define and design the legal relationships,
rights, responsibilities and results.
Ok, so beyond writing a lot of blah blah words, here is what I can commit
to for input to the next legal group meeting:
I commit to publish a roles and definitions wiki page that is
cross-referenced/cross-linked to the use cases we have so far and - more
importantly - where the group can continue compiling named roles and other
defined terms. Each term will be at an HTML anchor point to simplify and
streamline identification of the meaning people are using and to provide a
"ready to use" resource for popping in the eventual set of terms and
meanings chosen by the group for use in a final set of legal use cases and
corresponding recommendations.
Thanks,
- Dazza
| Sent from my iPhone
| Please Forgive Typos
_________________
| Dazza Greenwood, JD
| CIVICS.com http://civics.com/, Founder & Principal
| MIT Media Lab, Visiting Scientist
| Vmail: 617.500.3644
| Email: dazza@CIVICS.com
| Biz: http://CIVICS.com
| MIT: https://law.MIT.edu https://law.mit.edu/
| Me: DazzaGreenwood.com http://dazzagreenwood.com/
| Twitter: @DazzaGreenwood
| Google+: google.com/+DazzaGreenwood
| LinkedIn: linkedin.com/in/DazzaGreenwood
| GitHub: github.com/DazzaGreenwood/Interface
On Aug 21, 2015, at 12:01 PM, Eve Maler wrote:
AI: Dazza and Eve: Coordinate on producing 2 or 3 candidate distinctive use
cases that flesh out the AS possibilities, non-vertical-specific and
identity-federation-agnostic.
