4/5: Tools and Rules for Blockchain-Backed Individual Identity

This 5-part Legal Hack Night series is dedicated to rapid dev of a blockchain-backed individual identity digital signature application as an integrated business, legal and technical working prototype to better understand, evaluate and advance beneficial use of individual identity innovation.

The May 30 Legal Hack Night wiki for collaboratives notes and other materials is: https://github.com/MassachusettsLegalHackers/BCID/wiki/2017-May-30-LegalHacknightProjectNotes

Prototyping to Achieve Predictable Legal Outcomes

This rapid development process and the resulting prototype is focused on testing whether the use of blockchain technology will produce predictable legal outcomes. To the extent we can anticipate uncertain or anomalous legal results for one or more of the parties, we will adapt the business, legal and/or technical aspects of the prototype to provide greater certainly through contracts and/or by restructuring problematic aspects transactions or the roles/relationships of the parties using the technology. We plan to conduct a mini "Mock Trial" of a hypothetical dispute involving use of the blockchain technology and assume a simplified version of how the evidence and controversy would be handled under the rules of Suffolk County Superior Court in Boston, Massachusetts.

The fourth session of this series will be dedicated to testing and refining the Stonepaper Ethereum Blockchain smart contract based digital signature application. To support the legal aspects of this rapid prototype work we'll also continue gathering existing click-through terms, user authorizations, B2B contract provisions, legal notices and other relevant system rules as examples.

Background Materials:

• Reference materials and project documentation can be found in the Massachusetts Legal Hackers GitHub for this Blockchain ID project, at: https://github.com/MassachusettsLegalHackers/BCID

• The notes from our first MeetUp of this series can be found at: https://github.com/MassachusettsLegalHackers/BCID/wiki/2017-March-28-LegalHackNight-ProjectNotes

• The second and third sessions focused on informal discussion to identify and detail an appropriate hypothetical factual scenario to anchor the technical and legal use cases. We settled on a 3-Party scenario spotlighting a person signing a typical contract (in their individual capacity) for the purchase and sale of a used car with a small business used car dealership . The contract is agreed and executed using standard digital signatures and enabled by a US Federal Credit Union app that created an Ethereum blockchain address and makes the cryptographic key pair for that address reusable for digitally signing the legal contract and other authorization, delegation and consent transactions.

This hypothetical factual scenario will provide a sound foundation to walk through activities and interactions of each key party and start evaluating the best candidate approaches to establish legal rules, roles, relationships, rights, responsibilities covering the three key players:

1. The Individual Principal in their role as a party legally signing contracts and making other authorizations with their own blockchain-based identity by using the App to conduct transactions on the web;

2. The Fiduciary Agent in their role as a party who acts on behalf, at the behest and in the best interests of the Individual Principal as their Member or Client, respectively and and who provides or is responsible for platform or other business services in connection with the individual app; and

3. The Transacting Third Party user, in their role as a party who legally countersigns contracts and is a relying party on authorizations as a counterparty to transactions conducted by or for the Individual Principal.

In the use case, the Fiduciary Agent will presumably be a US federally chartered, regulated and insured credit union providing services to and acting on behalf of an Individual Principal who is a Member of the Credit Union. The Ethereum Stone Paper initial code base assumes the fiduciary is a hybrid between a Notary and a Licensed Attorney providing services to and acting on behalf of the Individual Principal who is a Client of their law practice. For technical purposes, we aim to customize the technology to allow for a range of Fiduciary Agent and Individual Principal pair-wise relationships, while continuing to support, reflect and assume the full customary set of fiduciary duties exist as a legal foundation of the integrated business, legal and technical dimensions of our working prototype.

• Resources for the third Meetup session of this series can be found at: https://github.com/MassachusettsLegalHackers/BCID/wiki/2017-April-25-LegalHackNight-ProjectNotes (https://github.com/MassachusettsLegalHackers/BCID/wiki)

• Resources for the fourth Meetup session will be drafted at a project wiki page. We will add the link here when the page is created. Meanwhile please consult the wiki page for the third session and please take a moment to read up on Stonepaper. Thanks and Attributions: We are grateful for the generosity of Code for Boston (a Code for America chapter) for hosting our group as part of their regular Tuesday Civic Hack Night. For more information on the Boston Brigade of Code for America, see: http://www.codeforboston.org (http://www.codeforboston.org/) This Massachusetts Legal Hackers rapid prototype initiative also uses, extends and contributes to the law.MIT.edu computational law research project "CoreID.me" about which more can be learned at: https://law.mit.edu/blog/core-identity-blockchain-project and http://CoreID.me