Comments and questions on the JLINC protocol for Information Sharing Agreements

Updated 2020-01-24 with answers from Victor, slightly edited for formatting purposes. Thanks, =vg!

My friends Victor and Jim at JLINC have published a set of technical documents that show how to implement “Information Sharing Agreements” – contractual agreements between two parties, where one party receives information, such as personal information, from the other party and commits to only use the received data in accordance with the agreement.

This is basically a respectful, empowering form of today’s widespread, one-sided “I must consent to anything” click-through agreement every website forces us to sign. It’s respectful because:

• it is negotiated, rather than unilaterally imposed as it is the default on the internet today;
• the existence of the agreement, and which parties it binds, can be cryptographically proven by both parties;
• there’s a full audit log on both sides, and so it would be difficult to “wiggle out of” the agreement;
• it can’t be unilaterally changed after the fact, only terminated.

So as I read through the documents, I had some questions, and as usual, I blog them :-) in random sequence. ~~~I will add answers to this post as I find out about them.~~~ Answers in-lined.

• Q: Why is a separate DID method required? I don’t quite understand what is unique about JLINC DIDs that are forms of DIDs can’t do, too.

  • A: The W3C DID working group has specified a “common data model, a URL format, and a set of operations for DIDs, DID documents, and DID methods.” This by itself does nothing - individual DID methods conforming to this model then need to be specified and implemented. See here. There are various DID methods (including `did:jlinc``) listed in the DID method registry. We believe our method is better for -our- needs and use cases – and besides, we understand that one ;-)

• Q: To create a JLINC DID, I need to post something to which URL? The spec says /register but doesn’t identify a hostname. Can it be any? Or is that intended to be a centralized service, perhaps run by JLINC, the company?

  • A: Anyone could read our public spec and create their own registry, but we have put up a testnet and made it available via an open source Node module](https://github.com/jlinclabs/jlinc-did-client). The example config file in the above repo contains the correct testnet URL. When we feel the W3C DID model has stabilized sufficiently we will make available a production-version public registry.

• Q: How do the identifiers that the two parties use for the JLINC protocol relate to identifiers they may use for other types of interaction, e.g. some other protocols within in the decentralized / self-sovereign identity universe? Is a given user supposed to have a variety of them for different purposes?

  • A: This is a question that is being addressed by the W3C DID-resolver community group, in which we are participating. We will make available a JLINC DID resolver when that spec has been published. Every DID contains a (presumably registered) DID method as its second colon-separated value (e.g. “did:jlinc:SOME-UNIQUE-STRING”) so you will be able to resolve any DID whose method your resolver is configured for.

• Q: Why is a ledger and its associated ledger provider required? (Actually, maybe it is optional. But the spec says “may submit it to a Ledger of their choice to establish non-repudiation”, so that implies the ledger is required for that purpose.)

  • A: Supporting audit ledgers is part of our plan but has not yet been implemented.

• Q: There is already a previousId in each exchange. Wouldn’t that be sufficient for non-repudiation if the two parties keep their own records?

  • A: Theoretically yes, but a third-party audit record contemporaneous with each data-transfer event would guard against any nefarious record manipulation that might become possible if there should turn out to be some cryptographic weakness discovered.

• Q: There is also the role of an “audit provider”. How is it different from a “ledger provider”? And if it is, why do we need both?

  • A: Those are two names for the same thing.

• Q: Are, by virtue of the ledger, the Information Sharing Agreements themselves, essentially public or at least leaked to an uninvolved third party? Can I use JLINC to privately agree on an Information Sharing Agreement without telling others about it? If so, what functionality do I lose?

  • A: For most purposes we envision using Standard Information Sharing Agreements (SISAs) that are published publicly, and we are looking for a suitable standards body to work out a format for those and perhaps publish some useful ones, modeled along the lines of Creative Commons. But JLINC will work fine with any agreement, most likely identified with a content-addressed URL, but conceivably even a private legal agreement between two parties, identified only by its hash value.

• Q: When an AgreementURI is used to merely point to the legal text that defines the agreement, rather than incorporating it into the exchanged JSON, would it make sense to also at least include a hash of the agreement text? That way, a party cannot so easily wiggle out of the agreement by causing the hoster of the agreement text to make modifications, or claim to have agreed to a different version of the agreement.

  • A: Yes, ISAs are always identified by their hashes, usually via a content-addressed URL like IPFS or some similar scheme that includes a hash of the content as part of the address.

• Q: There’s a field descendedFrom in various examples, which isn’t documented and is always the text string null. What might that be for?

  • A: The JLINC protocol has been rapidly evolving as we build stuff and discover ambiguities and possible efficiencies in it. That field is obsolete.

• Q: How would a permissionEvent work in practice? Wouldn’t that require the underlying legal text to change? Is there a description somewhere?

  • A: The ISA should specify that the data-custodian agrees and will respect the rights-holder’s choices as they are transmitted via permission events. Then each permission change event is transmitted under the existing ISA, same as with data events.

• Q: Could one use JLINC to govern data that’s much longer, or much more complex, than the typical small set of name-value pairs used for user registration data on consumer websites? Can I use it, say, for the first chapter of my Great American Novel I am sending to a publisher, permitting them to only read it themselves but not publish it yet, or to send my MRIs to a new doctor?

  • A: Yes, absolutely.

• Q: In a successful relationship between a Me and a B, to use the Me2B Alliance’s terminology, it appears that the “data kimono” is gradually opened by the Me to the B. For example, the Me may first visit a website without an account, then register (and provide their name and e-mail address) and a month later, buy something (which requires a shipping address and a credit card number, but only until the purchase is delivered and the data can be deleted again). In the JLINC world, does this require a different Information Sharing Agreement on each step? (particularly for the deletion after shipment?)

  • A: No – see the permissionEvent question above.