Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details.
2019-06-18
Attending: Eve, Lisa, Thomas
Lisa has uncovered some discomfort with UCITA in communities we care about, which may give us pause about our references to it in the Business Model report as a source of uniform language. See this source for some of the controversy. Section 2 of our report says "A possible challenge to implementing a user-centric access sharing protocol has been the lack of a set of uniform default contractual rules for the exchange of personal digital assets. Fortunately, UMA may leverage the Uniform Computer Information Transaction Act (“UCITA”) as one source of default contractual rules upon which the licensing of access rights to personal digital assets may be based." We haven't yet canonicalized any standard boilerplate, so we're probably not in any danger of "exciting those antibodies", but it's something to watch out for. Lisa notes that, from the P7012 perspective, fast progress is desired – but when the totality of options is presented, people can easily get overwhelmed.
Is it practical to define a Data Subject as either a natural or a legal person, as has been suggested? Architecturally, yes, it could be. But our analysis suggests that defining it this way is unhelpful and possibly harmful, because:
- UMA's primary aim is to aid "Alice" the individual (a natural person)
- GDPR and many other laws/regulations/policies define data subjects as natural persons and exclude legal persons from this role
- Conflating natural and legal persons is generally confusing
So let's stick to Data Subject as just a Natural Person.
We've been looking for a term for the person (Person? Natural/Legal? or only stick to Natural?) who is in a "proxy" role in our business use cases. If Proxy doesn't work, Tim was suggesting Representative or Legal Representative. Examples he has provided: "Personal Representatives, Executors, parents of minors, guardians appointed for minors, Conservators, guardians for elders, corporate proxies, etc." While Data Subject is human, the Representative could be a Natural or Legal Person. Given this, that's probably a good rationale for not adding the word Legal on the front of the term, since that makes it ambiguous (iow, it's a "legal representative" whether it's a legal person or a natural person). So let's call it Representative.
The point of finding and defining this name is that it's a name for a the party when they're acting on behalf of the Data Subject, not acting in an UMA flow capacity – even though (Representative == Resource Rights Administrator) in the same way that (Service Provider == Relying Party) in federated identity. The first role is about inherent value-add and the second role is about specialty protocol dance.
In the future, we might want to have a term with a definition like this, but we don't yet:
(some phrase): The Legal Person to which a Protected Resource relates.
We know there are use cases like this – "enterprise UMA" use cases. Maybe we just say "Legal Person" for now, and we talk about the Protected Resources that relate to them; those resources are not personal data of the Legal Persons (though the resources may contain the personal data of individuals).
2019-05-28
Attending: Eve, Cigdem, Domenico, Lisa, Colin, Adrian, Tim
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...