This page records the Discussion Group's meeting notes for September 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. Previous meeting minutes are here: July, August.
Friday, September 15
Agenda:
- Informal report writing
Attending: Adam, Thomas, Kathleen, JohnW
Friday, September 13
Agenda:
- Informal report writing
Matisse, JohnW, Kathleen, JohnM, ScottS, Thomas, Adrian,
Continue the use case.
MedRec use case: Tracking medical records on blockchain to track. Patient (Alice) wants control regards to who she shares data with, revoke consent, etc. PM needs more specific info regarding patients (e.g. with HIV of a given type). Similar to UMA.
Bchain provides method to log access to patient data in an immutable manner.
JohnW: patient has not choice/control who the receiver of the data. So Bchain provides a way to provide accountability of the entities that access/use Alice’s data. All entities in the ecosystem need to record their accesses to the bchain. The agreement could travel with the data. A private bchain could be used to provide privacy to the patient. Also, anonymous identities could be used while allowing Alice to point to her transactions.
Adrian asked about using hash of the contract (by the provider). Kathleen: yes that’s one way to do it. Matisse: also sees the need to use private bchains. JohnW: desirable outcome is to not have 1 gatekeeper. Use the distributed models inherent in bchains today. (see CISWG diagram). Adrian: Vermont bill may allow orgs and governments to accept evidence recorded on a blockchain.
Adrian: 3 uses of bchain: identity, timestamp, AppCoins.
https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf
Friday, September 9
Agenda:
- Informal report writing
Attending: Eve, Andrew, Thomas, Domenico, Luk?, Kathleen
Thoughts for the report: If some topics aren't "use cases" because they assume technologies/techniques, could we still include them as "tests" (e.g. real-world case studies that use blockchain)? MedRec is one such case study. That would allow us to include a lot of up-to-the-minute information.
Also, we would like to include some thread of blockchain vs. smart contracts. We already have this covered in the report outline.
We're thinking that maxing out on the number of use cases and case studies (five each, or even less) will be fine; that will elicit the analysis we need. We could easily analyze up to five actual real projects/pilots/POCs ("case studies") out there; there are so many. The distinction in the name is "theoretical vs. actual". Hmm, we might not want to put a limit on case studies as long as we keep illustrating real technologies/techniques. Let's limit theoretical use cases, though. In which case we've probably hit our limit among those submitted.
We'd like to propose that our meetings use a pattern in our meetings of using the half-hour for use case work, and a second half-hour for deep-dive report writing (that is to say, doing this twice a week).
Next week Eve can't attend due to being awesomely in Barcelona. Can Thomas run the meetings next week? Please confirm to the list.
Kathleen took an action to flesh out some MedRec case study text for next week.
Tuesday, September 6
Agenda:
- Pick a time for an ad hoc report working session
- Work on use cases on the call (finally!)
Attending: Eve, Kathleen, Jeff S, Adam M, John M, Scott S, Domenico, Adrian, Jim, John W
NOTE: No BSC telecon this Thursday because we couldn't find a chair pro tem.
Eve, Thomas, Kathleen, and Scott D had expressed particular interest in an editing session. We'll work out a time for that and advertise the time. (John W and Domenico have some interest.)
Regarding the Stellar Consensus Protocol-involving use case: John W notes: "Disclaimer re: Stellar Consensus Protocol. I work with JLINC Labs which uses the Stellar blockchain for our open source JLINC protocol."
John M describes his new "Evidence Notebook" use case: It's trying to achieve what Jim describes as proof-of-existence in a way that can be private at first. He provides three variations, e.g. to provide signatures. Community peers could even provide counter-signatures even if they can't see the content. He's prepared for lots of discussion over all of this. Adrian ties these ideas to his for doctors signing patient-centric prescriptions, noting that no smart contract is needed in his scenario; for John's use case, the signature is independent and doesn't need smart contracts while the escrow does.
Observing commonalities in use cases: John W sees that there are attributes (facts??) that are frozen and verifiable. In the identity space, these might be identity attributes.
Thursday, September 1
Agenda:
- Working session on report text to capture sentiment around "central tension" (vs. cooperative "outlet") and action items for fleshing it out
- Could result in text in use case(s) and technology/technique description/analysis too
Attending: Eve, Thomas, Matisse, Jim, John W, Adrian, Scott D, Kathleen
We'd really like to delve into all the use cases being contributed. But it seems we need to deal with this elephant in the room; then we can make quicker progress on the use cases and the technologies/techniques!
How to address the tensions and mitigations in our deliverables? There's a kind of recursion we can see in how reliability of interactions is increased (Scott D's traffic lights example). Or is it commoditization? Race to the top? Standardization? All of the above? Almost any use case could do, he thinks, as long as they capture the same pattern. Merkel turtles!
Scott suggests that channel integrity be applied along with reliability here. Financial products are commoditized though intangible. A blockchain is a time machine. Jim adds: Each event is a record, linking to the prior state and to any code or prose needed to execute or understand.
John asks: Is model-view-controller an apt design pattern to apply here? Jim notes: parameters-prose-code seems awfully close.
Applying security and privacy, Kathleen adds the concept of dynamism. Capturing someone's consent requires capturing their parameters.
The forthcoming paper on computational sovereignty is about "Who do you put in the 'turtle' position?" (Turtles all the way down...)
Identity comes in because you need to test "halt, who goes there" and "state your business" (authentication and authorization) and your purpose of use. But then you're right back to the "poison of centralization"! PKI, DNS, third-party asserted identity, IdPs, cross-domain SSO, and all the rest. Unless you're doing "decentralization" in a single-domain sandbox, which is less interesting (discussed on Tuesday), or doing ZKP tricks that are (Eve's position) too technically tricky and expensive for users' desires, IAM today is a centralization play.
Can we call it the "drug of centralization" instead, to be more philosophically neutral? Yes. Or even the "siren song".
Who's interested to put together the awesome 1-2 page summary of this? Eve, Thomas, Kathleen, Scott D.
Scott D points to Cope's Rule in biology as gainsaying Eve's belief that decentralization as inherently unstable in most circumstances. Scott: Rule-making, operations, and enforcement can be separated so that not all need to be centralization. (Also see the network effect.) Eve's version says that "No committee ever recommends its own demise." 
This is why she hopes that we stick to our six-month plan!
Can we find a chair pro tem for next Thursday?