2016-10 (October 2016) Meetings

Owned by Eve Maler
Last updated: Nov 03, 2016
10 min read

This page records the Discussion Group's meeting notes for September 2016. We meet Tuesdays at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET and Thursdays at 11am PT / 2pm ET / 7pm UK / 8pm CET for 60 minutes. 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, September.

Tuesday, October 25

Agenda:

  • Report writing – Sovrin Foundation questionnaire answers discussion

Attending: Eve, Thomas, Matisse, Kathleen, SteveO, Thorsten

Meeting logistics: Just a reminder: No meeting this Thursday. Also, when we take up meeting again next week, UK and Europe clocks will have changed, but US clocks won't have, and US Pacific is our normative time zone (see timeanddate.com for "summertime skew" details...). Please keep an eye on and/or subscribe to our calendar!

New book: Don't miss Thomas's new book, called Trust::Data: A New Framework for Identity and Data sharing! Wow. Congratulations!

Sovrin answers: You can find them in your inbox or in the email archive. See also the paper Thorsten mentioned in email.

Overall, Eve's question for each use case, differentially, is: How much does limiting the risk of a "pure public blockchain technology" approach impact the goals of the use case, and particularly in our case where the use case goals are for empowerment? E.g., for some fintech use case where you want to speed up business and protect against legal risk, maybe limiting the "distributedness" of the blockchain to your enterprise – that is, inside your firewall – could be fine. But for other use cases, that could seriously harm you goal. So for today, given that Sovrin has a goal of self-sovereign identity, have they been able to successfully mitigate risk while enjoying/providing the benefits of blockchain ("walked the line correctly")?

"Self-sovereign identity" sounds like an extension of the previous notion of "user-centric identity".

