...

...

...

...

...

...

...

...

...

...

...

...

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.

UMA legal subgroup notes

(Notes from the 2015 series were kept in email: 2015-08-07, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16, 2015-10-23, 2015-10-30, 2015-11-06, 2015-11-20, 2015-12-04, 2015-12-11, 2015-12-18.)

Date and Time

"Legal" topics are currently being covered in the main Work Group call a separate business model meeting series. See the UMA home page, UMA calendar, and the main Meetings and Minutes page, for details.

2019-05-07

Attending: Eve, Adrian, Cigdem, Domenico, Colin, Lisa

Eve proposes a use case around "relationship-driven policies" that themselves drive UMA authorization assessment and RPT issuance. The mapping to artifacts goes back to a PAT that the RS, as an OAuth client of the AS, has been issued due to the RO's approval.

So far, our nascent second report has an abstract of "The premise of the draft report A Proposed Licensing Model for User-Managed Access is that UMA enables the individual to centrally manage access and use rights with respect to personal digital assets by converting permission tokens into machine-readable licenses. This companion paper outlines a formal means by which this conversion can take place."

• Does this work? Is the language apt? The IEEE 7012 work is relevant here.
• OAuth talks about access tokens and we have used "permission tokens" in order to be relevant to lawyers. Are they connected? How big is the gap, if any?
• What does "machine-readable license" mean? It wasn't intended to be a straight sub for "smart contract", but rather something like a dispositive connection to a permissioning technology. Is a consent receipt a machine-readable license? It's meant to be in arrears, and maybe it could memorialize a license. Should there be an IEEE/Kantara liaison? There's some overlap and some intended informal liaising for such purposes.

What is the ideal outcome of the second report? There are real-life human (relationship) changes. They map into something legal, and those map into something technical. If we can identify the latter two, we can help a variety of parties create (interoperable) solutions in order to reduce friction in solving problems of convenience, trust, compliance... We need to crisp up the value-add of our deliverable next time.

How do we bite off only enough that an RS would be willing to do it? Since enough power licensed by the ASO to the RSO ("licenses-perm-granting-to" and a lot of downstream stuff) hinges on the PAT, and that hinges on a client agreement, the strength of that agreement – and perhaps any technical stuff that can strengthen it such as signing – becomes important. The other half of what's interesting is all the requesting-side mappings, including the "licenses-perm-getting-to" (bifurcated into CO and RqA). We have question marks there around the fact that the front channel is used a lot for the RqA, and that's invisible to auditing a lot of the time.

2018-03-02

Attending: Eve, Colin, John, Kathleen, Mark, Tim, Thomas, Bjorn

...

• 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

...