Produkt · EU Digital Identity Wallet · Intermediär

CodeB Wallet Intermediary: die EU-Wallet für viele Relying Parties

Bieten Sie die EU Digital Identity Wallet Ihren Kunden als Dienst an: Praxen, Händler, Makler, Kommunen, Vereine. Jeder Kunde erscheint in der Wallet unter seinem eigenen Namen und mit eigenem Zweck – Sie betreiben eine Installation, ein Zugangszertifikat und ein Register.

In einem Satz: CodeB Wallet Intermediary macht Ihre Installation zum Intermediär nach ARF: Jede Wallet-Anfrage ist mit Ihrem Zugangszertifikat signiert und trägt das Registrierungszertifikat der Relying Party, für die Sie handeln – mit deren Namen, Zweck und Ihnen als Intermediär nach ETSI TS 119 475.

ARF 3.0 · ETSI TS 119 475 · CIR (EU) 2025/848 · OpenID4VP 1.0 · HAIP 1.0 · OpenID Connect

Geschlossene Beta, im Test. Nicht zertifiziert.

Kurz gefasst

Was
Ein Intermediär-Modul: Ihre Installation spricht im Auftrag Ihrer Kunden mit der EU Digital Identity Wallet.
Für wen
Vertrauensdiensteanbieter, Identitätsprüfer, Zahlungsdienstleister, öffentliche Dienstleister und IT-Dienstleister, die vielen kleineren Organisationen die Wallet anbieten wollen.
Zertifikate
Ein Zugangszertifikat für Sie als Intermediär; je Kunde ein Registrierungszertifikat mit intermediary und act.sub, mit Statusliste.
Register
Je Kunde ein Eintrag mit den Angaben nach Anhang I der Durchführungsverordnung (EU) 2025/848, einschließlich Nummern 14 und 15 (Intermediär); öffentlich abrufbar.
Integration beim Kunden
Normales OpenID Connect – Beispiele für Node.js, Python, PHP und ASP.NET Core.
Bezug
Als gehosteter Dienst von Aloaha oder als Modul Ihrer eigenen CodeB-Installation. Preise auf Anfrage.

So funktioniert es

Vier Schritte; die ersten beiden je Kunde nur einmal.

Intermediär betreiben

Ihre Installation hat ein Zugangszertifikat (als Intermediär) und einen Registrar-Signer für Registrierungszertifikate, beide aus der Zugangszertifikats-CA.

Jede Relying Party registrieren

Für jeden Kunden: ein Registereintrag mit offiziellem Namen, Kennung, Zweck, Datenschutzerklärung und Kontakt, markiert mit „nutzt diese Seite als Intermediär“ und verknüpft mit seinem Gateway-Client.

Die Relying Party integriert

Normales OpenID Connect mit acr_values=urn:codeb:acr:eudi-wallet. Auf ihrer Seite nichts Wallet-Spezifisches.

Die Wallet sieht beide

Jede Anfrage ist mit dem Zugangszertifikat des Intermediärs signiert und trägt das eigene Registrierungszertifikat des Kunden, das den Intermediär nennt. Die Person bestätigt; der Kunde erhält ein signiertes id_token.

Was das Modul leistet

Zwei Zertifikate je Anfrage

Ihr Zugangszertifikat authentisiert den Intermediär; das Registrierungszertifikat des Kunden nennt Empfänger, Zweck und Intermediär – genau die Angaben, die eine Wallet für „wer fragt, in wessen Auftrag“ braucht.

Register je Relying Party

Offizieller Name, Kennung, Land, Zweck, Datenschutzerklärung, Kontakt, Aufsichtsbehörde und Intermediär. Änderungen werden protokolliert; der Eintrag ist öffentlich abrufbar, die Client-Kennung nicht.

Sperren in Sekunden

Sperren oder Löschen einer Registrierung beendet neue Anmeldungen für diesen Kunden sofort und markiert seine Registrierungszertifikate in der Statusliste.

Nur, was angefragt ist

Das Registrierungszertifikat listet genau die Nachweise und Angaben der jeweiligen Anfrage; die Wallet legt per selektiver Offenlegung nur diese offen.

Wallet-Protokolle inklusive

OpenID4VP 1.0 mit DCQL, HAIP 1.0, SD-JWT VC und ISO mdoc, Vertrauenslisten und Widerruf – dieselbe Technik wie das CodeB Relying Party Gateway.

Kunden ohne Registrierung

Gateway-Clients ohne Intermediär-Registrierung melden sich weiter mit Ihrer Installation als Relying Party an – Sie stellen Kunden schrittweise um.

