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.
...
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). Did Airside Mobile do something like that too?
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.
...
- 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
...