Class MdocVerificationContext
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
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
Nonce
The nonce of the request. Second element of the handover info.
public string? Nonce { get; init; }
Property Value
ResponseUri
The response_uri of the request. Fourth element of the handover info.
public string? ResponseUri { get; init; }
Property Value
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
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.