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
_________________
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.