This page records the Discussion Group's meeting notes for July 2016. We meet Tuesdays for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET and Thursdays for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET (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.
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Tuesday July 19
Agenda:
- 15 min: Sharpen our deliverable ToC/value prop
- E.g., focus on transactions/contracts aspects? verticals/sectors? what other constraints to make our goals achievable and valuable?...
- Choose a mini-goal for Aug 5 (the one-month mark)
- 15 min: Thorsten: present IRM touchpoints and next steps
- Homework for Thursday: next steps on patient consent for research (?) use case
Attending: Eve, Thorsten, Jim, Marc D, John, Philip (Thomas regrets)
Sharpening our deliverable: Is our primary audience the Kantara leadership, as John suggests? Kantara is in the business of identity innovation and interiorinterop. Jim notes that he's discovered the centrality of identity to his purposes, while blockchain is really one of a variety or family of technologies that are potentially relevant to his purposes, namely "moving legal onto GitHub, more or less – making legal processes cheaper and faster and getting them closer to user control and autonomy". Other technologies : IPFS and so on.
We seem to have achieved rough consensus about this vision for the scope of our briefing note: We want to focus on use cases that are about "contracting and transacting" in the context of empowering individuals, smaller companies, smaller countries, and communities in a "peer to peer" way with larger companies and countries etc. (not meaning P2P technologies necessarily, though it might do so). "Legal" means a formal statement of relationships, and it could include contracts, permits, consents, and so on. All legal documents increment relationships between some "Persons" (including both human and non-human).
IRM presentation: Thorsten presented some thoughts (of his own) on the IRM principles. We're thinking that capturing various technologies adjacent to blockchain (many of which he has listed here) and presenting an analysis of them in our briefing note would be a valuable idea.
Scott (not on the line but on the screenshare) added this link to a taxonomy of identity types, including human and other.
AI: Eve: Create a GDoc that would be a briefing note dumping ground for outline ideas (see above re Thorsten comments).
Thursday July 14
Attending: Eve, Jim, Scott, Thomas, Thorsten, Colin
Thanks to Scott we have a new Use Cases page! Eve speaks in favor of having champions and recording stakeholders, where possible. Scott will add. Here's the template. Adding web sequence diagrams is a very nice touch.
Thorsten's email about IRM liaison opportunities probably doesn't contain use cases as such, but their work on "IRM in the wild" may bubble up use cases, which we can capture here.
Okay, returning to discussing our current use case: Jeff S stated in email the concern that getting proofs that something happened out of a blockchain is not going to be as scalable or performant as we might be assuming. For example, we're talking about consent receipts. If an individual argues they didn't consent, and the service operator argues they did, and it's two years later, and it's hard to find that needle in the haystack, what good is a blockchain?
Does IPFS help?
Certificate transparency (see the RFC and the Chrome implementation) is a model where the CAs publicly attest to the certificate so that you don't have to "trust the CA". Does this help the problem we're discussing, where it's hard to get "recorded truth" out of the ledger?
J-LINC Labs uses Stellar as a lightweight consensus protocol. Interledger was also mentioned; Jim has looked at it and likes it.
Jim's take is that blockchain is really a notarization service – just validating a record. He believes Bitcoin doesn't need all that strength; you could use a (central) trust provider instead. In most social transacting, you probably don't need all the blockchain infrastructure. On the other hand, it's the best solution for the worst case: It's for the wide ecosystem. It's for the Internet (or disconnected) use cases where there's a lot of loose coupling.
Given that blockchain is therefore a social mechanism, and consensus is social, and blockchain seems best suited for "lack of centralized trust" use cases, Eve shares her concern about relying on lightweight consensus mechanisms if they open the way to vulnerabilities of a social/sociological/business sort (vs. a purely technical sort).
Let's look at our current candidate use case, and others, with an eye towards the wide ecosystem implications.
Tuesday July 12
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called Digital Contracts, Identities, and Blockchain and Digital Identities, Contracts, and Blockchain , had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes
- Business track notes
- Healthcare use cases track notes
- IBM Open Blockchain white paper
- Article on bootstrapping a bosses organization
- Screenshot from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?)
- CommonAccord intro presentation
- CommonAccord site
- CommonAccord Slack team invitation
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
AI: John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
Tuesday July 5
Eve is taking notes and is happy to take notes in future.
...
- Jim Hazard - Lawyer frustrated with word processing
- Eve Maler - ForgeRock - interesting UMA/smart contract connections
- Thomas Hardjono - interest in getting a high-level language specified for contracts
- Andrew Hughes - runs the Leadership Council
- Jeff Stallman - blockchain developer
- Scott Shorter - Kimble & Associates - doing some ONC work, auditing, and governance
- Don Quigley - services leader for directory services for GE
- Marc L. Aronson - president and CEO of Pennsylvania Association of Notaries
- Kathleen Connor - consultant involved in UMA, UMA legal, and ONC
- Ann Vroom - private individual interested in blockchain
- Clare Nelson - AllClearID
- Thorsten Niebuhr
- John Wunderlich
- Javier Moreno
- Colin Wallis
...