Standing agenda for 2019: Work on producing our second business model 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 business model meeting series. See the UMA calendar, and the main Meetings and Minutes page, for details.
2019-05-28
Attending: Eve, Cigdem, Domenico, Lisa, Colin, Adrian, Tim
Suggested agenda:
- Capture additional use cases people have on their minds (up to some limit so we can get to the other items too)
- Decide what to do about "Proxy" and "Org equivalent of a Data Subject" as legal roles
- Start to figure out/capture technical "links-to" relationships that enable us to go from "code" to "prose"
There is work going on on a protocol called ALIAS that is built on OAuth/inspired by UMA. Mehdi Medjaoui is involved; Eve saw a demo. She's begun discussing with him and his colleague the potential for getting together on something like "privacy-enhanced UMA" here based on the fact that our business model work is going in this direction (sewing together the technology with the legal and business layers) and folks like Identos have been extending UMA explicitly in a similar direction. ALIAS has an artifact called a "bind token" that cryptographically binds the RRA (ro), RSO (rs), and ASO (as) (their version)
Adrian points out that "business model" in a business context usually means "How does this organization make money?" Other people also thought that was the meaning. That's not what we've been meaning by it – rather, we've meant the set of relationships that obtain among the parties (vs. the relationships that obtain among the technical entities as defined by the specifications). So, should we call this a "legal framework" instead? Business-legal <something>? Something very important hinges on the AS-RS separation, which conveys a main benefit. Let's try business-legal framework for now and see how it feels. Is relationships a word we can work with somehow? Domenico suggests business relationships for UMA deployment. Sometimes Eve has used "deployment use cases" to reflect the fact that they have concrete jurisdictions, people, companies, etc.
Do we actually need a word for "Proxy"? Our diagrams and text use cases in the original slide deck don't seem to need it. Tim hasn't found a single word that perfectly fits the concept, and using Proxy may not even be legally accurate. Note that this sort of (Agency contract, Access contract) delegation is a delegation of management, not of ultimate sharing. It's a kind of "delegated administration for consumers". But certainly, those liable for releasing access will want proof that the licensor has delegated authority.
As few words as possible between the original concept and the UMA mapping, the better! But do we still need some consistent word for the person who is the non-data subject administrator, perhaps Representative?
Perhaps we simply need to recognize the patterns in play by adding their relevant relationships (e.g., the addition of the relevant parties, relationships, and legal devices). This could work elegantly.
Adrian wonders if we have now collected enough use cases, since we've now sussed out whether the AS or the RS is the focus of the use case. Eve's theory is that, while there is likely a small and finite set of patterns, it's still interesting to capture further use cases as they arise, since real life is "messy" and we may learn from corner cases.
2019-05-21
Attending: Eve, Nancy, Lisa, Tim, Cigdem, Adrian, Domenico, Mark
...
- 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
...