---
title: "Wallet2 Integration"
description: "Link the Trust Registry to Wallet2 so signed OpenID4VP Request Objects can authenticate against relying-party identities."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/services/trust-registry-service/wallet2-integration
generated: 2026-10-01
---
# 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](https://docs.walt.id/enterprise-stack/services/trust-registry-service/verifier-integration.md).

## 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](https://docs.walt.id/enterprise-stack/services/trust-registry-service/setup.md) and [Trust Source Management](https://docs.walt.id/enterprise-stack/services/trust-registry-service/trust-source-management.md).
2. A Wallet2 Service in the same tenant.

## Link Trust Registry to Wallet2

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

**Option: CURL**

Endpoint: `/v2/{target}/wallet-service-api/dependencies/add`

**Example Request**

```bash
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"
}'
```

**Path Parameters**

- `orgID`: _String_ — Your organization's Base URL prefix.
- `wallet2Target`: _String_ — The Wallet2 service path, e.g. `myorg.tenant1.wallet1`.

**Header Parameters**

- `Authorization`: _String_ — Bearer token for authentication. Format: `Bearer {yourToken}`.

**Body Parameters**

- `dependency`: _String_ — The full path to the Trust Registry service, e.g. `myorg.tenant1.trust-registry`.

**Response Codes**

- `201` — Dependency added successfully.

## 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.

**Note:**

If the union is empty, `x509TrustAnchors` is omitted and `x509_hash` / `x509_san_dns` fail closed. Linking a Trust Registry that only contains issuer (`PID_PROVIDER`) identities does not enable signed Request Object authentication.

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](https://docs.walt.id/enterprise-stack/services/wallet2-service/setup.md).
- Register unsigned `pre-registered` verifiers with `preRegisteredClients` and `redirect_uris` on the same Wallet2 configuration.