This page records the Discussion Group's meeting notes for July 2016. See the DG calendar for our meeting schedule. We meet Tuesdays for 30 minutes at 7:30 PT / 10:30 ET / 3:30 UK / 4:30 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 http://join.me/findthomas for both voice and screen sharing.
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. Interledgar 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.
Attendees and introductions
Please send introductions to the list if Eve got anything wrong!
- 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
What is a DG about?
A DG has more informal deliverables. It might, for example, recommend formation of a WG.
There are several Kantara WGs and efforts that have a legal flavor to them:
- UMA, with its UMA legal subgroup
- Consent and Information Sharing
- The Identity Assurance effort, with its trust framework components
Smart contracts, broadly defined as executable code to represent legal agreements, are one way to approach agreements.
Participant goals
Jim briefly described his work on digitizing legal agreements. Eve briefly described some discussion from the Digital Contracts event/workshop of six weeks ago. The worlds of smart contracts and digital contracts that use natural language are distinct. There’s a gap between them. It seems to be narrowing, but there seems to be urgency about closing the gap and connecting them.
Mark says that notary had been used previously as a synonym for timestamping. Now blockchain is coming to the fore in the same way.
John would like to clarify what goes, and what should go, on a blockchain.
Jim believes that smart contracts would be good to focus on independently of how they themselves are recorded. Blockchain is often the wrong way to store information.
Jeff concurs with that. Blockchain is a suite of technologies, and you don’t always need all of them.
Kathleen is working for the DHA security architect. The overhead for establishing trust frameworks is incredible. Adding agility would be great. Also, helping privacy, security, and administrative parts of healthcare to scale — HL7 V2, V3, and FHIR — is important.
Clare is a fan of Steve Wilson of Constellation. UBS is spending a lot of money in financial services. She’s interested in pursuing a conversation along that path.
John also notes that “contracts of adhesion” that often force individuals to accept terms and conditions are another use case where scalability of forming agreements would help — in this case, help individuals directly.
Scott brings up a long-ago goal of technically verifiable agreements that have been parameterized. It now seems a lot more possible.
Logistics and deliverables
How often to meet? Andrew recommends five months of intensive meeting and discussion, one month of intensive writing, and the reporting out. Several people speak up in favor of frequent short/intensive meetings.
Deliverables? Thomas suggests a use case document, ranked by priority. John summarizes the discussion by suggesting a final deliverable that would be a briefing note that contains “what is a BC, what is CmA, what are the kinds of contracts that have ‘smarts’, use cases, issue identification and analysis”, etc. We could take a look at some of the outputs of the Digital Contracts event held May 23-24, which Kantara helped to sponsor as part of our work.
Jim met with Bart Suiches of the Philips Blockchain Lab subsequently to the Digital Contracts event and discussed patient consents as a use case. John cautions about using health as our first or primary use case for discussion. Jim agrees that it’s the hardest case, which makes it attractive to him. But we can start simple. Bart told him they’re absorbed figuring out the GDPR.
Don’t forget that we can use our mailing list for discussion.
Next steps
AI: Eve: Share out links to notes and artifacts from the Digital Contracts event.
Let’s meet twice a week for 30 minutes each, at different times to spread out for US and Europe, and to avoid the UMA call. They will be (we think) at Tue 11am ET and Thu 2pm ET.
The group reached consensus on having Thomas and Eve as co-chairs.
Scott kindly agreed to serve as use case collector on the DG wiki. John created a use case template for CIS WG usage we might consider using.
AI: Thomas: Send out a note confirming the call times and set up the call dial-ins with Shannon.
We’ll start the repeating call series next week.