Evidence Exchange and Verifier Workflows
Evidence exchange and verifier workflows move evidence between producers, verifiers, relying parties, customers, operators, repositories, and audit workflows. Relying parties are the teams, services, customers, or workflows that make decisions based on verifier results. These workflows matter when evidence must be requested, transmitted, appraised, explained, or reused.
This option area is useful when the assurance decision depends not only on the artifact, but also on who receives it, how it is verified, what policy is applied, and what result is given to the relying party.
What this option area is for
Evidence exchange and verifier workflows may support:
- evidence requests and responses;
- attestation exchange and appraisal;
- SBOM, xBOM, vulnerability, or lifecycle evidence distribution;
- verifier policy and relying-party decisions;
- API, portal, repository, or automated evidence workflows.
They are commonly relevant to Product Acceptance, Secure Updates and Lifecycle Monitoring, Audit and Compliance Readiness, and Assurance Implementation Planning.
Where it fits
| Lifecycle stage | How it may help |
|---|---|
| Procurement and supplier assurance | Request evidence in a reviewable format and track responses |
| Acceptance | Move evidence from supplier or product team to the recipient that must decide acceptance |
| Deployment and operation | Support automated or periodic evidence checks |
| Update and vulnerability response | Exchange update, vulnerability, and current-state evidence |
| Audit and renewal | Provide repeatable workflows for evidence retrieval, appraisal, and explanation |
Options covered
Remote Attestation Procedures (RATS) evidence exchange
Remote Attestation Procedures (RATS) evidence exchange moves attestation evidence between attesters, verifiers, and relying parties. In this handbook, it is useful when evidence needs a repeatable exchange and appraisal path rather than ad hoc file sharing or manual interpretation.
RATS describes roles and relationships; it does not by itself define a complete product assurance system. Implementations need concrete attesters, evidence formats or token profiles, verifier policy, freshness handling, relying-party semantics, and records of failed or exceptional appraisals. Examples include the Veraison project, veraison/eat, veraison/ear, and embedded token libraries such as ctoken.
- Assurance role: Supports exchange of attestation evidence between attesters, verifiers, and relying parties.
- Evidence supported: Attestation evidence, appraisal results, freshness claims, and relying-party decision inputs.
- Lifecycle fit: Acceptance, deployment, runtime monitoring, service admission, update validation, and audit.
- Dependencies: Attester identity, verifier policy, reference values, appraisal logic, and relying-party interpretation.
- What it does not prove: Does not choose product-specific evidence sufficiency, reference values, or remediation actions.
- Mapping confidence: Direct for attestation exchange models; supporting for lifecycle assurance.
- Source/version note: Cite the specific IETF RATS architecture and Entity Attestation Token sources used.
Security Protocol and Data Model (SPDM)
Security Protocol and Data Model (SPDM) can support authenticated communication and measurement access between devices or components in applicable architectures. In this handbook, SPDM is relevant where evidence exchange depends on protocol-level authentication, measurement retrieval, and verifier interpretation.
SPDM evidence depends on the implemented protocol version, requester and responder roles, transport binding, endpoint credentials, measurement commands, and how verifier tooling consumes the results. Example implementations include DMTF libspdm and SPDM support inside device firmware, platform firmware, management controllers, or component validation tooling. "Supports SPDM" is a starting point for questions, not a sufficient assurance claim.
- Assurance role: Supports secure device or component communication, authentication, and measurement access in applicable platform architectures.
- Evidence supported: Protocol-level authentication evidence, measurement evidence, secure session properties, and verifier inputs.
- Lifecycle fit: Acceptance, deployment, platform communication, monitoring, update validation, and component assurance.
- Dependencies: Architecture support, endpoint identity, measurement source, verifier interpretation, and lifecycle-state handling.
- What it does not prove: Does not define full evidence retention, procurement policy, or lifecycle governance.
- Mapping confidence: Direct for SPDM protocol mechanisms; supporting for broader assurance workflows.
- Source/version note: Cite DMTF DSP0274 Security Protocol and Data Model (SPDM) Specification with the exact version used.
Software Bill of Materials (SBOM) / xBOM distribution
CRA Art. 13 §§ 3, 6
NIS2 Art. 21 § 2(d)
Software Bill of Materials (SBOM) and broader xBOM distribution workflows move transparency artifacts between suppliers, buyers, operators, customers, and auditors. In this handbook, distribution matters because a useful artifact must reach the right relying party with scope, version, freshness, and interpretation intact.
SBOM and xBOM distribution can use different formats, portals, APIs, repositories, or customer assurance workflows. Examples include supplier portals, artifact repositories such as OCI registries, dependency-management platforms, vulnerability-management platforms, and customer trust centers. The concrete implementation matters because access controls, integrity protection, update cadence, product binding, and recipient interpretation determine whether the artifact is usable.
- Assurance role: Supports transfer and reuse of transparency artifacts between suppliers, buyers, operators, customers, and auditors.
- Evidence supported: SBOMs, xBOMs, vulnerability records, build provenance, and related artifact metadata.
- Lifecycle fit: Procurement, release, acceptance, update, vulnerability response, audit, and renewal.
- Dependencies: Format selection, product/version binding, access controls, repository or delivery channel, and recipient interpretation.
- What it does not prove: Does not prove current integrity or remediation without evidence binding and workflow integration.
- Mapping confidence: Supporting unless a specific protocol or repository mechanism is mapped directly.
- Source/version note: Cite the chosen format, transport or repository mechanism, version, and exchange workflow.
Verifier policies and application programming interfaces (APIs)
Verifier policies and application programming interfaces (APIs) define how evidence is requested, appraised, transformed into a result, and exposed to relying parties. In this handbook, they are useful when teams need consistent appraisal behavior and decision records across products, suppliers, or lifecycle events.
APIs and verifier policies are implementation contracts. Examples may include an attestation verifier API, SBOM ingestion API, vulnerability-status API, procurement evidence portal, or CI/CD policy gate. Reviewers should know the policy version, evidence inputs, result semantics, authentication model, error handling, and audit logging rather than treating a successful API response as self-explanatory.
- Assurance role: Define how evidence is requested, appraised, transformed into a result, and exposed to a relying party.
- Evidence supported: Appraisal policies, verifier results, evidence request records, relying-party decisions, and exception records.
- Lifecycle fit: Acceptance, deployment, update, monitoring, audit, and incident review.
- Dependencies: Policy ownership, source-of-truth evidence, trust anchors, access control, logging, and change management.
- What it does not prove: A successful verifier result does not prove broader compliance unless the policy scope and evidence inputs match the decision.
- Mapping confidence: Supporting unless a specific verifier protocol or API specification is mapped directly.
- Source/version note: Cite the policy source, API contract, verifier version, evidence input scope, and decision output semantics.
What these options can support
Evidence exchange and verifier workflows can support scalable evidence collection, automated appraisal, relying-party decisions, and consistent supplier or product review. They can also reduce ambiguous manual interpretation when verifier policy is visible and maintained.
What they do not solve alone
They do not decide what evidence is sufficient, who should trust whom, or what happens after a failed appraisal. They also do not make weak evidence strong; they only move, appraise, or present the evidence available.
What must exist around them
- evidence request and response process;
- trust anchors, identities, and access controls;
- verifier policy, reference values, and appraisal rules;
- repository or retention workflow where evidence must be reused;
- exception, escalation, and risk-acceptance handling;
- logging and review of verifier decisions.
Evidence they may produce, protect, exchange, or verify
- attestation evidence and verifier results;
- SBOM, xBOM, vulnerability, or lifecycle artifacts;
- evidence requests and response records;
- relying-party decision records;
- API, portal, or exchange logs;
- exception and appraisal records.
Verification considerations
Verification should check who produced the evidence, whether the exchange path preserved integrity and context, what verifier policy was applied, whether the recipient can interpret the result, and whether exceptions are retained for audit.
Tooling categories
- evidence request portals;
- attestation verifiers and brokers;
- SBOM and vulnerability exchange services;
- verifier policy engines;
- API gateways and access control;
- relying-party decision services;
- audit logging and evidence export.
Questions to ask suppliers
- How is evidence requested, transmitted, appraised, and returned?
- Who operates the verifier, and what policy does it apply?
- What evidence inputs are required for a successful result?
- How are failed, missing, stale, or conflicting evidence responses handled?
Questions to ask implementers
- Which APIs, portals, verifier services, repositories, or logs support the workflow?
- How are verifier policy versions, appraisal results, and relying-party decisions represented?
- How are verifier results retained and linked to the relevant product or lifecycle decision?