Intermediär betreiben
Ihre Installation hat ein Zugangszertifikat (als Intermediär) und einen Registrar-Signer für Registrierungszertifikate, beide aus der Zugangszertifikats-CA.
Produkt · EU Digital Identity Wallet · Intermediär
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.
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.
intermediary und act.sub, mit Statusliste.Vier Schritte; die ersten beiden je Kunde nur einmal.
Ihre Installation hat ein Zugangszertifikat (als Intermediär) und einen Registrar-Signer für Registrierungszertifikate, beide aus der Zugangszertifikats-CA.
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.
Normales OpenID Connect mit acr_values=urn:codeb:acr:eudi-wallet. Auf ihrer Seite nichts Wallet-Spezifisches.
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.
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.
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 oder Löschen einer Registrierung beendet neue Anmeldungen für diesen Kunden sofort und markiert seine Registrierungszertifikate in der Statusliste.
Das Registrierungszertifikat listet genau die Nachweise und Angaben der jeweiligen Anfrage; die Wallet legt per selektiver Offenlegung nur diese offen.
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.
Gateway-Clients ohne Intermediär-Registrierung melden sich weiter mit Ihrer Installation als Relying Party an – Sie stellen Kunden schrittweise um.
Wallet-Annahme für Ihre Signatur- und Siegelkunden, gebündelt mit Ihren bestehenden Diensten.
Die PID aus der Wallet als Alternative zu Video- und Dokumentenprüfung, für viele Mandanten aus einer Installation.
Ein Zugang zur Wallet für Gemeinden und Behörden, jede mit eigenem Namen und Zweck in der Wallet.
Praxen, Kanzleien, Händler und Vereine erhalten die Wallet-Anmeldung, ohne selbst Zertifikate und Protokolle zu betreiben.
Folgt dem ARF 3.0, ETSI TS 119 475, OpenID4VP 1.0 und HAIP 1.0. Nicht zertifiziert.
Vorgelegte Angaben gehen an die Relying Party und werden nur für die Anmeldung vorgehalten; keine Drittanbieter-Analytik.
Zertifikate stammen heute aus der CodeB-Zugangszertifikats-CA und ihrem Register – nicht aus einem nationalen Register. Wallets akzeptieren sie, wo sie dieser CA vertrauen.
Kontakt, Datenschutzerklärung und Aufsichtsbehörde der Relying Party stehen im Registrierungszertifikat; Löschanträge über den ARF-Endpunkt.
Register, Zertifikat und Kundenintegration in vier Ausschnitten.
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"
}'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
}# 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# 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" }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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Die EU-Wallet auf der eigenen Website akzeptieren.
OpenID-Connect-Code für Relying Parties.
Wie Zugangs- und Registrierungszertifikate ausgestellt werden.
OpenID4VP-Endpunkte, Registrierungszertifikat, Löschanträge.
Schreiben Sie uns: gehosteter Dienst oder Modul Ihrer eigenen Installation – wir richten Register, Zertifikate und den ersten Kunden mit Ihnen ein.