Table of Contents

Class MdocVerificationContext

Namespace
Tessio.Verifier.Core.Mdoc
Assembly
Tessio.Verifier.Core.Mdoc.dll

Per-verification context for mdoc presentations. Richer than the frozen VerificationContext because the mdoc device signature covers the OpenID4VP session transcript, which is built from more than a nonce.

public sealed record MdocVerificationContext : IEquatable<MdocVerificationContext>
Inheritance
MdocVerificationContext
Implements
Inherited Members

Properties

ClientId

The client_id of the request this presentation answers, including any client identifier prefix. First element of the session transcript's handover info.

public string? ClientId { get; init; }

Property Value

string

EncryptionKeyThumbprint

RFC 7638 SHA-256 thumbprint of the verifier's response-encryption JWK, when the response was encrypted; null for unencrypted responses. Third element of the handover info.

public byte[]? EncryptionKeyThumbprint { get; init; }

Property Value

byte[]

ExpectedDocType

Expected document type from the DCQL query (e.g. org.iso.18013.5.1.mDL). When null, the docType check is skipped.

public string? ExpectedDocType { get; init; }

Property Value

string

Nonce

The nonce of the request. Second element of the handover info.

public string? Nonce { get; init; }

Property Value

string

ResponseUri

The response_uri of the request. Fourth element of the handover info.

public string? ResponseUri { get; init; }

Property Value

string

SessionTranscript

An externally built session transcript. When set, device authentication is verified over exactly these bytes and none of the fields above are used to build one. Set it for presentations whose transcript this type cannot describe, such as ISO/IEC 18013-7 Annex C over the Digital Credentials API (SessionTranscript).

public byte[]? SessionTranscript { get; init; }

Property Value

byte[]

ZkRequest

The zero knowledge request the presentation answers, or null. When it is set, a zero knowledge presentation must name one of the circuits it offered. Any other is refused before its proof is checked, even one the proof verifier accepts. Pass the same ZkRequest the request was built with. Null leaves the choice of circuit to AcceptsCircuit(string) alone.

public ZkRequest? ZkRequest { get; init; }

Property Value

ZkRequest

Remarks

Only the offered circuits are enforced. Required is not: a plain mdoc answer to a request that required a proof is verified as a plain presentation, as the age verification profile wants (Annex A, A.9). A presentation is matched by the circuit its identifier names, not by its spelling, so a bare hash or another casing of an offered circuit is accepted. The zero knowledge package's LongfellowProofVerifier takes the circuit's parameters from Longfellow's own specification for that hash, so with it the spelling carries nothing a proof depends on. A verifier that reads ZkSystemId itself should read CircuitHash instead.