See also: How do I ensure credibility in the credentials I award?
In conversations about Verifiable Credentials (VCs), you'll encounter terms like "verification", "validation", "authenticity", and similar related concepts. Although the VC community emphasizes nuanced technical differences between those terms, it's important to keep in mind the core concept behind VCs. That is, Verifiable Credentials exist to model only one idea: Some entity is claiming something about a subject.
That is, a VC is just a digitally-signed record of some entity (the issuer) making one or more claims about a subject.
Notice that this model does NOT tell you anything about the quality of the information in the credential. Nor does it tell you if the information is accurate or truthful. It only tells you that the issuer that signed the credential has made those claims. It simply reveals whether the credential has been tampered with, and conforms to the specification of the credential type. With that main model in mind, the following is a list of things you can investigate when receiving and processing a credential.
Authenticity: Who made the claims in the credential?
By definition, every Verifiable Credential must identify its issuer -- that is, the entity that has made the claims. The issuer is identified by an identifier in the verification method (usually, by cryptographic keys or Decentralized Identifiers in the digital signature). In the literal sense, checking who made the claims is easy and automatic: first, look in the issuer field for the issuer's identifier, and second, automatically (with the help of well-known algorithms) check that the credential was signed (or otherwise sealed) by that identifier. However, just knowing the issuer's identifier, by itself, is not sufficient.
Issuer Identity: Who does the issuer's identifier belong to?
While determining the issuer's identifier is trivial, knowing who that identifier belongs to (what natural or legal entity claims control of that identifier) is a lot harder, at least from a logistical or organizational perspective. Essentially, you need one or more lists from a trusted source, directories of entities that map identifiers to legal or at least recognizable names known to the provider of each list.
Where do these directories come from, who will host them, how will they interoperate, and what governance rules will they follow? The answers to these questions are still evolving in the credentials space, but will very likely depend on the subject matter or "vertical" of a given credential. A considerable amount of government, business, and nonprofit infrastructure exists that currently play these roles in society, from ministries and government departments, to global standards organizations, to professional associations, and consumer consortiums. Approaches to bringing these capabilities to the digital credentials ecosystem may involve a combination of strategies: specific lists of issuers known to specific verifiers by direct arrangements, the implementation of common protocols for expressing and consuming this type of trust information, and the development of new services specific to answering these questions for verifiers. As these pieces come together, collaborations between issuers and verifiers
Signature Verification: Is the signature valid, and has the credential been tampered with?
In the context of Verifiable Credential, the term "verification" typically means "the process of determining whether the digital signature or seal on this credential is intact and valid". This process is automatic, performed by trusted code libraries or web services. And while this is a critical operation, and serves as the heart of all Verifiable Credentials, it is very limited in scope. It can only do two things:
- Check that a specific identifier has signed and sealed the credential. (But not who the identifier belongs to, see the previous section for more discussion.)
- Ensure that the credential has not been modified since it was signed or sealed.
Everything else about the credential (such as who controls the issuer's identifier, or whether the credential is acceptable according to the verifier's business rules), is the domain of trust frameworks, policy decisions, and risk assessments.
Acceptance: Is the overall credential acceptable, according to the verifier's business rules and policies?
As the phrasing of the question implies, this is only answerable by each individual verifier or relying party, and solely depends on their use cases and policies. For example, while a credential code library can easily check whether the expiration date on a given credential has passed, it is up to the verifier to decide whether an expired credential is still acceptable. Similarly, while it's easy enough to automatically check if it's been revoked by the issuer, it is up to the verifier's risk profile to determine whether a revoked credential is acceptable. Consider, for example, existing use cases where a complex credential like a drivers license can be revoked by the issuing body (for traffic violations), but is still acceptable for some uses such as age verification. Acceptance of the credential issuer's claim is separate from the authentication of the issuer's identity; the acceptance of a skill claim may vary depending on whether it is issued by a peer or a prestigious institution.
In the context of processing Verifiable Credentials for purposes of verification and acceptance, implementers will need to keep several things in mind. A helpful way of thinking about the process is to divide it into VC verification (the mechanical components of credential processing) and acceptance (where you apply the business logic of your particular domain to interpret the meaning of the credential in the verifier's context or environment).
Verification steps (handled by a typical VC library or service)
1. Is it a well-formed VC (according to the VC Data Model spec), are all the required fields present, etc.
2. Does the VC validate against the specified schema or verification rules of the credential type specification? See type-specific credential processing.
3. Verify the signature. This involves:
- Resolving the issuer's identifier (it needs to be resolvable through a mechanism available to the verifier) and identifying authorized signing keys
- Identify which key signed the message
- Cryptographic signature verification (indicates the credential has not been tampered with) according to the algorithm defined by the securing mechanism used by the issuer.
When building an application to perform these verification steps above, the main decision an implementer needs to make is "which securing mechanisms, such as cryptographic suites or key types, and which DID methods, should our application support?" This is partly a technical decision (for example, "we'll use Ed25519 keys to start with, as they're well supported and performant"), partly a legal requirement or policy decision (for example, "NIST government guidelines require us to support the EC-256 key types"), and largely a question of which approaches relevant issuers will be using in credentials the verifier is likely to encounter.
Acceptance steps (app-specific business logic and policy decisions)
In addition to the automated verification steps above, typical VC verifier libraries will also perform several policy-specific checks. If required by policy, check:
- The validUntil field to see if this credential has expired. (Don't forget about time zones and distributed systems clock skew.)
- The validFrom field to see if the credential was "future-dated".
- If the credential has been revoked. Some revocation methods support several different reasons for revocation (permanent vs temporary), so that needs to be taken into account as well.
Lastly, your app logic will need to perform any remaining checks necessary for acceptance of this particular claim from this particular issuer. For example, if using one or more registries of known issuers, you will need to check the issuer's identifier (often a DID) to see if it is registered with a trusted authority and determine whether to accept the VC based on the issuer's reputation or other considerations.
When all programmatic verification and acceptance checks complete, applications may present results for human-mediated decisions, like whether to bring a candidate in for an interview. Or in some cases they may be programmed to automatically respond by changing some records, such as recording a license requirement as met or a skill as mastered.
Embedded (client-side) verification vs using a verifier web service
Another implementation decision is -- should you use an embedded standalone VC verification library, or call out to a verifier web service (such as one implementing a standard VC-API endpoint for verification)?
This will mostly depend on your platform constraints.
Embedded Verification Library:
- Benefits include: self-contained, no need to authenticate with an external verification API (this matters, for example, when creating an in-browser Single Page Application).
- Drawbacks indluce: if you decide to support a different set of cryptographic suites, key types, or DID methods, you'll need to add that code and re-deploy the app. Also, some DID methods may require heavy-weight server side resolvers.
Verifier Web Service:
- Benefits may include the usual benefits of microservice architecture, such as: the verifier service can evolve independently (and receive security updates) from the rest of your application.
- Drawbacks include: these services are typically gated behind API authorization, and some applications (called "public clients" in authorization parlance) may have difficulty keeping track of corresponding secrets and API keys. If the service is maintained by a third party, you may become dependent on their decisions about the priority of supporting the approaches used in certain credentials that you are presented with.