Thomas's CoreID paper caused some people to accuse him of being a communist (smile) for proposing a blockchain identity system that enables anonymous credentials. Eve's question is: What ecosystem that involves both individuals and services could function without at least some (probably the lion's share of) use cases of identified sharing?

There are some "anonymous authorization" (Shibboleth) and "claims-based access control" (UMA) use cases, indeed. (And notice that these use cases didn't require blockchain to be solved) But quite often, (empowered) service operators do need to know who they're dealing with among (currently disempowered) individuals. See Latanya Sweeney's research on the ability to re-correlate individuals from a few attributes; hence Eve's skepticism about ZKP approaches (which Sovrin criticizes as well). Users also have real incentives to share data with services in many cases because otherwise the services can't function.

Are there any services accepting Sovrin credentials yet? These are apparently called "stewards".

We looked at the Technical Foundations paper. The observer/validator/governance paradigm seems well thought out. Thomas noted that the widening circles of nodes looks like what Ripple has. The governance model could perhaps be a model/template for other use cases as well.

Not depending on IdPs sounds like a big benefit. People have been become persona non grata on various services that function as IdPs (such as being shadowbanned or outright banned on Twitter), or have been monitored by government IdPs. However, the reality of many service providers is that they rely heavily on these 30 social IdPs for a lot of what they do, both the user population and the information provided by these service sources. ("Social login" is when they rely totally on the incoming IdP for information, and "social registration" is when they explicitly collect additional information and do separate login thereafter.) What is the value proposition for these RPs?

Also, how would legacy "federated SSO" work (a la SAML or OIDC) in this new world?

AI: Everyone please continue to review the questionnaire answers (two sections left to go) and provide thoughts in email. We can send our questions to the Sovrin folks after our review is complete.

Tuesday, October 18

Attendees: ScottS, Kathleen, Matisse, Thomas, JohnW

AIs for Report:

  • Text from contributors
  • Terminology and definitions

Report to dos:

Kathleen working on HL7. Jim Hazard has been talking in UMA legal, with many similarities with FHIR work. Question is what will the Smart Contract look like, what will it do. Adrian also writing up text.

Kathleen: reach out to Jim for text. Also Adrian has text from the ONC Blockchain Challenge.

Thomas: anything missing from the Report? Kathleen: need a definition of SC. Scott: yes, we’re not quite there. Also expand to a list/taxonomy of definitions and terminologies for the report.

Potential Liaisons: groups that members of BSC are involved and list of relevant orgs looking at SC

  • HL7
  • GA4GH: Global Alliance four Genomic Health
  • CommonAccord
  • GTRI: Georgia Tech Research Institute
  • OTTO: Open Trust Taxonomy for OAuth
  • Federated Authorization
  • Smart Contracts Alliance
  • Kantara’s liaison with JTC1/ISO (Identity Assurance & Management)
    • UMA WG
    • CIS WG
  • New ISO group on blockchains (ISO TC307)
  • Sovrin
  • JLINC protocol – JSON-LD may be used for SC.
  • BlockchainCanada.org

AI: Thomas: start email thread on definition of SC.

Thursday, October 13

Agenda:

Attending: Colin, Adrian, Marc, Thomas, Jim Hazard, Kathleen,

Went through the bulleted list from Adrian.  Thomas: this list of also what is needed for Smart Contracts (e.g. subject, user, resources, etc). A smart contract has identities of originator, destination (counter-party), dates/durations, conditions (which may depend on external data sources - resources), agreed set of data-feeds (resources), source-authenticity of the data-feeds/sources, even perhaps agreed nodes/platforms to execute the contract, etc.

Adrian: Using a blockchain tech, you can create a UMA without federation. So it becomes a "federation-free" to perform transactions involving personal data.User is running the UMA-AS and signing contracts with hospitals.  The contract control how hospital A shared my data with hospital B. Adrian's assumption is that the AS is a user-owner resource. Two types of contracts: first contract is the registers a resource that has my data with my AS (delegation of authZ).  The second contract is the Hospital A and B.

Adrian's maps the world in 2 phases capturing the 2 constructions of contracts. The first contract is telling the institution "here is my AS and resources under the control of my AS" (bilateral or trilateral).

Kathleen: text sent to Eve/Scott for pre-review.  HL7 has based its work on foundation standards (e.g. access control; privacy; policies, etc). Examples: ISO/IEC 10181. How to use attributes to make access control decisions (e.g. RBAC). Agreements on security and privacy policies. Not a full trust framework, but more on federated authentication: how 2 or more domains establish trust. How to expand from narrow to wide ecosystem: how to move away from centralized model to a direct trust model (e.g. using Stellar consensus model). How to express this trust in smart-contracts. So that if data "falls-off" or "escapes" that you can no longer use that data. How does the RP check claims etc in a direct (non-centralized) model.

Adrian: important to express difference between the federated model vs the blockchain model.  The Federated model is able to get hospital A and B to share data about User without immediate consent from the User.  Adrian thinks we need 2 contracts. Here is the UMA-AS is acting as the agent of the RO (resource owner). The RO does not need to be present 24x7.  The issues:  are the policies visible to external entities. In Adrian's case, the policies are never visible.

Kathleen: in this case, the AS will honor whoever is able to prove trust. So the 2 models are compatible. The access policies are not necessarily visible.

Jim: we need to separate "smart contracts" from blockchains".

Adrian: how can we start a SC withiout placing the policies (driving the SC) into the public domain. Policies means the riles of access: If I'm Alice and I don't want share my rules/policies (about accessing my resources), how to do this in SC? In the UMA case, the rules/policies are in the UMA-AS.

Jim: an SC does not need to public.  In this case, Bob could take a shot and see if it works.

Adrian: there are lots of similarities between SC and UMA. Jim: the SC record codifies the legal text and executable. Thomas: yes there should be commonalities between UMA-AS and SC/Blockchains.  SC has "if-then-else" which are like rules of access in UMA for AS, RO and requesting party. A node could in fact add UMA-AS capabilities.

Kathleen: for the BSC report, we need to express some kind of "future roadmap" on how to get from here to there. Thomas: may be suggest some recommendation points.

Marc: need a development methodology, just Jim/thomas paper at W3C blockchain conference in May: https://www.w3.org/2016/04/blockchain-workshop/interest/hazard-hardjono.html. People in France are also struggling on how to get from current legal model to SC in the future.

 

 

Thursday, October 6

Agenda:

Attending: Eve, Scott S, Adrian, Kathleen, Matisse, Colin, Marco?, John W?

Matisse has suggested the blood diamond example as a case study to analyze for this properties of enforcing ethics at a technology level. Here's a YouTube video on it. This could be extended to several provenance use cases. Scott notes everledger.io as a company offering blockchain-based fraud detection services for insurance purposes, where the generic use case is fraud detection and the specific case study involves ethics of blood diamond provenance. The ivory trade could be another ethics use case. See also this article. The current process is Kimberley Process certificates. Apparently the Kimberley Process is looking at blockchain now.

Would Matisse be willing to take on the assignment to write up the blood diamond case study? Scott S is interesting in this too. Matisse is only free after her PhD thesis is done in a month's time, and would like a structure. How about this for case study structures?

  • Deficits and benefits of how the problem space was/is being solved
  • Proposed benefits of the new solution space – crystalize this (e.g., fraud, not "user empowerment"?)
  • Different approaches being taken (e.g., whitelist? blacklist? other?) in the new solution space
  • Strengths, weaknesses, risks, and open issues being seen in practice
  • Cross-references to the appropriate other technology, case study, and use case sections
  • Since our Report process is time-boxed, go into only as much depth as you can in a short period of time

AI: Scott S: Attempt to turn the draft case study structure into a questionnaire and see if we can reach out to everledger.io to try it out so we can begin to fill out a case study section with the results. We always reserve the right to massage any answers we get back, to do more research, and publish information in our own words.

Note that it's possible to put diagrams in the final report. We will make sure of it. All report authors should feel free to submit diagrams and graphics.

Discussing the language Scott has contributed to the Certificate Transparency section of the report: We suggest adding a bit of discussion about the weaknesses of PKI, and the optimistic assumption of much blockchain technology about PKI and how identity can just use a clean global PKI system. Also, how much of blockchain node participation is anonymous, how much of the time? The notion behind Certificate Transparency is to force, at a technical level, knowledge of what you've got. The section could contain cross-references to the other technology sections.

AI: Eve: Find for Scott S the "Let's fix HTTPS" presentation that explains why browsers are never going to get better at cert management.

Thomas reports that he is working on his IPFS section. Kathleen is working on her HL7 section.

Eve's thoughts for her UMA section run in this direction: UMA's primary goal is empowerment for a particular type of transaction, which is sharing of digital resources. In the course of coming up with an architecture for that, UMA invented an interestingly powerful service (the AS), which is, however, a centralized entity that must be trusted. (Adrian's "pure" form requires this to be chosen by the individual, akin to a public blockchain that is completely decentralized, whereas most initial deployments are expected to be akin to a permissioned blockchain that we could consider less "pure".) The work on UMA Legal attempts to mitigate the risk of having central services matching up to distributed APIs. More brainstorming on UMA section ideas:

Adrian's formulation of requirements sent to the list:

Trust and personal data

  • identifying the patient that is the subject of the data,
  • identifying the user requesting patient data,
  • recording and auditing the authorization to release the patient data,
  • establishing the authenticity of the data that is being released,
  • paying for the service that delivered the patient data,
  • controlling and auditing that the shared data was used as expected.

Eve's revision: ???

  • Identifying the resource subject
  • Identifying claims about the user requesting access
  • (something about authorization itself??)
  • Recording and auditing the authorization to access the resource
  • Establishing the authenticity of the resource that was accessed
  • Paying for the service that delivered the resource
  • Controlling and auditing that the resource was used as expected

We made a few changes in the report itself as well.

Tuesday, October 4

Agenda:

Attending: Eve, Thomas, Kathleen, Scott S, John W, Matisse, Adrian

N.B.: Many of us will begin to see daylight saving time weirdness in the timing of BSC calls this month and into the next. Please note that US times are normative during daylight saving time changes! Please double-check the DG calendar if your local clock has changed.

We gave out additional technology writeup assignments. No new text was written yet, but we will expect at least some for review by Thursday. The assignment in each case is:

  • A definition
  • A short discussion of strengths and weakness of the current way of doing things
  • A short comparative discussion of strengths and weakness of the new way of doing things (if the technology/technique is "new")
  • Pointers to the other technology and technique sections as appropriate (so that we have cross-references among the sections)

The blockchain section will end up being the most complex and lengthy.

Discussion about "public and private blockchains have different dynamics": How different is the dynamic when anyone can can write a block to the chain vs. there has to be a trust framework determining who can write a block to the chain? How does the value to an individual (read: disempowered party) who wants to use the resulting blockchain-based system change? We looked at the example of OpenBazaar.org for trading any goods in a peer-to-peer fashion, vs. a traditional non-blockchain-based system like eBay, vs. a private blockchain-based system where you have to get into the trust framework (the "club")?

Discussion about public, private, different consensus protocols, etc.: There's an interplay of consensus types and governance types. OpenBazaar in particular may require node participants to sign an agreement (according to Thomas's tentative understanding), although node participants may be anonymous – we're not exactly sure.

OpenBazaar might be a good compact intro-level example – or a worked case study. It's just a bit more controlled than total anonymous/anarchy. It was started to illustrate that e-commerce transactions can be legitimate in an efficient P2P environment, removing huge third-party coercion (Amazon, eBay) concerns – but the big parties can mitigate the risk of a bad actor in the way that we suspect P2P system can't. We should research their level of contract/governance imposition to see if it contains a solution to weed out bad actors.

The identities/parties in this picture: Individuals who want to trade; node miners; OpenBazaar itself; who else?

AI: Eve: Ask Thomas to follow up with OpenBazaar or make introductions with some other BSCer.