Orientierung für Stadtwerke · Stand 16. Oktober 2026
Für ein Stadtwerk beginnt die EUDI-Wallet-Frage nicht mit einer API. Zuerst braucht es einen konkreten Identitäts- oder Nachweisprozess, die passende Rolle im Ökosystem und einen realistischen Blick auf Betrieb, Datenminimierung und Zertifikate.
Kurze Antwort
Organisationen können in der deutschen EUDI-Wallet-Sandbox Nachweise prüfen, als EAA Provider eigene digitale Attributsnachweise ausstellen oder beide Rollen verbinden.[1] Der gemeinsame Onboarding-Pfad folgt den Stufen Plan, Integrate und Operate.[2]
Für Stadtwerke ist das zunächst ein Orientierungs- und Use-Case-Thema. Die öffentlichen Unterlagen belegen keinen pauschalen unmittelbaren Beschaffungs- oder Integrationszwang für jedes Energieunternehmen. Sie zeigen aber konkrete Voraussetzungen für Organisation, Technik und Betrieb.
Rollenmatrix
Die Rolle folgt dem Prozess: Wird ein vorhandener Nachweis geprüft, ein eigener Nachweis ausgestellt oder werden beide Schritte wirklich benötigt?
Ein Stadtwerk prüft Nachweise, die eine Person aus ihrer Wallet vorlegt.
Erste Fachfrage
An welchem konkreten Prozesspunkt ist welcher Nachweis wirklich erforderlich?
Technischer Fokus
Verifier-Komponente, OpenID4VP, HTTPS, Zertifikate, Trust Registry und minimale Protokollierung.
Ein Stadtwerk stellt einen digitalen Attributsnachweis aus, für den es fachlich und organisatorisch zuständig ist.
Erste Fachfrage
Darf und kann das Stadtwerk diesen Credential-Typ belastbar ausstellen und über seinen Lebenszyklus pflegen?
Technischer Fokus
Credential-Schema, Rulebook, Ausstellungsprozess, Schlüssel- und Zertifikatsmanagement.
Ein Use Case kombiniert das Prüfen und Ausstellen unterschiedlicher Nachweise.
Erste Fachfrage
Sind beide Rollen für denselben Nutzen nötig oder wird der erste Test dadurch unnötig groß?
Technischer Fokus
Ein gemeinsames Onboarding, aber getrennte technische Komponenten und Verantwortlichkeiten.
Der offizielle Onboarding-Guide sieht für beide Rollen einen gemeinsamen organisatorischen Einstieg, aber rollenspezifische Integrationsschritte vor.[2]
Readiness-Check
Der Developer Guide verlangt unter anderem technische und operative Kontakte, API- und HTTPS-Fähigkeit, sichere Betriebsprozesse sowie eine klare Zweckbindung der angeforderten Daten.[2][3]
Drei Hypothesen
Diese Beispiele sind Prüfhypothesen, keine belegten Standardprozesse, Produktversprechen oder Rechtsaussagen. Die Sandbox erlaubt inzwischen auch das Testen elektronischer Attributsnachweise mit Testdaten.[4]
Hypothese: Eine RP-Integration könnte dort relevant werden, wo ein digitaler Prozess heute eine belastbare Identitätsprüfung benötigt. Vor einem Test ist zu klären, ob PID-Daten tatsächlich erforderlich sind und an welcher Stelle sie einen bestehenden Medienbruch reduzieren würden.
Hypothese: Ein digitaler Attributsnachweis könnte in ausgewählten Prozessen eine Eigenschaft oder Berechtigung belegen, ohne mehr personenbezogene Daten als nötig offenzulegen. Dafür braucht es einen legitimen Credential-Typ, eine zuständige ausstellende Stelle und ein nachvollziehbares Rulebook.
Hypothese: Bei externen Fachkräften oder Partnerunternehmen könnten prüfbare Qualifikationsnachweise einen klar definierten Zugangsschritt unterstützen. Das ist erst dann ein tragfähiger Use Case, wenn Verantwortlichkeit, Aktualität, Widerruf und Prozessnutzen geklärt sind.
Integrationsreife
Use Case, Rolle, erforderliche Attribute, Nutzen, Verantwortung und Ressourcen intern klären.
Rollenspezifische Komponenten anbinden und Flows, Fehlerfälle, Datenminimierung und Nutzerführung testen.
Zertifikate, Logs, Registry-Status, Widerruf, Support und Änderungen der Sandbox dauerhaft beherrschen.
FAQ
Aus den hier ausgewerteten öffentlichen Sandbox-Unterlagen folgt kein pauschaler unmittelbarer Integrationszwang für jedes Stadtwerk. Sinnvoll ist zunächst eine fachliche Einordnung: Gibt es einen konkreten Identitäts- oder Nachweisprozess, welche Rolle hätte das Unternehmen und reicht die organisatorische sowie technische Reife für einen begrenzten Test?
Eine Relying Party fordert einen Nachweis an und prüft ihn. Ein EAA Provider stellt einen elektronischen Attributsnachweis aus. Eine Organisation kann beide Rollen übernehmen, benötigt dafür aber getrennte technische Komponenten und klar zugeordnete Verantwortung.
Nein. Die Sandbox dient zum Testen und Lernen. Der Developer Guide weist ausdrücklich darauf hin, dass sich heutige Lösungen vor dem Übergang in die Produktionsumgebung noch ändern können.
Der öffentliche Leitfaden nennt unter anderem sichere HTTPS-Dienste, eine Verifier-Komponente mit OpenID4VP, unterstützte Credential-Formate, Zertifikats- und Trust-Registry-Prozesse sowie Tests für Datenminimierung, Fehlerfälle und Nutzerführung.
Nur Attribute, die für den konkret beschriebenen Dienst erforderlich sind. Der RP-Leitfaden verlangt Datenminimierung und Zweckbindung; die Auswahl gehört deshalb bereits in die Use-Case-Definition und nicht erst in die technische Umsetzung.
Dieser Beitrag bietet eine fachliche Erstorientierung auf Basis öffentlich zugänglicher Sandbox-Unterlagen. Er ist keine Rechts-, Datenschutz-, Sicherheits- oder Compliance-Beratung und bestätigt keine Produktionsreife eines konkreten Systems.
Die Dokumentation und die Sandbox werden weiterentwickelt. Vor einer Integration zählt daher der aktuelle Stand der offiziellen Leitfäden, nicht ein einmalig festgeschriebener Projektplan.
Sie haben einen konkreten Identitäts- oder Nachweisprozess im Blick? Beschreiben Sie Prozesspunkt, benötigten Nachweis und vermutete Rolle in wenigen Sätzen. Bitte senden Sie im Erstkontakt keine Personen- oder Kundendaten.