...
This page records the Discussion Group's meeting notes for November December 2016. We meet Tuesdays at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET and Thursdays at 11am PT / 2pm ET / 7pm UK / 8pm CET for 60 minutes. US times are normative during daylight saving time changes. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options, web interface, more info, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar for our full meeting schedule. Previous meeting minutes are here: July, August, September, October, November.
| 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:
- Report work and recommendations
Attending: Eve, Matisse, Thomas, Susan, John W, Colin, Kathleen
Symbiont spoke at the NAIC conference yesterday about identities (corporate exclusively?) and smart contracts. This relates to beneficial ownership. We appear to be on the cusp of this being figured out because of the pressure from corporations, at least. So it may behoove us to make recommendations about natural-person identity work regarding several efforts, e.g. several WGs in Kantara. Susan also attended the Smart Contract Alliance event this past week, where there were three regulatory agencies represented, speaking about how things might work for them. Personal identities are going matter to them, but they have no concept of this – they just know about KYC (Know Your Customer) in a regulatory sense. "If you want universality, it must be imposed by some external standard. If you want autonomy, you must recognize individual choice. These two are in some sense antithetical." If something like Sovrin is widely adopted, Eve suspects its uses would devolve to KYC-type use cases.
We could essay some of these principles (and oxymorons?) in our intro. There are no silver bullets in "self-sovereign identity".
Microsoft announced that Dan Buckner is forming a unit around something similar. Thomas notes: It's all about the data, and who has control over it. Is it considered a joint asset or not? A concept called the LLP – Limited Liability Persona – used to be floated (by Bob Blakley? Burton Group folks, at any rate). Some banks do seem interested in giving their individual customers control over releasing their own KYC data in personal data store-like fashion, DLT or no.
In terms of the logical choices of where to store a person's PII:
- 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:
AI: Eve and Thomas: Put the above text in the draft report.
There's an interesting challenge with allowing people to control access/permissioning as the primary goal vs. allowing people to control personal data as the primary goal. Client devices are generally not meant to be running all the time (e.g. to serve relevant data), whereas a transaction (such as making a payment) generally requires that a service be up and running. Imagining that a person's mobile device is a storageless UMA authorization server that can access what it needs in the cloud and makes a callback, would that work if a requesting party Bob tries to access Alice's resource?
Next time: 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 in order to meet our DG's goals for transactional empowerment of individuals.
Thursday, December 1
Agenda:
...