Add Support in Veraison to fetch endorsements from Veraison's EDS.

[shefali-kamal]

Problem Statement

Veraison's Endorsement Distribution Service can be owned and run by a party A(can be a TEE vendor) and Remote Verifier can be owned and run by CSP/Enterprise. In such scenarios veraison's verifier will not have a copy of endorser's database. This feature should be provided in Veraison.
Points to note:

• The set of endorsements with an endorser could be very huge so it may not be practical for the verifier to have all of it in its data store.
• The set of endorsements to be managed by the verification service might also be very dynamic in nature, coming from different sources (for example different devices being connected to a composite attester).

Proposed solutions from community meeting on 24/02/2026
Solution A: An agent in Veraison organization(separate from Veraison services repository) that can query the EDS to get the endorsements, parse them and push CORIMs to provisioning service in Veraison. These endorsements are available at runtime during evidence verification.

Pre-Req:

• The agent should know the details of endorsements it needs to pull(example ImplementationID and InstanceID in case of ARM CCA)
• Provisioning Service in Veraison also needs to be up and running.
• Mechanism on how make sure Database of Veraison has latest endorsements(and refresh them) lies with agent.

Solution B: Veraison can be configured for EDS query/response support . For that an EDS Client is provided, which when configured can check the endorsements in corim-store(during attestation). If it is a miss then client can connect to EDS and cache the values, returns endorsements to VTS to be used for attestation. The core idea is to wrap the CoRIM store around an active component -- either a new VTS thread or a separate service -- which exposes the needed API surface for the existing VTS verification and provisioning workflows to query the store (both read and write). In the verification workflow, the "store manager" can be configured with one or more EDS clients that implement the client-side CoSERV API (ideally), or some other proprietary API in case the EDS is not CoSERV capable. These clients fetch data from upstream EDS services if the requested endorsement, ref-value, or trust anchor is not in the local store(corim-store). Selecting a specific EDS client may depend on the attestation scheme: e.g., queries for the CCA platform scheme could be routed to the platform vendor's EDS, trusted device queries would go to the device vendor, queries for the CCA workload would be routed somewhere else.

Preferred Solution:
Solution B is preferred in my opinion due to following reasons:

• Solution B is configuration based. Hence whoever deploys veraison services can make the choice.
• It provides caching as well as runtime gathering of endorsement functionality for verification service.
• Provisioning service needs not to be configured, up and running in this scenario.
• Solution B although needs to be in Veraison services it is not very complex to implement