DOCS: Clarification Needed on Graph Database Support and Interface Expectations

[jeevan0920]

Hello Veraison Team,

While studying the [Veraison project documentation](https://github.com/veraison/docs/blob/main/project-overview.md), we came across the following statement:

"It has been determined that the most appropriate form of storage to support queries by the validator is a database that supports graph structures & queries."

This has caused some confusion, and we would appreciate clarification on a few points:

1. Is a Graph Database Required?
   Does Veraison require a graph database to support validator queries in production environments, or is this mentioned as a potential optimization for specific use cases?

2. Compatibility with IKVStore Interface
   Veraison currently defines a key-value store interface (IKVStore) that supports basic operations like Init, Setup, Get, Set, GetKeys, Add, and Del.
   Can graph databases be supported via this interface, or would they require a new interface or architectural changes?

3. Expectations for Graph Queries
   What kind of graph queries does the validator rely on (e.g., relationship traversal, pattern matching)? Are there any specific data structures or relationships that make graph databases advantageous in this context?

4. Current or Planned Implementations
   Are there any existing implementations or planned efforts to integrate a graph database backend with Veraison? If so, are there recommended tools or approaches?

We are trying to better understand the intent and requirements behind this part of the documentation, and how database backends are expected to behave or evolve in the Veraison ecosystem.

Thank you for your time and support!

[setrofim]

I believe that part is out of date. services do not rely on a graph database, and (I think) we do not currently use graph databases anywhere in the Veraison project.

1. No. Our current model (as you point out in (2)) for endorsement/trust anchor storage is a simple key-value store. This can be implemented using pretty much any database system. We currently have support for SQL-based DBMS's (sqlite, MySQL/MariaDB, and PostgresSQL).
2. Supporting graph relations at store level would require a richer interface than IKVStore. We don't have any plans to implement anything like that in the near future.
3. Current implementation of the verifier does not rely on any graph queries. It generates a key from the evidence claims and does a simple lookup in the key-value store.
4. IIRC, we experimented with graph-based data models during early prototyping (years ago), but eventually settled on the simple key-value store instead, as that is all that is really needed for the verifier. (note: unrelated to the verifier, we have been looking at richer query interface for the purposes of endorsement distribution, but that is still in early stages, and also doesn't require graph databases).

In short, we do not require graph support at database level right now, and have no plans to require it in the foreseeable future. Sorry about the confusion. I'll update the docs to remove that statement.

[jeevan0920]

Thanks again for the helpful clarification on the absence of graph database use and the reliance on a key-value store for endorsement storage.

While reviewing the the endorsement distribution based design we had a follow-up question regarding the offline verification use case.

The diagram shows the rust-ccatoken standalone verifier depending on a local cache store of reference values and trust anchors, populated via the Endorsement API Client Library. From your previous message, we understand that richer query interfaces are being explored for endorsement distribution — but are still early and do not require graph databases.

Given that context, we’d appreciate clarification on a few points:

What is the expected format or structure of this local cache store?
Is it intended to be a persistent KV store (e.g., backed by a file or embedded DB), an in-memory structure, or left up to implementers?

What semantics or guarantees are expected from this cache?
For example, should it support freshness guarantees, expiration, versioning, or trust anchor rotation?

Are there currently any interfaces or tooling in Veraison to populate this cache from the Veraison Endorsement DB?
Or is this currently assumed to be an implementation-specific concern?

Is the Endorsement Distribution API intended to be the primary mechanism to sync this cache?
And if so, is there a recommended schema or example for consumers to follow?

We’re trying to understand the architectural expectations for offline verification flows and how tightly they’re coupled to any future enhancements in endorsement distribution.

Thanks again!

[setrofim]

Please note that answers below are specific to the rust-ccatoken library and is orthogonal to services/ other parts of Veraison.

What is the expected format or structure of this local cache store?
Is it intended to be a persistent KV store (e.g., backed by a file or embedded DB), an in-memory structure, or left up to implementers?

The cache store interface is defined by IRefValStore and ITrustAnchorStore traits. The library provides a simple in-memory implementation of each of these. These are rather basic, and, I believe, the expectation is that applications provide their own implementations of these traits.

What semantics or guarantees are expected from this cache?
For example, should it support freshness guarantees, expiration, versioning, or trust anchor rotation?

The provided in-memory caches have none of these. It is up to the application's implementations to implement these if needed.

Are there currently any interfaces or tooling in Veraison to populate this cache from the Veraison Endorsement DB?
Or is this currently assumed to be an implementation-specific concern?

The in-memory caches can be populated from JSON files. See testdata/rv.json and testdata/ta.json for examples of what the files should look like. Please see the memo stores test code for how they can be loaded. There are currently no API for populating them (I imagine this is left to Endorsement API client library).

Is the Endorsement Distribution API intended to be the primary mechanism to sync this cache?
And if so, is there a recommended schema or example for consumers to follow?

Unlike the services, which provide a full flow, rust-ccatoken is a stand-alone library. There is no "intended" flow as such -- that is left for the application do define. I do not believe we have an example for Endorsement Distribution API at the moment.

@thomas-fossati is the author of the library.

Thomas, please feel free to correct/expand on my answers.

[jeevan0920]

Thanks for the clear answers. closing the issue.