Class StaticTrustListResolver
- Namespace
- Tessio.Verifier.Trust
- Assembly
- Tessio.Verifier.Trust.dll
Trust resolver backed by a fixed set of trusted issuer identifiers, plus optional trust-anchor certificates for issuers that present an X.509 chain. Suitable for development, tests and small deployments. Load the identifier set from a JSON file or URL with TrustListLoader.
public sealed class StaticTrustListResolver : ITrustListResolver
- Inheritance
-
StaticTrustListResolver
- Implements
- Inherited Members
Remarks
The trust mechanism depends on how the key was resolved. A key resolved from issuer metadata is
trusted exactly when its issuer identifier is on the configured list, proven by control of the
issuer's HTTPS origin. A key resolved from an x5c (or x5chain) header is trusted when
its chain anchors on one of trustAnchors (or the leaf itself is a pinned anchor); the
identifier is not required to be on the list, because anyone can put any name in a
certificate, so the X.509 chain is the proof. This is the only mechanism ISO mdoc has, where the
issuer identifier is a Document Signer subject DN that no list enumerates. Binding the certificate
to a claimed issuer, where that applies, is the caller's concern: SD-JWT VC ties iss to a
certificate SAN before this point, but ONLY where the leaf asserts a name. A leaf that asserts none
cannot contradict iss, and the specification makes its subject the issuer, so for that leaf
anchoring is the whole of the proof. Without configured anchors, x5c credentials are rejected.
Either way the certificate must be inside its own validity window, read at clock. Anchoring
is not the whole answer: a pinned certificate whose window has closed is refused, exactly as the
chain check refuses an expired one on the path that builds a chain.
What a trusted issuer is trusted FOR. This resolver answers one question, "is this signer
trusted", and callers ask it about more than credential issuance: a Token Status List token's
signer is judged here too. So adding an entry to trustedIssuers or to trustAnchors
authorises that party for every purpose the deployment asks about, including signing revocation
status for credentials issued by somebody else. That is the cost of a flat list, and it is worth
knowing before adding an entry to clear a rejection.
This is the open-source end of the trust seam. Production EU trust (LOTL, national lists, WRPAC) is a separate concern behind the same ITrustListResolver interface.
Constructors
StaticTrustListResolver(IEnumerable<string>, string, IEnumerable<X509Certificate2>?, TimeProvider?)
Creates a resolver trusting exactly the given issuer identifiers.
public StaticTrustListResolver(IEnumerable<string> trustedIssuers, string source = "static", IEnumerable<X509Certificate2>? trustAnchors = null, TimeProvider? clock = null)
Parameters
trustedIssuersIEnumerable<string>Issuer identifiers (iss values or certificate subjects).
sourcestringOptional label reported as TrustListSource.
trustAnchorsIEnumerable<X509Certificate2>Root or pinned certificates that x5c chains must anchor on. Credentials presenting an x5c chain are rejected when this is empty, and an anchor is only usable inside its own validity window.
clockTimeProviderTime source for every certificate validity decision here, on both the pinned-leaf and the chain-building path; system clock when null. Pass the same one given to the verifier, or a presentation verified at a chosen instant is judged against wall-clock time instead, and the two disagree for exactly the certificates whose window has since closed.
Methods
ResolveAsync(string, ReadOnlyMemory<byte>[], CancellationToken)
public Task<IssuerTrustStatus> ResolveAsync(string issuer, ReadOnlyMemory<byte>[] x5c, CancellationToken ct = default)
Parameters
issuerstringIssuer identifier from the credential (e.g., an HTTPS URI for JWT VC Issuer Metadata).
x5cReadOnlyMemory<byte>[]Optional X.509 chain from the credential header (DER-encoded, leaf first).
ctCancellationTokenCancellation token.