Die Wallet kennt die Person. Darf diese Person auch für den Kunden bestellen?

Ein neuer Einkäufer meldet sich im Kundenportal an. Sein digitaler Identitätsnachweis ist gültig, der Name stimmt und die Anmeldung verläuft problemlos. Danach bestellt er auf Rechnung für eine Firma, bei der seine Einkaufsberechtigung längst beendet wurde. Die Identität war nicht das Problem. Das Portal hat eine zweite Frage übersprungen.

Mit europäischen digitalen Identitäts-Wallets wird der Nachweis bestimmter Angaben technisch interessanter. Für deutsche B2B-Anbieter ergibt sich daraus eine konkrete Entwicklungsaufgabe: Wie verbindet das Portal geprüfte Nachweise mit seinen eigenen Kundenbeziehungen und Freigaben? Der Nutzen entsteht dort, wo ein sauberer Prozess weniger manuelle Rückfragen erzeugt und trotzdem widerrufbare Rechte behält.

Formulieren Sie drei getrennte Fragen

Die erste Frage lautet: Wer meldet sich an? Die zweite: Zu welcher Kundenorganisation gehört diese Person im aktuellen Vorgang? Die dritte: Welche Handlung darf sie dort ausführen? Ein Portal, das diese Fragen in einem einzigen Status „verifiziert“ zusammenfasst, verliert wichtige Unterschiede.

Eine Person kann für mehrere Unternehmen tätig sein. Sie kann Angebote ansehen dürfen, ohne Bestellungen auszulösen. Eine Bestellung kann außerdem eine weitere Freigabe benötigen. Diese Regeln stammen aus der Geschäftsbeziehung. Sie sollten weder aus einer E-Mail-Domain noch aus einer erfolgreich geprüften persönlichen Identität automatisch abgeleitet werden.

Die Europäische Kommission beschreibt die EUDI Wallet als Mittel zur digitalen Identifikation und zum kontrollierten Teilen digitaler Nachweise. Für ein konkretes Portal müssen verfügbare Wallets, unterstützte Nachweise und der aktuelle Integrationsrahmen geprüft werden. Ein angekündigtes Ökosystem ist keine Garantie, dass jede gewünschte Funktion bereits für jeden Nutzer verfügbar ist.

Starten Sie mit einem Nachweis, der einen echten Engpass löst

Suchen Sie einen klaren Anwendungsfall. Vielleicht benötigt Ihr Team bei der Anlage neuer Geschäftskonten wiederholt bestimmte Identitätsangaben. Vielleicht soll eine vorhandene Kundenbeziehung mit einem stärkeren Nachweis verbunden werden. Vermeiden Sie einen Pilot, der sämtliche Registrierungs- und Freigabeprozesse gleichzeitig ersetzt.

Beschreiben Sie vor der Umsetzung, welche Information heute manuell geprüft wird und welches Ergebnis die Anwendung danach speichern darf. Manchmal reicht ein bestätigter Prüfstatus mit Bezug auf den Vorgang. In anderen Fällen werden bestimmte Angaben benötigt. Eine vollständige Kopie aller verfügbaren Daten ist kein sinnvoller Standard.

Berücksichtigen Sie Personen ohne passende Wallet oder mit einem nicht unterstützten Gerät. Ein alternativer Prozess verhindert, dass ein technischer Integrationsversuch bestehende Kunden ausschließt. Er muss ebenso nachvollziehbar sein und darf nicht unbeabsichtigt zu einem einfacheren Weg werden, die vorgesehenen Prüfungen zu umgehen.

Prüfen Sie den Nachweis im richtigen Kontext

Eine empfangene Antwort muss zur begonnenen Sitzung und zur konkreten Anfrage gehören. Die Anwendung benötigt außerdem einen nachvollziehbaren Umgang mit Ausstellern, Gültigkeit und den für das Verfahren vorgesehenen Statusprüfungen. Ein optisch plausibler Nachweis oder ein erfolgreich gelesener Datensatz genügt dafür nicht.

Das offizielle Architecture and Reference Framework der EUDI Wallet dokumentiert die technische Architektur und ihre Entwicklung. Ein Umsetzungspartner sollte die verwendete Fassung und die für den Pilot relevanten Profile benennen. Unklare Aussagen über „Wallet-Kompatibilität“ erschweren spätere Tests zwischen verschiedenen Beteiligten.

Lassen Sie Fachbegriffe in der Benutzeroberfläche nicht die eigentliche Entscheidung verdecken. Ein Sachbearbeiter muss erkennen können, welcher Nachweis geprüft wurde und welche Firmenberechtigung noch offen ist. Ein grünes Symbol sollte einen klar beschriebenen Zustand repräsentieren, nicht sämtliche verbleibenden Prüfungen unsichtbar machen.

