Verifiable Presentation Personas: Certifiers, Consolidators, & Submitters

Verifiable Presentations (VPs) are an under-defined part of the Verifiable Credential (VC) ecosystem. This is a problem because presentations are a critical part of making a viable, working, useful credential ecosystem. Imagine graduating from a university and not being able to receive your degree in the mail. Or being asked for a copy of your driver’s license and not being able to provide it. A credential is valuable because it can be sent (i.e., “presented”) from one party to another. Leaving verifiable presentations under-defined is a huge risk for the continued success of VCs.

The Problem With Presentations

Despite being mentioned 118 times in the W3C VC spec, VPs are generally under-explained in the specification. In particular, we have little information about differences between VPs. For example, take a look at this diagram in the specification:

VPs seem somewhat ambiguous in this picture. For example, the holder “Acquires, stores, [and] presents” VCs, but how do they acquire the VCs in the first place? According to this diagram, it looks like they are “issued credentials,” but is issuance the same thing as a VP? The arrow for “Issue Credentials” is exactly the same as “Send Presentation,” leading us to believe these activities are similar, but how are they similar? We can’t adequately answer these questions by looking at the above picture and the specification doesn’t provide a ton of help either.

We can come up with more complicated arrangements of issuers, holders, and verifiers too, which complicates our mental model of VPs. For example, is there a holder that only presents to other holders? Are there verifiers that present to other verifiers? These questions are probably outside the scope of the W3C specification but are nonetheless important for understanding (and building) VC ecosystems.

Presentation Personas

The goal of this piece is to fill these gaps in our comprehension of VPs. To that end, I’ve constructed three VP personas that zoom in on different motivations for creating presentations: Certifiers, Consolidators, and Submitters.

Certifiers: As a certifier, I’m an issuer and want to be able to issue a VC about a holder and send it to them or another party.

• Certifiers care about enabling VC features like expiration dates and revocation.
• Certifiers are often “roots of trust.” The value of a VC is derived from the credibility of the certifier.
• Includes any organization that is making claims about entities.
• E.g., GS-1, organic certifiers

Consolidators: As a consolidator, I’m a holder and want to be able to receive/send VCs about another holder.

• Consolidators care about where VPs are coming from and where they’re going to.
• Consolidators care about the status of the VCs they’re receiving and sending (e.g., revocation status & expiration date).
• Includes any organization that is collecting claims about entities.
• E.g., Subsidiaries/sub-organizations, brokers

Submitters: As a submitter, I’m a holder and want to be able to present VCs about myself or another holder to a verifier.

• Submitters are similar to consolidators in that they’re both holders, but submitters are specifically responsible for VPs to verifiers.
• The VC subject(s) can be about the submitter, but not necessarily so.
• Submitters care about the status of the VCs they’re submitting (e.g., revocation status & expiration date)
• Includes any organization that is asserting claims about entities.
• E.g., Certified organic farms, university graduates, brokers

Caveats

There are a few caveats about these personas worth mentioning. First, this breakdown is not exhaustive. As the VC and VP ecosystem grows and changes I fully expect to find new interactions and scenarios that demand individual attention. In fact, there is an edge case that I’ve purposefully left out: self-certifiers. This persona both issues a VC about themselves and sends it directly to a verifier, but the credibility of self-certified claims is suspect, so my working hypothesis is that this persona will not be super critical for many use-cases.

Second, while I am differentiating between VP personas, I am not arguing that the underlying technology differs (or should differ) between each type of VP. A kitchen knife can be used to chop an onion or open a box. The kitchen knife is still a kitchen knife. While there may be room to argue that we should use different kinds of knives for cutting onions and opening boxes, that line of reasoning is outside the scope of this piece. I’m working under the assumption that there is one kind of VP, as defined in the W3C spec, that is being used for different purposes.

Third, these personas are not mutually exclusive. For example, a single party can be a certifier and a consolidator, or a consolidator and a submitter, but my working hypothesis is that these roles are often played one at a time.

Key Takeaways

Now that I’ve talked about Certifiers, Consolidators, and Submitters, you’re probably wondering how this breakdown helps us.

From a product development perspective these personas represent different types of users with different needs and pain-points. For example, a Submitter might need different tools to do their job than a Consolidator or a Certifier. Building a one-size-fits-all VC platform risks accommodating everyone and no one. While the technology underpinning these activities might be the same, their purpose is not. That’s a critical distinction that should inform how we build amazing and easy-to-use VC products.

Alternatively, this persona breakdown makes us reflect on how we use the language of “Verifiable Presentations.” A VP made by a Submitter is done for different reasons than a VP made by a Certifier, just as chopping an onion has a different aim than opening a box, even though I’ve used a kitchen knife to do both. In other words, the term “presentation” risks falling into the fallacy of equivocation. “Presentation” is said in a different sense depending on which persona we’re talking about. We should strive to eliminate this equivocation when we can. The personas I’ve outlined above should help us achieve that goal.

VPs are a complex and important yet under-developed part of our VC ecosystem. We should strive to continuously improve the specificity of our mental models of VPs as VCs evolve and grow as a standard. It’s imperative that we do so if we want VC technology to flourish.

Written by Adam Lerner, Technical Product Manager Transmute