RelyingPartyTrust
Deprecated
Configure RelyingPartyValidator with the anchors of the access certificate providers, which establish trust for the client identifier prefixes x509_hash and x509_san_dns; trust for other prefixes is not established
A single source of trust in the relying party sending an authorization request, for one client identifier scheme, see OpenID4VP, Client Identifier Prefixes.
Callers pass a set of these, which in union represents the wallet's trust in relying parties: A request is accepted when any source applicable to its client identifier scheme establishes trust. Several sources of the same kind are fine, e.g. a trust list plus a locally pinned certificate.
Passing null instead of a set means trust is not evaluated at all, i.e. every relying party is trusted. The signature of a signed request is still verified, with the key the request asserts itself (the leaf of x5c, a jwk, or a did:key), so a signed request without one is rejected. Passing an empty set, or a set with no source for the scheme a request uses, rejects that request: Configuring this at all means trust has to be established, and there is no way to do that without trust material. This includes entity_id (OpenID Federation) and did, for which a Custom source is the only way to establish trust, as this library implements neither federation trust chains nor DID resolution — without one, a relying party could bypass the configured trust anchors just by naming itself with a scheme we do not evaluate.
Only redirect_uri is not covered, as it forbids signed requests anyway, and neither is a request carrying no client_id at all, which the DC API authenticates through the platform-provided calling origin instead.
Inheritors
Types
Trust anchors for the certificate chain transported in the x5c header of requests using the x509_san_dns or x509_hash client identifier scheme.
Consulted for client identifier schemes this library does not evaluate natively, i.e. entity_id (OpenID Federation), did, and anything unrecognised. Verify the signature of a signed request with the key the scheme establishes, e.g. from the DID document, and establish trust in the relying party; throw to reject the request, stating why.
Keys of relying parties known to this wallet in advance, looked up by their client identifier, for the pre-registered client identifier scheme. Return null for an unknown client identifier.
Certificates of the parties trusted to issue verifier attestations, for the verifier_attestation client identifier scheme. Applies when the attestation transports its signer in an x5c header.
Keys of the parties trusted to issue verifier attestations, for the verifier_attestation client identifier scheme. Applies when the attestation asserts no certificate.