Trust Chains and Credential Verification
Trust Chains and Credential Verification
- Understand DIDs and verifiable credentials at a conceptual level.
- describe how a verifier decides whether evidence should be trusted
- identify issuer trust, cryptographic integrity, status, scope, and freshness checks
- connect trust-chain reasoning to Mandaitor authorization decisions
A trust chain is the reasoning path a verifier follows before accepting a proof. It is not enough for a credential-like artifact to exist. The verifier must ask who issued it, which identity material signed or secured it, whether the issuer is trusted, whether the proof is still current, whether it has been revoked or superseded, and whether the claims satisfy local policy.
The W3C Verifiable Credentials model distinguishes issuers, holders, and verifiers, and it emphasizes that verifiers evaluate credentials according to their own business rules after checking authenticity and status.1 DID Core explains how decentralized identifiers can be associated with DID documents that contain verification methods and services.2 Mandaitor combines these ideas in a practical way: Proof-of-Mandate must be checked as part of a chain of identity, issuer, status, scope, and policy decisions.
The trust-chain mental model
| Check | Plain-language question | Mandaitor interpretation |
|---|---|---|
| Integrity | Has the proof been tampered with? | Validate proof material, signature, hash, or verifier response. |
| Issuer trust | Do we trust the authority that issued this evidence? | Accept Mandaitor tenant, configured issuer, or verified authority service. |
| Identity binding | Does this proof belong to the right subject? | Bind principal, delegate, agent identity, and mandate identifier. |
| Status | Is the proof still usable? | Check expiry, revocation, suspension, or replacement. |
| Scope | Does it cover this action and resource? | Evaluate action, resource, constraints, and lifecycle. |
| Local policy | Should this relying party accept it? | Apply business rules, risk class, data category, and escalation requirements. |
Cryptographic validity is not business acceptance
A beginner may assume that “valid proof” means “the action must be accepted.” That is not correct. A proof can be technically valid but still not satisfy a relying system's policy. For example, an agent may present an authentic proof that it can create purchase orders, but the relying system may reject it because the supplier is blocked, the value exceeds a local limit, or the proof is not accepted for that jurisdiction.
| Scenario | Technical proof result | Business result |
|---|---|---|
| Signature valid, mandate expired. | Integrity may pass. | Reject because status is not current. |
| Issuer trusted, resource mismatch. | Issuer check passes. | Reject because action is outside scope. |
| Proof current, local policy stricter. | Proof and status pass. | Reject or escalate based on local requirements. |
| Proof valid, risk high. | Verification may allow under baseline policy. | Require human approval or stronger evidence. |
Failure points should teach the user
Verification failures should not be mysterious. They should tell users whether the problem is identity, issuer trust, lifecycle status, scope, missing context, or local policy. Clear reason codes help developers debug, help users request the right mandate, and help reviewers understand repeated gaps.
| Failure category | User-facing explanation | Better next step |
|---|---|---|
| Identity mismatch | The actor presenting proof is not the expected delegate. | Check agent registration and request identity binding. |
| Untrusted issuer | The relying system does not accept this issuer. | Configure trust anchors or use an accepted authority. |
| Expired or revoked | The mandate or proof is no longer valid. | Create, renew, or reactivate the mandate. |
| Out of scope | The action or resource is not covered. | Narrow the action or request a new mandate. |
| Missing context | The verifier cannot evaluate a required constraint. | Provide amount, resource, purpose, jurisdiction, or approval data. |
| Local denial | The proof is valid but business policy rejects it. | Escalate or change the relying-party policy if appropriate. |
Trust anchors and policy configuration
A trust anchor is a configured starting point for trust. In Mandaitor, a relying system might trust a specific Mandaitor tenant, issuer key, organization, identity method, or verification endpoint. Trust anchors should be managed carefully because they determine which external proofs can influence action.
| Trust configuration | Example | Risk if too broad |
|---|---|---|
| Trusted issuer | Accept proofs from one Mandaitor tenant. | Over-acceptance if tenant boundaries are unclear. |
| Trusted key or verification method | Accept proofs secured by specific material. | Breakage or overtrust if rotation is not handled. |
| Accepted mandate types | Accept only finance or project mandates. | Incorrect rejection if taxonomy is incomplete. |
| Accepted proof age | Require recent verification for sensitive actions. | Stale proof may be used if freshness is ignored. |
| Escalation threshold | Require human approval above a defined risk. | High-impact actions may proceed automatically. |
Practice check: diagnose a broken trust chain
Trust-chain failure analysis
A verifier receives a technically valid proof, but the issuing organization is not on the verifier's accepted trust list and the mandate has expired. The product must explain the outcome to an operator without implying that the cryptography failed.
Broken trust chains are teaching moments. The verifier should help users understand whether they face a cryptographic, governance, freshness, or policy problem.
- Separate validity from acceptanceWrite one sentence explaining which part of the proof is cryptographically valid and which part fails business acceptance.
- Name the failing linksIdentify whether the trust anchor, issuer acceptance, mandate status, expiry, or policy context blocks the action.
- Design the user-facing messageDraft a concise verifier message that helps the operator decide whether to update trust configuration, request a new mandate, or deny the action.
- Diagnostic clarity
- The answer identifies more than one possible failure link and avoids a generic invalid label.
- Operational guidance
- The answer tells the operator what can be fixed and what must remain denied.
- Trust precision
- The answer distinguishes cryptographic verification from policy acceptance.
Why can a proof be cryptographically valid but still rejected by a verifier?
- Because cryptographic validity only proves that signatures and data integrity checks passed; the verifier may still reject the issuer, expiry, status, or policy context.
- Because valid signatures are never useful for business workflows.
- Because trust anchors are only needed when the proof is malformed.
Reveal answer
Verification has both technical and governance layers. A valid signature can prove integrity, while verifier policy still decides whether the issuer, trust anchor, mandate status, and context are acceptable for the business action.
What to read next
Read Mandate Policies and Policy Enforcement to learn how scope and constraints become decisions. Then read Evidence Packs and Audit Events to understand how successful and failed verification checks become reviewable evidence.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.