Identitaetspruefung wird zum Webplattform-Workflow
Die Digital Credentials API verschiebt Identitaetspruefung von individuellen Upload-Flows zu browservermitteltem Credential-Austausch. Der W3C Working Draft vom August 2026 definiert eine API, mit der User Agents die Praesentation und Ausstellung digitaler Nachweise vermitteln koennen, waehrend Chrome 141 und Safari 26 die Idee fuer Produktteams deutlich konkreter gemacht haben.
Das ist fuer Kundenportale relevant, weil viele Produkte Nutzer noch immer Ausweiskopien hochladen lassen, manuelle Pruefung abwarten oder denselben Nachweis in Support, Onboarding und Compliance wiederholen. Digitale Nachweise koennen diese Momente schneller und privater machen, aber nur wenn das Produkt um Consent, minimale Attribute und verstaendliche Fallbacks gestaltet wird.
Mit dem wirklich benoetigten Attribut starten
Ein guter Digital-Credential-Flow beginnt mit einer engen Frage: Welche Tatsache muss das Produkt pruefen? Ein altersbeschraenkter Service braucht vielleicht nur den Nachweis, dass eine Person ueber einer Schwelle liegt. Ein Mobilitaets-, Finanz- oder Public-Service-Portal braucht eventuell eine staerkere Identitaetsaussage. Ein B2B-Workflow kann eine Berechtigung, berufliche Rolle oder Unternehmenszuordnung brauchen.
Das unterscheidet sich vom klassischen Dokumenten-Upload, bei dem Teams oft mehr personenbezogene Daten erhalten als noetig und danach Speicher-, Aufbewahrungs- und Sicherheitsrisiken uebernehmen. Die Digital Credentials API unterstuetzt Muster fuer selektive Offenlegung, deshalb sollte der Produktbrief den kleinsten ausreichenden Nachweis definieren, bevor Engineering den Request baut.
- Den Verifizierungszweck in Produktsprache formulieren, bevor ein Protokoll gewaehlt wird.
- Identitaet, Alter, Adresse, Lizenz, Rolle und Berechtigung getrennt betrachten.
- Nur das minimale Attribut anfragen, mit dem der Workflow fortgesetzt werden kann.
- Entscheiden, ob das Portal einen Nachweis, ein Pruefergebnis oder gar kein persoenliches Detail speichern muss.
- Festlegen, welche Nutzer ueber einen Fallback weiterkommen, wenn die API nicht verfuegbar ist.
Consent als wichtigste Oberflaeche gestalten
Browser und Betriebssystem stellen Credential Chooser und Consent-Oberflaeche bereit, aber das Produkt muss Nutzer trotzdem auf den Moment vorbereiten. Ein Kundenportal sollte erklaeren, warum Verifizierung angefragt wird, welches Attribut gebraucht wird, wer es empfaengt und was nach Zustimmung oder Abbruch passiert.
Gute Consent UX ist spezifisch statt dramatisch. Der Button sollte zur echten Aufgabe passen, zum Beispiel Alter bestaetigen, Identitaet verifizieren oder Mitgliedschaft nachweisen. Die Umgebung sollte vage Begriffe wie Wallet verbinden oder Ausweis hochladen vermeiden, wenn der Flow nur ein einzelnes verifiziertes Attribut braucht. Vertrauen entsteht, wenn Nutzer die Konsequenz nicht erraten muessen.
Browser-, Wallet- und Protokollunterschiede einplanen
Der Standard ist credential-format-agnostisch angelegt, echte Deployments unterscheiden sich aber weiterhin nach Browser, Geraet, Wallet und Austauschprotokoll. Die Chrome-Dokumentation verweist auf Feature Detection, Protokollpruefung sowie Same-Device- und Cross-Device-Presentation-Flows. WebKit beschreibt Plattform-Consent-Flows, die nahe Geraete oder QR-Handoff nutzen koennen.
Damit wird Progressive Enhancement zur praktischen Architektur. Ein Portal kann digitale Nachweisverifizierung dort anzeigen, wo sie unterstuetzt wird, braucht aber weiterhin einen verlaesslichen Fallback fuer nicht unterstuetzte Browser, Nutzer ohne kompatible Wallet, Enterprise-Geraete mit Policy-Einschraenkungen oder Credentials ohne das angefragte Attribut.
EUDI-Wallet-Readiness mit Produktbetrieb verbinden
Die EU Digital Identity Regulation hat digitale Identitaetswallets zu einem nahen Planungsthema fuer europaeische Produkte gemacht. Die Europaeische Kommission beschreibt einen Rahmen, in dem jeder Mitgliedstaat mindestens eine Wallet fuer Buerger, Unternehmen und Einwohner bereitstellen muss, um sichere grenzueberschreitende Identifizierung und Authentifizierung zu staerken.
Fuer eine Webplattform bedeutet das nicht, dass jedes MVP ab Tag eins vollstaendige EUDI-Wallet-Akzeptanz braucht. Es bedeutet aber, dass Teams wissen sollten, welche Relying-Party-Pflichten, Registrierungsprozesse, Credential-Formate, Issuer-Trust-Listen und Aufbewahrungsregeln relevant werden koennen. Product, Legal und Engineering brauchen ein gemeinsames Betriebsmodell statt Identitaetspruefung als Vendor-Widget zu behandeln.
Verifizierungsevidenz nuetzlich, aber klein halten
Identitaetschecks erzeugen sensible operative Evidenz. Support muss eventuell wissen, dass ein Nutzer die Verifizierung abgeschlossen hat, welcher Credential Issuer vertraut wurde, wann das Ergebnis ablaeuft und warum ein Flow fehlgeschlagen ist. Das Produkt muss meist kein Rohdokument, keine vollstaendige Credential Payload und keine zusaetzlichen Attribute speichern, die fuer die Entscheidung nicht gebraucht wurden.
Ein praktischer Audit Trail erfasst Zweck der Anfrage, Attributumfang, Issuer oder Trust Framework, Ergebnis, Zeitstempel, Retention-Regel, Nutzeraktion und Fallback-Pfad. Diese Evidenz sollte Support und Compliance helfen, ohne heimlich wieder das Uebererhebungsproblem aufzubauen, das digitale Nachweise eigentlich reduzieren sollen.
Ein praktischer erster Build fuer Kundenportale
Fuer EDS Labs Projekte ist ein starker erster Digital-Credentials-Build eng und messbar: einen Verifizierungsmoment waehlen, das minimale Attribut definieren, Consent Copy gestalten, Feature Detection ergaenzen, den Credential Request implementieren, den Fallback bauen und nur die Evidenz loggen, die fuer den Betrieb noetig ist.
Das Ergebnis ist nicht nur ein modernes Identity Feature. Es ist eine ruhigere Portal-Erfahrung: weniger Dokumenten-Uploads, weniger unnoetige Datenverarbeitung, klarerer Consent und ein Verifizierungsflow, der mit Browser-Support, Wallet-Adoption und europaeischer Digital-Identity-Infrastruktur wachsen kann.