Wer Intermediär wird

Vertrauensdiensteanbieter

Wallet-Annahme für Ihre Signatur- und Siegelkunden, gebündelt mit Ihren bestehenden Diensten.

Identitätsprüfer

Die PID aus der Wallet als Alternative zu Video- und Dokumentenprüfung, für viele Mandanten aus einer Installation.

Öffentliche Dienstleister

Ein Zugang zur Wallet für Gemeinden und Behörden, jede mit eigenem Namen und Zweck in der Wallet.

IT-Dienstleister für KMU

Praxen, Kanzleien, Händler und Vereine erhalten die Wallet-Anmeldung, ohne selbst Zertifikate und Protokolle zu betreiben.

Sicherheit, Datenschutz, Grenzen

Ausgelegt auf ARF 3.0

Folgt dem ARF 3.0, ETSI TS 119 475, OpenID4VP 1.0 und HAIP 1.0. Nicht zertifiziert.

Keine Profile, keine Tracker

Vorgelegte Angaben gehen an die Relying Party und werden nur für die Anmeldung vorgehalten; keine Drittanbieter-Analytik.

Vertrauensbereich

Zertifikate stammen heute aus der CodeB-Zugangszertifikats-CA und ihrem Register – nicht aus einem nationalen Register. Wallets akzeptieren sie, wo sie dieser CA vertrauen.

Rechte der Betroffenen

Kontakt, Datenschutzerklärung und Aufsichtsbehörde der Relying Party stehen im Registrierungszertifikat; Löschanträge über den ARF-Endpunkt.

Für Entwickler

Register, Zertifikat und Kundenintegration in vier Ausschnitten.

Eine Relying Party registrieren

Einmal pro Kunde: Registereintrag mit „nutzt diese Seite als Intermediär“ und dem Gateway-Client, über den er sich anmeldet.

shell
# Register a relying party that uses your site as intermediary (admin API of the
# access-certificate CA; the same form is on the admin page "Access-certificate CA").
curl -s https://YOUR-SITE/wrpac-ca.ashx?rp \
  -H "Authorization: Bearer ADMIN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "example-shop",
    "official_name": "Example Shop Ltd",
    "trade_name": "Example Shop",
    "org_id": "VATMT-00000000",
    "country": "MT",
    "url": "https://shop.example",
    "email": "privacy@shop.example",
    "privacy_policy": "https://shop.example/privacy",
    "intended_use": "Age check at checkout",
    "uses_intermediary": true,
    "oidc_client_id": "example-shop-web"
  }'

Was die Wallet erhält

Das Registrierungszertifikat der Relying Party nennt den Intermediär; die Anfrage selbst ist mit dem Zugangszertifikat des Intermediärs signiert.

json
// Payload of the registration certificate the wallet receives (typ rc-wrp+jwt,
// signed by the registrar signer; values illustrative, abridged).
{
  "sub": "VATMT-00000000",            // the relying party - not the intermediary
  "name": "Example Shop",
  "sub_ln": "Example Shop Ltd",
  "country": "MT",
  "intermediary": { "sub": "VATMT-99999999", "sname": "CodeB" },   // ETSI TS 119 475 Table 10
  "act": { "sub": "VATMT-99999999" },                               // GEN-5.2.4-09
  "credentials": [ { "format": "dc+sd-jwt", "meta": { "vct_values": ["urn:eudi:pid:1"] },
                     "claim": [ { "path": ["age_equal_or_over", "18"] } ] } ],
  "purpose": [ { "lang": "en", "value": "Age check at checkout" } ],
  "privacy_policy": "https://shop.example/privacy",
  "registry_uri": "https://YOUR-SITE/wrpac-ca.ashx?registry=example-shop",
  "status": { "status_list": { "idx": 7, "uri": "https://YOUR-SITE/wrpac-ca.ashx?rc-status" } },
  "iat": 1792540800, "exp": 1792627200
}

Was die Relying Party integriert

http
# The relying party itself only does a standard OpenID Connect sign-in
# (authorization code + PKCE) with its gateway client and asks for the wallet:
https://YOUR-SITE/oauth2/v1/authorize?response_type=code
  &client_id=example-shop-web
  &redirect_uri=https%3A%2F%2Fshop.example%2Fcallback
  &scope=openid
  &acr_values=urn%3Acodeb%3Aacr%3Aeudi-wallet
  &state=...&nonce=...&code_challenge=...&code_challenge_method=S256
# Complete samples for Node.js, Python, PHP and ASP.NET Core: relying-party-quickstart.html

