Verifiable Credentials, Claims, and Proofs
Verifiable Credentials, Claims, and Proofs
- Know what a principal, delegate, verifier, and DID are.
- distinguish claims, credentials, presentations, and verification results
- map issuer, holder, and verifier roles to Mandaitor proof flows
- explain why proof material is useful before and after an action
A verifiable credential is a structured way to express claims made by an issuer. The W3C Verifiable Credentials Data Model describes an extensible model for credentials, a three-party ecosystem of issuers, holders, and verifiers, and mechanisms for making credentials tamper-evident and machine-verifiable.1 Mandaitor uses the same mental model to explain Proof-of-Mandate: a system should be able to present evidence that an authority boundary existed and that a concrete action was verified against it.
The most important beginner lesson is that a credential is not simply a token. It is a statement made by someone, about something, for a purpose, with proof material and verification rules. In Mandaitor, the statement is about delegated authority: a delegate may perform a defined action for a principal under defined constraints.
A verifiable credential can prove that a credential or presentation is authentic and current, but the verifier still decides whether the claims satisfy its business rules.1 Mandaitor follows the same logic: Proof-of-Mandate can make authority evidence inspectable, while a relying system still applies its own acceptance policy.
The roles: issuer, holder, verifier
The W3C model is useful because it separates three roles that are often confused. The issuer makes a claim. The holder presents it. The verifier checks it. A single organization may operate multiple roles, but the conceptual separation helps learners reason about trust.
| VC concept | General meaning | Mandaitor interpretation |
|---|---|---|
| Issuer | Entity that makes claims in a credential. | Mandaitor or an authorized issuer that produces mandate-related proof material. |
| Holder | Entity that can present the credential. | Agent, service, workflow, or client presenting proof of delegated authority. |
| Verifier | Entity that checks the credential and applies policy. | API, tool gateway, dashboard, counterparty, or reviewer evaluating Proof-of-Mandate. |
| Claim | Statement about a subject. | Statement that a delegate may perform an action under constraints. |
| Presentation | Shared credential or selected credential data. | Proof-of-Mandate or evidence shown to a relying system. |
| Status | Information about validity, suspension, or revocation. | Mandate lifecycle state and proof freshness checks. |
Claims are the atomic unit of trust
A claim is a statement that can be evaluated. In ordinary life, “Alice is licensed to drive” is a claim. In Mandaitor, “Agent A may create invoices for Customer B up to EUR 5,000 until Friday” is a claim about delegated authority. The claim only becomes useful when the verifier can identify who made it, who it concerns, whether it is still valid, and what constraints apply.
| Claim element | Example | Why it matters |
|---|---|---|
| Subject | Agent A, service account, workflow instance. | Identifies who or what the claim is about. |
| Issuer | Mandaitor tenant, delegated authority service, organization. | Determines who is responsible for the claim. |
| Predicate | May create invoice, may read project file, may approve validation. | Defines the permitted action. |
| Object | Customer B, project folder, validation record. | Defines the resource or target. |
| Constraints | Amount cap, expiry, jurisdiction, approval requirement. | Prevents broad or ambiguous delegation. |
| Proof | Signature, integrity protection, reference to verification result. | Makes tampering detectable and supports later review. |
Proof-of-Mandate as credential-style evidence
Mandaitor's Proof-of-Mandate should be understood as an evidence artifact, not as a magical permission slip. It ties a verification decision to a mandate, a delegate, an action, a time, and the rules that were evaluated. That makes it useful for APIs that need to trust an agent action, for dashboards that need to show posture, and for reviewers who need to reconstruct why something happened.
This sequence is important because it separates issuing evidence from accepting action. Mandaitor can produce evidence that a verification decision occurred. A relying verifier can still reject the action if the proof is stale, the mandate is revoked, the resource is outside local policy, or the business context has changed.
Credential lifecycle and mandate lifecycle
The W3C VC model includes concepts such as validity period, credential status, evidence, terms of use, and securing mechanisms.1 Mandaitor maps those ideas to mandate lifecycle management. A mandate may be active, expired, revoked, suspended, or superseded. A Proof-of-Mandate should therefore be evaluated in relation to lifecycle state rather than treated as permanently valid.
| Lifecycle question | Credential-world concept | Mandaitor-world concept |
|---|---|---|
| Who issued this evidence? | Issuer identity and proof verification. | Mandaitor tenant, issuer key, or authority service. |
| Is it still current? | Validity period and credential status. | Mandate expiry, revocation, suspension, and proof freshness. |
| Does it describe this action? | Claims and credential subject. | Scope, resource, action, context, and constraints. |
| Can it be checked independently? | Cryptographic securing mechanism. | Proof material, verification endpoint, audit reference, or evidence pack. |
| Should this verifier accept it? | Verifier business rules. | Relying-party policy, risk tolerance, and local compliance requirements. |
Selective disclosure and least authority
The W3C VC ecosystem pays significant attention to privacy and data minimization.1 The same design pressure appears in Mandaitor. A relying system often does not need to know everything about a principal, delegate, or mandate. It needs enough information to decide whether a proposed action is authorized.
This leads to a practical principle: show the minimum authority evidence necessary for the decision. A payment tool may need to know that an agent may initiate a payment below a threshold, but it may not need broad details about unrelated mandates. A reviewer may need richer context later through an evidence pack, but the runtime verifier should receive the smallest useful proof.
Common misunderstandings
| Misunderstanding | Better interpretation |
|---|---|
| A verifiable credential proves that a real-world statement is true. | It proves that an issuer made a claim in a tamper-evident form; the verifier still evaluates trust and business rules.1 |
| Proof-of-Mandate replaces authorization policy. | It supplies verifiable evidence that policy can evaluate and reviewers can inspect. |
| A proof should be accepted forever. | Proofs must be checked for freshness, status, lifecycle, and relying-party rules. |
| A broad credential is easier. | Broad authority increases risk. Mandaitor should prefer narrow, bounded, context-aware mandates. |
What to read next
Continue with Trust Chains and Credential Verification to understand why a verifier must evaluate issuers, keys, status, and policy before trusting proof. Then read Mandate Policies to understand how scope and constraints turn credential-style evidence into an enforcement decision.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.