Versions Compared

Old Version 35

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

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:

...

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.

...

  • 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

...