Attestation patterns

by ANIL JOHN

A design pattern should only be applied when the flexibility it affords is actually needed. ~ Erich Gamma

The W3C Verifiable Credentials Data Model provides a great deal of flexibility when it comes to making verified attestations. Some thoughts on a couple of common attestation patterns …

It is fascinating to hear how folks in the global ecosystem are seeking to apply verified attestations to a wide array of problem sets in a manner that is secure, privacy respecting and, if done well, interoperable.

W3C VC Ecosystem Model

I am even happier that the conversation is no longer about blockchain and distributed ledger technologies, but about the abstraction layer that the W3C Verifiable Credential Data Model and W3C Decentralized Identifiers can put on any type of resilient registry, whether that is implemented using a blockchain, a DLT platform, or some other type of distributed data store.

In the conversations that I’ve been part of, folks seem to self-select themselves into two broad “attestation pattern” camps.

Digital identity attestation pattern

The first is, unsurprisingly, a digital identity attestation pattern that goes something like this:

Digital identity attestation pattern

In the flow above, a digital wallet holder goes to one of more issuers of credentials in order to obtain attestations that prove some fact about them or provide some manner of entitlement to them which can then be presented to a verifier (relying party) during some manner of transaction.

Supply chain attestation pattern

The other type of flow tends to more prevalent in an asset tracking scenario such as transport, trade and supply chains and goes something like this:

Supply chain attestation pattern

The flow above is a multi-hop scenario in which a digital wallet holds one or more attestations from a particular issuer which is then presented to the next entity in the hop. Each entity in the hop verifies the prior attestations (the verification aspect is not represented in the picture above) and adds their own attestation to the mix until the collection of attestations is presented to a verifier at the end.

More alike than different

When looking at the pictures above, it is easy to assume that both flows are very different and they need to be addressed in a very distinct way. I would also make a point that there are a lot of incumbents in both camps who would benefit from pursuing this fractured view.

However, the diagrams while seeming to be different are more alike than different. The nuances that differ between the two flows often come down to:

  • The holder and the subject in the digital identity flow is often a person
  • The holder and the subject in the supply chain flow is often an organization
  • The supply chain flow often has clear requirements around the sequence of issuers in the flow e.g. the producer of a good attests to something before the entity that is transporting the good to its final destination does their attestation (BTW, the need for specific sequencing may be true in the digital identity flow as well)

I am hand-waving more than a bit over some of the nuances here that make these flows possible, such as using the same wallet to store multiple credentials from different issuers, aggregating and presenting multiple credentials to a single verifier, as well as the use of consent based selective disclosure under the control of the holder of the wallet in what is released to and seen by the verifier. See my earlier posts on “Whose wallet is it anyway?” and “Illusion of interoperability” for more details.

The key points to note here is that the items that matter when it comes to technical interoperability of the solutions in either flow are very much the same, and that anyone whose statement is a variation on “We are special and unique because we do X” should not be taken at face value.

What I will also point to is that the digital wallet plays a central role in all cases and as such we should be spending a lot more attention on its security, privacy, interoperability as well as its UI and UX. In short, an opportunity. Are you ready?


cyberforge: random and relevant

  • Citizenship Vocabulary - describes a Linked Data vocabulary for asserting Verifiable Credentials related to residency and citizenship information, such as given name, family name, country of citizenship, birthday, and other attributes used to determine the citizenship status of a citizen. Now a W3C CCG Work Item.

  • Secure Data Store - describes a privacy-respecting mechanism for storing, indexing, and retrieving encrypted data at a storage provider. It is often useful when an individual or organization wants to protect data in a way that the storage provider cannot view, analyze, aggregate, or resell the data. This approach also ensures that application data is portable and protected from storage provider data breaches.

  • Universal Wallet Interoperability Spec - describes a portable, extensible, JSON-LD wallet, supporting digital currencies and credentials


 Tweet  Share  Email


Get the best cybersecurity research, resources and insights to help secure and safeguard the digital world.
No Charge. No Spam. Unsubscribe Anytime.