Class ParsedWalletResponse
- Namespace
- Tessio.Verifier.OpenId4Vp
- Assembly
- Tessio.Verifier.OpenId4Vp.dll
A fully parsed wallet authorization response: the presented credentials plus the response metadata the hosting layer needs for session correlation.
public sealed record ParsedWalletResponse : IEquatable<ParsedWalletResponse>- Inheritance
-
ParsedWalletResponse
- Implements
- Inherited Members
Remarks
ParseAsync(WalletResponseData, CancellationToken) (contracts-v0) returns only the credentials;
this richer shape is exposed on the concrete WalletResponseParser because the
state value travels inside the JWE for direct_post.jwt responses and would
otherwise be unreachable.
Properties
Credentials
The presented credentials extracted from vp_token.
public required IReadOnlyList<PresentedCredential> Credentials { get; init; }Property Value
Encrypted
Whether the response arrived encrypted, as a direct_post.jwt response parameter holding
a JWE, rather than as plain vp_token and state form fields. A response parameter
that is not a JWE is refused by the parser, so true here means it really was encrypted.
public bool Encrypted { get; init; }Property Value
Remarks
The parser accepts either shape, because only the session knows which one it asked for. The
built-in callback compares this with the response_mode its request asked for and refuses a
mismatch before completing. A host with its own callback should do the same, since a plaintext
presentation in answer to a request that asked for encryption does not answer that request. An error
response is the exception: OpenID4VP 1.0 section 8.3.1 lets a wallet that is unable to encrypt send it in
the clear, so the built-in callback makes no such comparison for one (see Error).
Error
The wallet's error code when it answered with an Authorization Error Response instead of a
presentation, for example because the holder declined; null for a presentation. When it is set,
Credentials is empty. Set only by a parser with
ReadErrorResponses on; any other parser throws for such a form.
public string? Error { get; init; }Property Value
Remarks
SPEC: OpenID4VP 1.0 section 8.5: "The error response follows the rules as defined in [RFC6749]". RFC 6749
section 4.1.2.1 limits the code to printable ASCII without " or \, which the parser
enforces. Only the code is kept: error_description and error_uri are text the sender chose.
Read in both forms. Section 5.6: "Both successful and error responses SHOULD be returned using the supplied
Response Mode", so under direct_post.jwt a wallet should seal it in response, and
Encrypted is then true. No section defines the payload of a sealed error, so the parser reads
the error and state members the cleartext form carries as fields. Section 8.3.1 lets a wallet
that is unable to encrypt send it in the clear instead.
It proves nothing about the holder: anyone holding the request's state can send one.
Init-only and optional, so every existing construction of this record still compiles and behaves as it did.
State
The OpenID4VP state echoed by the wallet, when present.
public string? State { get; init; }