Öffentlicher Registereintrag

shell
# Public register entry (the registry_uri in the certificate) - shows that the
# relying party uses an intermediary and which one (CIR (EU) 2025/848 Annex I points 14-15):
curl -s "https://YOUR-SITE/wrpac-ca.ashx?registry=example-shop"
# { "id": "example-shop", "official_name": "Example Shop Ltd", ...,
#   "uses_intermediary": true,
#   "intermediary": { "sub": "VATMT-99999999", "sname": "CodeB" }, "status": "valid" }

Häufige Fragen

Was ist ein Intermediär für die EUDI-Wallet?

Ein Intermediär ist eine Relying Party, die im Auftrag anderer Relying Parties mit der EU Digital Identity Wallet kommuniziert. Nach der überarbeiteten eIDAS-Verordnung gelten Intermediäre selbst als Relying Parties und dürfen keine Daten über den Inhalt der von ihnen abgewickelten Transaktionen speichern. Das Architecture and Reference Framework (ARF) beschreibt die Rolle neben Relying Parties und deren Instanzen.

Was ändert sich für die Person mit der Wallet?

Jede Anfrage trägt zwei Zertifikate: das Zugangszertifikat des Intermediärs, das belegt, wer die Anfrage abwickelt, und das Registrierungszertifikat der Relying Party, das angibt, wer die Daten erhält, wozu, und den Intermediär nennt. Eine Wallet kann also „wer fragt“ und „in wessen Auftrag“ anzeigen.

Braucht jede Relying Party trotzdem eine eigene Registrierung?

Ja. Die Durchführungsverordnung (EU) 2025/848 verlangt, dass eine Relying Party in ihrer Registrierung angibt, ob sie einen Intermediär nutzt und welchen (Anhang I Nummern 14 und 15). Das Modul führt diesen Registereintrag je Relying Party und stellt ihr Registrierungszertifikat mit den Intermediär-Feldern nach ETSI TS 119 475 aus.

Was ist der Unterschied zum CodeB Relying Party Gateway?

Das Relying Party Gateway lässt eine Organisation die Wallet auf ihrer eigenen Website akzeptieren. Der Wallet-Intermediär lässt Sie das vielen Organisationen unter deren eigenem Namen anbieten: Jede wird einzeln registriert, erscheint in der Wallet als sie selbst und lässt sich einzeln sperren – während Sie eine Installation und ein Zugangszertifikat betreiben.

Können wir das mieten oder lizenzieren?

Ja. CodeB Wallet Intermediary gibt es als gehosteten Dienst, betrieben von Aloaha, oder als Modul einer CodeB-Installation, die Sie unter Ihrem eigenen Namen betreiben. Preise auf Anfrage.

Was muss die Relying Party bauen?

Eine normale OpenID-Connect-Anmeldung (Authorization Code mit PKCE) und eine Prüfung des acr-Claims. Keine Wallet-Protokolle, keine Zertifikate, keine Vertrauenslisten. Der Entwickler-Schnellstart enthält vollständige Beispiele.

Behält der Intermediär die vorgelegten Daten?

Vorgelegte Angaben werden bei der Anmeldung an die Relying Party übergeben und nur für diese Anmeldung und die übergebenen Tokens vorgehalten; sie landen in keinem Profil. Es gibt keine Drittanbieter-Analytik.

Welche Wallets akzeptieren das?

Wallets, die OpenID for Verifiable Presentations 1.0 umsetzen und den verwendeten Zertifikaten vertrauen. Heute stammen Zugangs- und Registrierungszertifikate aus der CodeB-Zugangszertifikats-CA und ihrem Relying-Party-Register, das kein nationales Register eines Mitgliedstaats ist; Wallets akzeptieren sie, wo sie dieser CA vertrauen.

Was passiert, wenn ein Kunde geht oder Regeln verletzt?

Sperren oder löschen Sie seine Registrierung: Neue Anmeldungen für diese Relying Party enden sofort, und ihre Registrierungszertifikate erscheinen in der Statusliste, die Wallets prüfen, als gesperrt oder ungültig.

Ist das zertifiziert?

Nein. Das Modul folgt dem ARF 3.0, OpenID4VP 1.0, HAIP 1.0 und ETSI TS 119 475; es ist nicht zertifiziert und beansprucht kein eIDAS-Vertrauensniveau.

Intermediär werden?

Schreiben Sie uns: gehosteter Dienst oder Modul Ihrer eigenen Installation – wir richten Register, Zertifikate und den ersten Kunden mit Ihnen ein.