What information is recorded on the ledger for a consent receipt?


#1

I’ve been reading more details on how Sovrin works I’m trying to get a better understanding of consent receipts. I assume they function like claim attestations in that a unique and non-correlatable key would be recorded on the ledger by the issuer of the receipt and the recipient of the receipt would receive a structure that specifies who it was from and what it covers that was signed with the same key pair.

Do I have that right or is there something else at play here?

Symon.


#2

Bump.

I would also like to know the answer to this question. I’m noticing consent receipts and link contracts are still kind of vague in their definition, and I think these are important pieces in order to understand the architecture as a whole.


#3

Sorry that no one answered this earlier. Here’s a summary answer:

  • A consent receipt is a signed machine-readable document (typically in JSON) that an identity owner has given consent to share specific data with a specific relying party. The term is used by multiple groups and industries, most frequently in the context of GDPR compliance. The most precise definition I know of is being forged by the Kantara Consent and Information Sharing Working Group—see their Consent Receipt Specification page. However at Internet Identity Workshop they said that it’s still not done.

  • A link contract is a more powerful data sharing control than a consent receipt (which is why it is called a contract and not a receipt). The term originated with the OASIS XDI Technical Committee, and it is described on this Wikipedia page. The core idea of a link contract is that it is a machine-readable document (again, typically in JSON) that can be read by a software agent to understand and control the data sharing permissions that apply to a specific set of data. For example, if I give you a link contract to my personal contact data, the link contract might say you have permission to ask me for a copy whenever you need it, and also that I promise to send you a notification whenever I have updated it, but that in all cases it’s only for your own personal use.

So the two concepts (and data structures) of consent receipts and link contracts are closely related. Both are machine-readable (e.g., JSON), both give permission to share data, both are digitally signed by both parties, and both are legally enforceable. A link contract is essentially a superset of a consent receipt, i.e., if you have a link contract, it also functions as a consent receipt.

In both cases, you can put a hash onto the Sovrin ledger as a way of proving that the consent receipt or link contract existed at a specific point in time. (Note that you still need to store the actual consent receipt or link contract so you can later prove that it generated the hash.)


#4

I see, I’m at last starting to grasp on this concept, and somehow I think it’s a bit hard to understand link contracts without the consent receipt in consideration.

So, the way I’m seeing it, a consent receipt might act as a public proof of a link contract having been “signed” by two or more parties. Am I right?.. My agent could securely share a given link contract with your agent, and in case both agree to follow the contract, a consent receipt would be stored on the ledger with no more info than a hash of the contract and our signatures. Does that make sense?


#5

Yes and no.

Yes, if you hashed a signed link contract and posted the hash to the Sovrin ledger, then that hash would serve the same function as a consent receipt. That’s what I was trying to say in my previous post.

But no, techically a consent receipt is its own data structure (at least as it’s being designed by Kantara), and that data structure it not identical to a link contract. It doesn’t have as much information in it.

I hope that helps clear it up. The two concepts are closely related but not identical.


#6

Yes, I get that they’re not identical concepts. And clearly a stored hash of a signed link contract would act as a consent receipt, but if that is the case. What other use cases might a consent receipt have? Any known scenarios where a consent receipt would serve any function by itself other than proving the existence of a given contract or being just a simple contract itself?

If a consent receipt could just be seen as a limited case for a link contract, why not just talk about link contracts whether simple or complex?


#7

Carlos, it’s a good point that if link contracts subsume the functionality of consent receipts, why bother with consent receipts?

The short answer is that the concepts arose in two different communities, with two different goals. Consent receipts were developed for privacy and regulatory compliance, with work focused at Kantara, while link contracts were developed for semantic data interchange requirements with work focused at the OASIS XDI Technical Committee.

My own feeling is that in the Sovrin ecosystem, all data sharing will be moderated by apps and agents forming link contracts, and thus that we can focus entirely on link contracts as you suggest. Does anyone else feel differently?