Halten Sie Vertretung und Bestellrechte aktuell

Die Zuordnung zu einer Kundenorganisation benötigt einen verantwortlichen Freigabeweg. Ein bestehender Administrator des Kunden kann beispielsweise Personen einladen oder Rechte bestätigen, sofern dies zum vereinbarten Prozess passt. Änderungen müssen mit Zeitpunkt, verantwortlicher Person und Wirkung nachvollziehbar bleiben.

Ein Widerruf sollte nicht erst bei der nächsten Neuregistrierung greifen. Prüfen Sie, wie bestehende Sitzungen und bereits vorbereitete Vorgänge behandelt werden. Eine offene Bestellung kann eine erneute Berechtigungsprüfung erfordern, wenn sich Rolle oder Kundenbeziehung geändert haben. Diese Entscheidung muss ausdrücklich zum fachlichen Ablauf passen.

Auch Vertreterwechsel und verlorene Geräte gehören in den Entwurf. Die Identität einer Person, ihr Zugangsmittel und ihre Rolle sind unterschiedliche Dinge. Ein neues Gerät sollte nicht sämtliche alten Firmenrechte ungeprüft wiederherstellen. Umgekehrt darf ein technischer Kontowechsel nicht die historische Zuordnung bereits abgeschlossener Vorgänge zerstören.

Machen Sie Datenminimierung bedienbar

Zeigen Sie verständlich an, welche Angaben für den nächsten Schritt benötigt werden und weshalb. Wenn eine Eigenschaft genügt, sollte nicht automatisch ein vollständiges Dokument angefordert werden. Die technische Integration und die fachliche Datennutzung müssen gemeinsam geplant werden, damit unnötige Angaben nicht aus Bequemlichkeit im Kundenprofil landen.

Legen Sie fest, wer Prüfdetails sehen darf und wie lange diese gespeichert werden. Entwicklungs- und Supportlogs sollten keine vollständigen Identitätsnachweise enthalten. Für Fehleranalysen reichen häufig Vorgangskennung, Fehlerkategorie und technische Zeitangaben. Konkrete Aufbewahrung und zulässige Verarbeitung müssen zum Unternehmen und zum Verfahren passen.

Eine Abnahme mit schwierigen Kundenkonstellationen

Der erste Pilot sollte neben einer erfolgreichen Anmeldung mindestens diese Fälle enthalten:

• Eine gültige Person besitzt noch keine bestätigte Firmenzuordnung.
• Ein Nutzer gehört zu zwei Kundenorganisationen mit unterschiedlichen Rechten.
• Eine Einkaufsberechtigung wird während einer bestehenden Sitzung entzogen.
• Ein Nachweis passt nicht zur aktuellen Anfrage.
• Eine benötigte Eigenschaft fehlt oder wird nicht geteilt.
• Der alternative Zugang funktioniert, ohne die vorgesehene Prüfung zu überspringen.

Testen Sie außerdem die Erklärung im Supportfall. Eine Person sollte erfahren, ob die technische Prüfung fehlgeschlagen ist oder eine fachliche Freigabe fehlt. Diese Unterscheidung verhindert unnötige Wiederholungen und hilft Ihrem Team, den richtigen Ansprechpartner einzubeziehen.

Innovation T kann dafür eine bestehende Anmeldung um einen abgegrenzten Nachweisprozess ergänzen. Unsere Beiträge zu Passkeys als Zugangsmittel und OAuth beziehungsweise OpenID Connect behandeln verwandte Grundlagen. Die Softwareleistungen verbinden diese Technik mit Ihrem Kundenprozess. Besprechen Sie den Nachweis und die konkrete Handlung, die danach erlaubt sein soll, bevor aus einer Wallet-Anmeldung eine zu weitreichende Freigabe wird.

Häufige Fragen

Ersetzt eine EUDI Wallet automatisch die Rollenverwaltung im Kundenportal?

Nein. Ein Identitätsnachweis und eine Berechtigung für einen konkreten Geschäftsvorgang beantworten unterschiedliche Fragen. Firmenzuordnung, Bestellgrenzen und Freigaben müssen passend zum Portal geprüft und verwaltet werden.

Sollte ein bestehendes B2B-Portal sofort alle Anmeldeverfahren austauschen?

Nicht allein wegen des Trends. Sinnvoll ist ein abgegrenzter Integrationsversuch mit den tatsächlich verfügbaren Wallets und Nachweisen. Bestehende Zugänge und Wiederherstellungswege sollten währenddessen zuverlässig weiter funktionieren.

Muss die Anwendung sämtliche angebotenen Identitätsdaten speichern?

Nein. Sie sollte nur die für den konkreten Zweck benötigten Angaben anfordern und ihre Speicherung begründen. Der Umfang der angeforderten Daten gehört ebenso in die Planung wie deren technische Prüfung.