Link secrets play an important role in enabling more trusted interactions with verifiable credentials. They give verifiers the ability to know that a credential was truly issued to the individual presenting it, and they enable individual holders to combine different credentials into powerful compound proofs.

In this post, I’ll break down what link secrets are, how they work, and why we at Evernym have opted to use link secrets instead of simpler DID-based models to provide a greater degree of privacy and security for binding a credential to its holder.

## What is a link secret?

A link secret is a large random number, wrapped in a way that allows the holder to prove that they know the secret.

This wrapping is known as making a **cryptographic commitment** to the secret. A cryptographic commitment gives the assurance that the secret was known at the time the commitment was made, and that the secret hasn’t changed.

Making a cryptographic commitment is like enclosing the secret in an envelope: The ‘envelope’ can be shared without revealing the secret inside.

The mathematics involved in making cryptographic commitments allow a holder to * blind* the commitment. Blinding commitments allows for different versions of the same commitment to be shared without correlation. This allows for different, blinded versions of the holder’s link secret to be embedded in every credential they receive. Multiple issuers who have given credentials to the same holder would not be able to use the blinded link secret to correlate the holder.

In unblinded form, the link secret is not shared with issuers, verifiers, or other identity owners. It is not possible for a malicious party to use multiple different blinded link secret values to derive the link secret, but it is possible for the holder to prove to a verifier that the same link secret was included in each credential.

## Why do we use Link Secrets?

The link secret has two purposes:

#### 1. Proof of holder binding

Because the holder of a credential knows the unblinded link secret and nobody else does, the link secret is a convenient way to prove that a credential is bound to the holder and hasn’t been copied or cloned from another holder’s wallet.

This enables verifiers to **ensure that the individual presenting a credential is the same individual that the credential was originally issued to**.

#### 2. Proof of credential linking

Because the link secret is the same across all credentials belonging to the holder, they can combine data from several credentials into a single proof. Even though each one contains a different blinded value, the holder can show that the secret behind those blinded values is the same, without revealing the secret. This shows that all the source credentials are linked to the same person without providing a correlatable identifier.

If an individual has a bank statement credential with their account balance and an employment credential, they can combine both into a powerful **compound proof** to immediately show creditworthiness—**without leaving behind any breadcrumbs between the two credentials**.

Along with selective disclosure and signature blinding, **private holder binding** is a key feature for protecting users’ privacy with zero-knowledge proof (ZKP) verifiable credentials. Holder binding is the process of showing that a credential was issued to a particular holder. Private holder binding allows for a holder to prove the credential was issued to them without revealing anything else.

**Credential linking** allows a holder to share data from different credentials (even from different issuers) in a single proof transaction, and prove that all the credentials were issued to that holder.

The link secret achieves both of these goals without degrading privacy. Other SSI approaches take a simpler approach: they embed a DID in each credential, and expect that DID (which may be common across credentials) to be revealed with each usage. While this works at a basic level, and it relies on similar security as link secrets, it makes correlation trivial—a horrible privacy outcome.

**Using a DID for the holder or subject of a credential is a bit like giving every verifier the same super-cookie that they can use to track everything you do.**

### Are Link Secrets safe?

Link secrets are just as safe as private keys. One worry about link secrets is that if a link secret is compromised, the credentials of the identity owner are compromised as well. But it turns out that this is not the case at all. The reason lies in some unique characteristics of verifiable credentials issued with zkp-capable signatures.

One mitigation for link secret compromise is to prove relatedness with something other than or in addition to a link secret. Take, for example, these two scenarios:

If a holder shares a driver’s license credential and their link secret with someone who turns out to be a bad actor, then it would be all too easy for that bad actor to impersonate them. The normal proof request would be: “Prove your name with your license” — and either the holder or the bad actor could do that.

If, instead, the proof request is, “Prove your age with your license, and prove that the name on your license is the same as the name on four other credentials in your wallet” — the bad actor is defeated, without the holder having to reveal their name.

Additionally, it’s worth comparing how a link secret compromise compares to a DID-based linking model that faces a key compromise as well. In both methods for holder binding, the security relies on the holder keeping a secret value safe. With a DID, this is the DID’s private key. In both cases, if a link secret or a private key is compromised a holder can be impersonated. In both cases, as well, there’s a way to stop a malicious actor once a compromise has been discovered. However, **only the link secret method allows for a holder to reduce correlation of data if they choose**. This is why we have opted to use link secrets to prove credentials were issued to the same entity rather than using DIDs.

### How do Link Secrets work?

A link secret is a blinded cryptographic commitment to a secret value known only to the holder. It is included in the issuer’s signature on a credential in such a way that the holder can prove knowledge of their secret without revealing it. The fact that it is a commitment means that the issuer never sees it, and being a blinded commitment means that each issuer sees a different value even though the underlying secret is the same.

A detailed introduction to cryptographic commitments may be found Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing, you may also hear commitments of this type referred to as Pedersen Commitments. A cryptographic commitment allows the holder to commit to a particular value, then reveal that they committed to the value at some later time.

One example is that I could claim to be able to predict the final score of a sporting event, then make a commitment to a predicted final score and give it to you for safekeeping. After the end of the game, I could prove that I had correctly predicted the final score mathematically, but only if I actually did. I couldn’t change my prediction after the game or the proof wouldn’t work.

Blinded commitments are cryptographic commitments that have had an additional random factor included so that the commitment can be shared with multiple parties without correlating them.

A Signature Scheme with Efficient Protocols is the original description of CL Signatures (a zkp-capable signature and the basis for what Indy calls AnonCreds). Section 6.1 of that paper gives a protocol for signing a committed value. This is what a link secret is. The blinded link secret commitment is passed to the issuer, who signs it as part of the set of messages that make up the credential. Section 6.2 describes the protocol for proving knowledge of the signature on a committed value, such as the signature made over a link secret, and section 6.3 describes using the signature scheme for signing blocks of messages, which is the way they are used in AnonCreds. CL Signatures are based on the same mathematics used for RSA.

Other zkp-capable signature schemes also support including blinded commitments from the holder into the issuers signature, in much the same way that CL Signatures do. Camenisch and Lysyanskaya explored using elliptic curves and bilinear maps for such a signature scheme in Signature Schemes and Anonymous Credentials from Bilinear Maps. This scheme is very similar to Short Group Signatures, which describes the original BBS signature. BBS+ was first described in Constant-Size Dynamic k-TAA then optimized somewhat in Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited. All of these signature schemes support link secrets.

### Conclusion

Link secrets provide a way to privately bind a holder to a verifiable credential that is just as secure as using a DID, but without the drawback of adding a correlating identifier.

Functionally, using a link secret for holder binding relies on the same guarantees as using a DID: in both cases the holder must keep something secret. A link secret also provides a mechanism for showing that multiple credentials were issued to the same holder. Link secrets are based on well-established and well-understood mathematics and have been incorporated into a number of zkp-capable signature schemes.