2016-07 (July 2016) Meetings

Owned by Eve Maler
Last updated: Jul 28, 2016
10 min read

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. We meet 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.

Thursday July 28

Agenda:

Attending: Thomas, Eve, Scott, Ann, Andrew, Mark, Kathleen, Jeff, Don, John

Research use case: We looked at the use case text and explored the model data sharing consent form, which has been "accordified" in CmA. This is one of the technologies we're explicating and exploring. In Jim's candidate cast of actors, we're missing a likely clinician (dealing with Alice and her treatment for a particular condition) or investigator (looking into, say, an experimental drug), which two roles might be filled by the same person (say, Dr. Whoever). The data might be collected for research generically, or in a different fork of the data flow, it's collected in the course of a specific treatment that Alice is undergoing.

Is there a fork as well for aggregation of data and then dissemination to multiple research teams, vs. direct data donation to a specific research effort? Could be both.

Our concerns would be that the use case:

  • Captures requirements for deidentification
  • Captures the different parties to whom it's being shared
  • Captures the different intermediaries
  • Captures data usage requirements and constraints
  • Captures the ethical considerations for the patient (data subject) but also others sharing part of the same genome
  • Captures the patient's requirements for comfort around consenting so that they can verify compliance of the other parties more stringently (smart contract implications?)
  • Captures cross-cutting jurisdictional regime implications of the patient as a stakeholder (rights vs. property) – affects data usage, compliance, etc.
  • Captures granularity and specificity of consent throughout the consent life cycle (UMA and Consent Receipts implications?)

Kathleen has seen ugly lawsuits where, because even deidentified data was unconsented, it had to be destroyed.

We're guessing that some of the above list items will become standard use case "Considerations" items, and some will be use-case-specific "Observations" items.

Technologies we haven't listed yet include UMA and Consent Receipts; they should be added to the report outline.

Tuesday July 26

Agenda:

Attending: Eve, Matisse, Jeff, Scott, Don, Thomas, Jim, Andrew (from the Kantara LC), John, Colin Lurking

Discussing the outline:

We should ensure that we satisfy the needs of an external audience that shares our purpose too. We could, in part, do this by including a review (John: "environmental scan") of other activities attempting to address some of these issues. The world seems to just be entering the trough of disillusionment. We want to achieve empowerment and the "P2P-ness" in a functional sense, even if not in a strictly technical sense. It's a good idea to reference the Kantara vision/mission wording. Jeff suggests: Maybe we shouldn't say "P2P" at all in our goal, because it implies a (technical) technique too strongly. We could illustrate the power imbalance instead by talking about "contracts of adhesion" or simply talk about addressing the power imbalance directly (brute force method!).

Eve essays a goal: Solve the use cases, with whatever technologies. This may mean not always using a pure blockchain model if that has certain vulnerabilities, or requires a TTP in the mix, or whatever. We could discuss how blockchain has started to be over-applied to solve problems it perhaps wasn't meant for (the root of the trough-of-disillusionment phenomenon!).

From the chat: Technology cannot solve problems that require management and governance
. But technology can provide tools to manage and govern.

Jim shares this link as a resource for helping with the first use case.

Next time: Continue with the same agenda.

Thursday July 21

Agenda:

  • 10 min: Review Tuesday's discussion briefly if we have substantially different people on the call
  • Rest of the time: Figure out the broad outlines of use case #1 in light of our new understanding

Attending: Thomas, Eve, Scott, Don, Marco, Matisse

In doing a use case, here are questions we could consider answering:

  • Who is the party we want to empower or give autonomy to? That would be the "Alice", so to speak.
  • What is the transaction we are describing? This would be the gerund that goes into the use case name. (Like "consent", e.g.)
  • What is the domain of the transaction? (Like "health research", e.g.)

We need a champion to stand up and take the new use case wiki page further. Is that Jim? John? Both together? Please see the new Alice Consents to Health Research use case page for details.

For next week:

  • The briefing note dumping ground to throw eggs at
  • Use case work

AI: Thomas: Ask Shannon to tidy up the calendar.

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 interop. 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 (smile), had some notes as output. Here are relevant links:

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.