Proof Purpose

Also called proofPurpose, verification relationship

ComposedSpecified

A proof purpose is a field inside a Data Integrity signature that states why the signature was made, not just who made it, but which specific authorized capacity they were acting in when they made it. It's the answer to a question a plain digital signature can't answer on its own: a signature over some bytes proves those bytes weren't tampered with and came from a specific key, but it says nothing about whether that key was even allowed to sign this kind of statement in the first place.

The vocabulary comes directly from a DID Document's verification relationships: the different named roles a key listed in a DID Document can be authorized for:

  • assertionMethod: this key is allowed to assert claims (issue credentials).
  • authentication: this key is allowed to authenticate as this DID (log in, prove control).
  • keyAgreement: this key is allowed to establish an encrypted channel.
  • capabilityInvocation: this key is allowed to invoke a granted authorization.
  • capabilityDelegation: this key is allowed to delegate an authorization to someone else.

A Data Integrity proof's proofPurpose field names exactly one of these, matched against the corresponding entry in the signer's DID Document. A verifier checks two separate things: is the signature valid and was the signing key actually authorized, in the issuer's own published DID Document, for the specific purpose this proof claims. A stolen authentication key that gets used to try to issue credentials (a purpose it was never authorized for) fails this check even if the raw signature itself is mathematically perfect.

Where it comes from

The five-value vocabulary above is defined by the W3C DID Core specification, with Manu Sporny and Amy Guy among its primary editors (see the DID entry). The Data Integrity / Linked Data Proofs lineage (the same W3C working group, Sporny and Dave Longley among its editors, see Data Integrity Proof) reuses that exact vocabulary as the proofPurpose field on a signature. Solidus designed neither the vocabulary nor its reuse as a proof field.

Solidus status

Documented in Solidus's own type definitions; absent from what actually ships live, the same finding the Data Integrity Proof entry already made, worth restating for this specific field. Solidus's published CredentialProof type (@solidus-network/types) hard-codes proofPurpose to the single literal value 'assertionMethod', narrower than the full five-value DID Core vocabulary, since Solidus credentials are only ever issued, never authenticated-as or capability-delegated with this particular field. But checked live, 2026-07-17: the actual running issuer's OID4VCI metadata contains no Data-Integrity-style proof object and no proofPurpose field anywhere: its live format is JOSE/SD-JWT, a family that has no direct equivalent to this concept. (It does list an unrelated proof_types_supported block for OID4VCI proof-of-possession, a different concept with no bearing on proofPurpose.)

Proof you can run yourself: npm view @solidus-network/types and read the CredentialProof interface directly, proofPurpose is typed as exactly one literal value. Compare against curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer, no such field appears in the live response.

Where it comes from

Someone else specified this. Solidus assembles it.

The vocabulary itself, assertionMethod, authentication, keyAgreement, capabilityInvocation, capabilityDelegation, is defined by the W3C DID Core specification (Manu Sporny and Amy Guy among its primary editors, see the DID entry) as the set of ways a DID Document's keys are authorized to be used. The Data Integrity / Linked Data Proofs spec (same W3C VC Working Group lineage, Sporny and Dave Longley among its editors) reuses that exact vocabulary as the proofPurpose field on a signature, so a signed proof states not just who signed something but under what authorized capacity. Solidus authored neither.

How to check this

Written down. No implementation yet.

npm view @solidus-network/types, then read the CredentialProof interface directly, proofPurpose is typed as the single literal 'assertionMethod', never anything broader. Compare against curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer (checked 2026-07-17), whose response contains no Data-Integrity-style `proof` object or `proofPurpose` field anywhere: it does list an unrelated OID4VCI `proof_types_supported` block for proof-of-possession, which has no bearing on Data Integrity's proofPurpose.

Related

Proof Purpose · Solidus Lexicon