A TLA for the BLT

This post was originally posted on Medium in 2017.

We live in an age of Three Letter Acronyms (TLA’s). It’s a function, perhaps, of increasing levels of specialization and jargon combined with a certain social impatience that devalues vocabulary (Can you distinguish between the correct usages of transform and transmogrify)? But if I set aside the snark it is still true that jargon and the use of TLA’s can make communication within a community more effective and efficient. The correct use of TLA’s also becomes a sign that you are part of the community, or can act as a barrier to entry to the community, but that’s another story (RTFM, LOL).

One acronym that gets tossed around in some communities is “BLT”. This refers to the parallel layers of Business, Legal, and Technical issues that often need to be resolved to move from problem to solution. It turns out to be a hard problem to have a Business relationship with Legal affect that can be easily represented in Technical artefacts.

For example, the business challenge of monetizing a website by processing personal information is currently addressed by the legal artifice of a TOU (Terms of Use) that we are magically supposed to have read and assented to before using a site. This is technically implemented by a readily available link to the Terms of Use on the bottom of the web page. But nobody reads those terms. The user experience is terrible (who actually likes listicles?). And, from a privacy and user autonomy perspective, the notice and consent provided by standard form contracts is weak at best, and does not work at Internet scale.

We have not yet come up with a good tool to connect the business, legal, and technical layers. More specifically, the problem is connecting the technical layer to the other two. There are centuries of development and tools for connecting the business and legal levels. The question becomes how to reliably connect the technical and legal layers in a way that simultaneously satisfies the requirements of programmers and lawyers?

One solution is to try and encapsulate everything in the technical layer and avoid the necessity of connecting to the legal or business layer. Who needs lawyers and contracts when you have programmers and code, right? (Some will, and some won’t, read that as ironic). This was a design goal of the dao on ethereum and is one way to look at smart contracts.

Another solution is to express the elements of a legal agreement in a file that can be processed by software. These agreements are called Ricardian contracts and CommonAccord is an initiative to create global codes along these lines. The result includes what can be called wise contracts. They can be processed by software, and produced as text. But the use of Ricardian contracts is built into no Internet protocol that I’m aware of.

Neither of these solution seem satisfactory in the long run.

This is where a new TLA comes in. I was talking to Mike Schwartz from GLUU at the Internet Identity Workshop (IIW) recently. We chair different Kantara Initiative Workgroups but the discussion reminded me that this is a common problem — pinning the technical to the legal. The generic phrase that popped into my head was:

Legal Reference Token (LRT).

An LRT is intended to be a generic term to indicate an object, or file, that can be managed in software but that refers to a legal artefact that can be reliably produced on demand and which can be relied upon in the event of a dispute. This meets and connects the demands of the two layers. The legal layer will have access to the text and content of an agreement or contract for lawyers as necessary, while the technical layer has a technically manageable object to use. If you really want to stretch the metaphor, a legal reference token is a toothpick that connects the legal and technical layers in a BLT.

An example would be a copy of a contract negotiated and signed in a JLINC transaction. An LRT would be any artefact pointing back to the draft contract, the signed contract, or the hashed & signed record of the contract during or subsequent to the negotiation, agreement, and signing of the contract.