miSWIYUverifier

A C#/.NET 10 ASP.NET Core web app (Minimal API with a browser UI) that verifies the Swiss E-ID (swiyu Public Beta) Beta-ID credential via the swiyu-verifier management REST API (OpenID4VP / DCQL) — the Swiss sibling of miEUDIverifier.

The web page shows a QR code. The user scans it with the swiyu Sandbox Wallet (iOS/Android), confirms the data sharing of their Beta-ID, and the page displays the verified identity data: given name, family name, date of birth, over-18, sex, nationality, place of birth and portrait photo.

Status: tested end-to-end on 27 October 2026 — scan, consent, presentation and display of the verified data including the portrait, against the swiyu Sandbox Wallet (iOS) with swiyu-verifier 5.0.1 (Trust Protocol 2.0 only), using both Beta-ID generations: one from the old did:tdw BCS issuer and one issued the same day from the new did:webvh issuer. Previous full passes: 10 September 2026 (verifier 4.2.0, iOS Sandbox Wallet 1.18.0) and 3 July 2026.

The swiyu sandbox moves fast and breaks verifiers without warning; if this stops working, What broke and when lists every incompatibility hit so far, and how each was diagnosed.

⚠️ You need the swiyu Sandbox Wallet, not the regular swiyu app

On 4 September 2026 the Public Beta was renamed Sandbox, and the regular swiyu Wallet became production-only (announcement). This project runs against the sandbox infrastructure (*.trust-infra.swiyu-int.admin.ch), so the normal swiyu app can no longer be used with it — it finds no matching credential and answers access_denied.

• iOS: swiyu Sandbox Wallet — direct link only, it is not searchable in the App Store (iOS 17+)
• Android: APK from the wallet releases — not on Google Play

The Sandbox Wallet starts empty: issue a fresh Beta-ID inside it (step 1). Nothing changes on the verifier side — the sandbox URLs, DIDs and the issuer stay the same.

Try it (live demo)

A public test instance is available at https://miswiyuverifier.mitterbucher.com/ — open it, scan the QR code with your swiyu Sandbox Wallet and confirm.

No guarantee of availability — this endpoint may be offline at any time. To run your own instance, see the Quick start below.

• You need the swiyu Sandbox Wallet (see the note above — not the regular swiyu app) with a Beta-ID (free, self-issued — see step 1 below).
• Every visitor gets their own verification session (own QR code); any number of verifications can run in parallel. "New request" starts a fresh verification anytime.
• Note: the Beta-ID contains made-up pseudo data only (not an official document).

Flow (Cross-Device)

                                    ┌─ host machine ───────────────────────────────┐
   swiyu app ──HTTPS:443──► router  │ Caddy (TLS, /oid4vp/* only)                  │
   (smartphone)                     │   └─► swiyu-verifier :8083 ◄── PostgreSQL    │
        ▲                           │         ▲ management API (local only!)       │
        │ scans QR                  │         │                                    │
   Browser ◄──────:5070──────────── │ miSWIYUverifier (ASP.NET)                    │
                                    └──────────────────────────────────────────────┘

• The ASP.NET frontend (src/miSWIYUverifier) creates a verification via the management API of the swiyu-verifier (DCQL query on the Beta-ID) and renders the returned verification_deeplink as a QR code.
• The swiyu app fetches the signed request object from the publicly reachable HTTPS EXTERNAL_URL and posts the presentation back to it. TLS is terminated by Caddy, which forwards only /oid4vp/* to the container — the management API stays unreachable from outside.
• The frontend polls GET /management/api/verifications/{id} until state = SUCCESS and displays the data from wallet_response.credential_subject_data.
• All cryptographic validation (SD-JWT, signatures, holder binding, revocation) is done by the swiyu-verifier service — the core library stays slim.

This is the beginning of the README. Read the rest at the original. Read the full README ↗