...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Thursday, December 15
Agenda:
- Craft scenarios that aim to maximally empower a person (possibly choosing one or more of those that appear in these notes, but try not to be too UMA-specific!), and work on setting forth the requirements for DLT- and other-related technologies that they'd have to meet
Attending: Eve, Thomas, Kathleen, Susan
What does "empowered" actually mean? Eve points to her "user-centric" criteria as one way to get sharper-edged (see below). What scenarios should we collect? Thinking of financial transactions (since Thomas has been hanging out with FIs 
), that should include getting "universal access" to data, even if (say) it's jointly owned, as in joint accounts. But it's more than data; it's actual transacting, as in payments and buying stuff. Also, online apps should ask for only what's needed, and there should be a sort of "Good Housekeeping seal" she can trust. Think of Uber and what it knows and shares. There's helping Alice make a decision about clinical trials and to what purposes her health data is put. Genomic data is a case of data that's both "jointly owned" and not deidentifiable. (BTW, research isn't covered by HIPAA.)
Suggestion: We need to a) define empowerment, b) select final scenarios, c) assess specific technologies, not very broad ones, and then d) ultimately make observations and even compare them before e) writing recommendations. There is sentiment for using the "user-centric" materials to start to define empowerment.
Let's dig up that other "blockchain identity" technology that's certificate-related from our notes. That should be one of the technologies we assess, along with Sovrin, UMA, Opal, and (what else? other stuff in our outline, etc.).
No official meetings next week or for the rest of the year. Thomas and Eve and whoever else cares to join will have ad hoc meetings during our normal slots. Eve will ask KI stuff to remove the official calendar entries, but we'll advertise the opportunities appropriately.
Tuesday, December 13
Agenda:
...
- Traditionally: Attributes have been stored in something like a directory server, more "voluminous" records (e.g. EHRs) might be stored in something like a CMS, and other databases such as RDBMSes might be used for other personal data. Organizations in charge of collecting and generating this data are by regulation, profit motive, and custom responsible for managing its security and data protection.
- Also: Data can be stored on a client device. It can be protected in various fashions (e.g. encrypted with a private key). (added 2016-12-15; accidentally left off last week)
- With DLTs in the picture: Other options become available:
- Public ledger:Conventional wisdom has already formed, it seems, that you don't put PII on a public ledger. The reasons are: bloat, distributedness, and consumer management of private keys. The two other options given this are:
- Pointers from the public ledger to other traditional server-side storage (a la Blockstack, in presumably most implementations?)
- Pointers from the public ledger to client-side storage (a la Sovrin)
- Private ledger: This can be secured by any traditional means, so it doesn't suffer from the weaknesses of the public ledger approach.
- Public ledger:Conventional wisdom has already formed, it seems, that you don't put PII on a public ledger. The reasons are: bloat, distributedness, and consumer management of private keys. The two other options given this are:
...