...
- Fridays, 8-9am PT
- Please see the UMA home page for dial-in details
- Please see the UMA calendar for full scheduling details: http://kantarainitiative.org/confluence/display/uma/Calendar
2018-01-05
Attending: ...Eve, Tim, John, Colin
Agenda:
- Get the Business Model paper ready for its closeup (International Privacy Summit presentations on Jan 29)
- Discuss satellite papers
Tim has prepared an "experimental brach" of the business model paper, as a draft 7b. It plays off of the semweb/ontology topic. We need to briefly state some things up top (maybe a last paragraph of the Executive Summary?):
- The audience?
- What the UMA protocol accomplishes (the parties by name and abbreviation) – possibly then pointing to a separate paper
- What this paper accomplishes (UMA-compliant licensing)
- A very short example
- The scope (UMA2, not UMA1, and Alice sharing, not AliceCo sharing)
Should we entirely avoid the abbreviations for the parties? We avoided ever using the abbreviations in the specs themselves. Eve believes strongly that we should include the diagrams; we could potentially spell out the terms rather than using the abbreviations.
Is a cloud storage service provider considered a custodian? a bailee? Is bailment transitive? The "Challenge of Personal Ownership" section currently mentions this question. The bank/lockbox bailment analogy is often made outside the digital resources context. These roles should, the theory goes, love UMA. John suggests distinguishing "records", "information", and "data". Owning a record shouldn't mean owning the data. A service provider who's a data controller for an individual doesn't own that person's data. Information is the stuff described by the (digital) data. The subject has rights over the data. When Alice has concerns over her privacy, it's about the data. To date, the paper hasn't dealt with these distinctions. UCITA's definition of "information", unfortunately, is not so nuanced.
If "protocol" is scary, then "standard" would do. If "method" is likewise scary, then "system" would suffice. Talking about "meeting customer expectations" also acknowledges that our audiences are likelier "B2C" than individual data subjects. The first time "standard" is used, maybe it could be prefaced with something like "machine-to-machine communications standard" or "digital communications standard" or something.
In the world of legal devices, contracts (today, anyway) are the "design-time" devices that are stable and heavier relationships, and licenses are lighter-weight relationships that can be determined at run-time. UMA does not require any of the devices to be signed, but in combination with receipts, they could be. Any artifact passed between two entity, signed or not, is visible as identical to both entities and therefore auditable.
Let's continue with draft 7b.
John hypothesizes that, once data is shared all over the place under UMA, a lawsuit will be filed under UMA licensing. Eve naively assumes the judge should be able to inspect the contract and license wording that flows upwards from any obvious template language we provide. Would that be so? Maybe class actions might not be so simple!
AI: Eve: Write the short scope/audience paragraph.
AI: Eve: Try to turn the old Legal Considerations doc into a separate paper we can call out to that provides (hopefully our new set of) UMA use cases and an extended explanation for a business/legal audience of the technical side of UMA.
2017-12-22
Attending: Eve, Kathleen, Tim, Bjorn
...