https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 2018-03-02 Attending: Eve, Colin, John, Kathleen, Mark, Tim, Thomas, Bjorn Status update on the publication of the business model doc: It is finally posted! The listing on the Reports & Recommendations page needs to be fixed, but you can point people directly here <https://kantarainitiative.org/file-downloads/uma-business-model-0-7e-2018-02-01-pdf/> . We kind of need a UML diagram (or some kind of graph that lets us label the arcs) to express our delegation and licensing relationships more clearly, and we may need more role names for clarity as well. For example, a Resource Owner "is-a" Data Subject Representative (or whatever we want to call it – that's what GDPR calls it) but we have gone directly from DS to RO in our delegation mapping step. It would be clearer if we had a formal model that went: - DS delegates-X-rights-to DSR (the mechanism for this might be law, by contract – e.g. a will...) - DSR is-a RO - RO delegates-X-rights-to ASO - etc. Can we get hold of a UML modeling expert to ensure we don't miss any of the relationships and roles? In terms of finding one – or multiple – use cases to map onto the model, Eve is talking to 2-3 candidates about this. The complete list of agreements that seem to be possible in our model so far (the purple ones weren't mentioned in the business model paper yet): - 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 It sounds like we need to do this for the POC: 1. Complete the formal model (and likely express it in a formal way) 2. Construct the set of agreements and licenses (or whatever the latter end up being in the case of individual permissions?) in a skeletal CmA format 3. Use the CmA format to invite UMA deployers to work with us on testing the format by applying their use cases A central element of our proposal is that licenses have the right design characteristics to give ROs (acting on behalf of whoever the DS is) to enable the autonomy, reciprocity, and objectivity needed above and beyond contracts. Regs variously require policy elements of the contracts to enable the individual to have certain rights. "Right of action" in healthcare is one. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl