Trust and Policy

Trust policy converts cryptographic evidence into a contextual decision. A valid signature confirms integrity under a key; policy determines whether that issuer, key, credential, disclosure, holder relationship, and transaction are acceptable for the stated purpose.

Policy layers

A complete policy model can include:

Layer	Example responsibility
Participant policy	Which issuers, wallets, verifiers, or relying parties are recognized
Credential policy	Which credential types, schemas, profiles, and claim meanings are accepted
Cryptographic policy	Allowed formats, algorithms, key types, verification relationships, and deprecations
Lifecycle policy	Validity, status, suspension, revocation, replacement, and dependency behavior
Presentation policy	Required claims, alternatives, minimisation, audience, nonce, and holder binding
Assurance policy	Required proofing, evidence source, review level, and transaction risk
Jurisdiction policy	Purpose, legal basis, biometric conditions, retention, transfer, and individual rights
Business policy	Eligibility, access, safety, fraud, sanctions, clinical, or sector-specific rules
Operational policy	Timeout, retry, review, outage, monitoring, evidence, and incident behavior

These layers should be independently versioned where their owners and change cycles differ.

Trust is scoped

An issuer should be trusted only for the claims and contexts it is authorized to support. Trust can be constrained by:

• credential type;
• subject population;
• jurisdiction;
• sector or professional domain;
• assurance level;
• validity period;
• algorithm and key profile;
• verifier or relying-party purpose;
• membership in an independently governed framework.

A trusted issuer of employee affiliation is not automatically trusted to issue civil identity, academic degrees, medical licenses, or financial eligibility.

Trust sources

Policy may rely on governed sources such as:

• explicit institutional allow-lists;
• trust registries or federation metadata;
• contractual partner relationships;
• certification or accreditation evidence;
• domain and DID governance;
• approved public-key infrastructure;
• sector or government registers;
• manually approved exception records.

The existence of a public identifier or key is not sufficient by itself. Provenance and authorization must be established.

Credential and schema policy

Policy should pin the accepted credential definition and claim semantics. It should reject ambiguous or silently changed schemas even when the structure remains technically parseable.

A credential profile should define:

• issuer and subject models;
• required and optional claims;
• value formats and vocabularies;
• disclosure rules;
• holder-binding model;
• status mechanism;
• validity and renewal behavior;
• evidence and assurance category;
• version compatibility.

Schema validation confirms structure, not truth or authorization.

Algorithm and key policy

Cryptographic policy should allow only reviewed combinations of:

• credential format;
• signature or proof algorithm;
• key type and size;
• verification relationship;
• key status and lifecycle;
• certificate, DID, or registry validation path;
• holder proof and key binding;
• response encryption where required.

Unexpected, deprecated, weak, or unsupported combinations should fail safely. Algorithm agility should be governed rather than achieved by accepting every advertised option.

Status and freshness policy

A credential can be authentic but unacceptable because it is expired, suspended, revoked, superseded, or presented outside its intended context.

Policy should define:

• whether status checking is mandatory;
• acceptable cache age and dependency behavior;
• how expiry and clock tolerance are handled;
• whether superseded credentials remain usable for historical evidence;
• which results route to review;
• how a status outage affects high- and low-risk transactions.

A verifier should never silently skip a required status check and still claim full verification.

Assurance and risk

The same credential may be sufficient for one transaction and insufficient for another. Policy can combine:

• issuer authority;
• proofing or evidence assurance;
• holder binding;
• device and session assurance;
• credential age;
• transaction value or impact;
• contextual risk indicators;
• required human review.

Assurance labels should be supported by explicit controls and evidence, not marketing language alone.

Policy outcomes

A policy engine should return an explainable category rather than only a Boolean value. A result may include:

• satisfied;
• insufficient evidence;
• untrusted issuer or profile;
• lifecycle failure;
• context or holder-binding failure;
• unsupported algorithm or format;
• dependency unavailable;
• review required;
• policy configuration error.

The result should identify the policy version and reason category without exposing sensitive fraud logic or internal implementation details.

Policy governance lifecycle

Policy should pass through:

1. proposal and ownership;
2. architecture, security, privacy, legal, or business review as applicable;
3. test-vector and negative-case definition;
4. controlled approval;
5. staged activation;
6. production observation;
7. periodic review;
8. migration or retirement.

Every material policy change should identify affected credentials, partners, holders, historical decisions, metadata, tests, and rollback conditions.

Testing policy

Policy testing should include:

• approved and unapproved issuers;
• boundary dates and status changes;
• rotated and retired keys;
• malformed and excessive disclosures;
• missing holder proof;
• replayed or wrong-audience presentations;
• unsupported algorithms and versions;
• trust-registry outage;
• review and exception paths;
• migration from the prior policy version.

Public documentation boundary

This page describes trust-policy architecture. Production trust registries, customer acceptance rules, fraud indicators, algorithm allow-lists, policy source code, thresholds, exception records, and emergency overrides remain controlled.

See Verification and Policy, Public Metadata and Discovery, and Content and Capability Status.