#Wallet2 Integration

Link the Trust Registry to a Wallet2 Service to authenticate signed OpenID4VP Request Objects (x509_hash / x509_san_dns) against relying-party certificates from loaded trust lists. Static PEM pins remain available as break-glass anchors and are unioned with registry-derived certificates.

This is verifier Request Object trust, not credential-issuer trust. Issuer list membership (PID_PROVIDER) is not mixed into JAR PKIX. For credential verification at presentation time, see Verifier Integration.

#Architecture

┌─────────────────────────────────────────────────────────────────┐
│                 Signed Request Object Auth                       │
│                                                                  │
│  Wallet2 present / resolve / preview / reject                    │
│                       │                                          │
│                       │ PEM pins ∪ RP registry certs             │
│                       ▼                                          │
│              InMemoryTrustStore (per request)                    │
│                       ▲                                          │
│                       │ RELYING_PARTY_PROVIDER identities        │
│              Trust Registry Service                              │
│                       │                                          │
│                   Loaded Trust Sources (TSL, LoTE)               │
└─────────────────────────────────────────────────────────────────┘

#Prerequisites

1. A Trust Registry Service with at least one trust source that lists relying parties (LoTE type EUWRPRCProvidersList, or another list whose entities map to RELYING_PARTY_PROVIDER / ACCESS_CERTIFICATE_PROVIDER). See Setup and Trust Source Management.
2. A Wallet2 Service in the same tenant.

#Link Trust Registry to Wallet2

Add the Trust Registry as a dependency of your Wallet2 service:

curl -X 'POST' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{wallet2Target}/wallet-service-api/dependencies/add' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{
  "dependency": "myorg.tenant1.trust-registry"
}'

#How JAR Trust Is Derived

On each present, resolve, preview, reject, and isolated-flow step, Wallet2 rebuilds ClientIdTrustConfiguration from:

1. configuration.requestObjectX509Trust.x509TrustAnchorsPem — optional PEM pins.
2. Certificate identities on the linked Trust Registry whose entity type is RELYING_PARTY_PROVIDER or ACCESS_CERTIFICATE_PROVIDER, whose service status is GRANTED / RECOGNIZED / ACCREDITED / SUPERVISED, and whose source assurance.accepted is true.

When CA certificates are present in that set, they are preferred as PKIX trust anchors. Otherwise the listed service certificates (often RP leaves in a LoTE) are used as anchors.

Wallet2 may only resolve and list through the dependency proxy. Load and refresh trust sources on the Trust Registry service itself.

#Related configuration

• Pin extra anchors with requestObjectX509Trust on Wallet2 — see Wallet2 Setup.
• Register unsigned pre-registered verifiers with preRegisteredClients and redirect_uris on the same Wallet2 configuration.