Über W3C-Politics im Wallet-Krieg: Die Apple & Google “Mobile Document Request API”
Warum das EUDI Wallet, der Gaia-X PCM, kleine Anbieter und Projekte rund um die Entwicklung von Identitätswallets für Menschen einen schweren Stand haben
Apple und Google arbeiten im W3C Kontext an einer API für “mobile document requests”. Diese API stellt die eine proprietäre Verbindung zwischen Apple Wallets, Google Wallets und dem Webbrowser für die Bereitstellung von Identitäts-Credentials nach ISO/IEC 18013–5:2021 Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application her.
Die W3C Inkubationsaktivitäten von Apple & Google
Apple und Google arbeiten in den USA mit der American Association of Motor Vehicle Administrators (AAMVA) und verschiedenen staatlichen Organisationen des Department of Motor Vehicle (DMV) zusammen, um ISO 18013–5 Mobile Driver’s Licenses (mDLs) in ihre eigenen Payment-/Wallet-Ökosysteme zu übertragen und diese mDLs dann mit Organisationen wie der U.S. Transporation Security Administration (TSA), staatliche Strafverfolgungsbehörden und anderen potenziellen Einzelhandels-/Zahlungsanwendungen zu verknüpfen.
Die W3C Web Incubation Community Group (WICG) ist eine Gemeinschaftsgruppe beim W3C, die die Weiterentwicklung von Browser-Technologien und Standards vorbereitet, die weitgehend von Browserherstellern genutzt wird, um Informationen über geplante Technologien auszutauschen und Feedback zu künftigen Funktionen des Browsers zu sammeln.
Manchmal werden Elemente für ein paar Wochen inkubiert bevor sie in eine W3C-Arbeitsgruppe überführt werden, aber oft werden sie Monate bis Jahre lang inkubiert.
Mobile Document Request API
Nun hat Apple mit Unterstützung von Google gerade die Mobile Document Request API angekündigt:
Die API ist im Grunde eine Möglichkeit für eine Website, einen mobilen Führerschein anzufordern (und möglicherweise zukünftige Formate, die auf diesem Format basieren) und OS/Browser Platformanbieter zu befähigen, mDL-Credentials über Webseiten zu verarbeiten.
Da diese Aktivität erst einmal US-zentrisch ist, steht der mobile Führerschein im Mittelpunkt. In den US gibt es keine Personalausweise, sodass dort häufig der Führerschein die Funktion unserer Personalausweise für z.B. einen Alternsnachweis übernimmt. Der technologische Ansatz lässt sich sehr gut auch auf Personalausweise anwenden.
Zudem sieht es so aus, dass mDL (oder eine Abwandlung davon) auch wesentlicher Bestandteil des EU Digital (EUDI) Wallets sein wird. Dies beinhaltet auch eine simple Selective Disclosure Fähigkeit basierend auf signierten Hashlisten. Dieser Ansatz kommt mit Mainstream Cryptography aus. Er benötigt also keine Anoncreds oder andere fancy cryptography, die weder hinreichend kryptographisch untersucht noch standardisiert ist.
Die API ist besorgniserregend, weil sie die “Definition der nativen Kommunikation zwischen dem Benutzer-Agenten und der Anwendung, die das mdoc verwaltet” als außerhalb des Anwendungsbereichs liegend aufführt. Das heißt, die Auswahl des digitalen Wallets ist außerhalb des W3C Incubation-Geltungsbereichs (es wird von Apple und Google Wallets ausgegangen). Ebenfalls außerhalb des Geltungsbereichs sind “Issuing” und “Provisioning”. Die Spezifikation konzentriert sich auf die Übertragung von einer digitalen Wallet-Credentials zu einer Website.
Strategie zur Schaffung von unüberwindbaren Eintrittsbarrieren
Die oben beschriebene Vorgehensweise ist eine bewährte Strategie der Plattformanbieter, und es war nur eine Frage der Zeit, bis sie diesen Ansatz auch bei mDL (und mdoc im Allgemeinen) verfolgen würden. Diese Strategie wurde bereits erfolgreich von den großen OS/Browser Plattformanbieter in der W3C Web Payments Gruppe zwischen 2010–2015 angewendet.
Die Strategie der Plattformanbieter ist im Grunde die folgende:
- Die großen Anbieter von Technologieplattformen “inkubieren” eine Spezifikation in der WICG, die von OS-Plattform-Funktionen profitiert und die für Dritte nicht verfügbar ist (Hardware-gestützte Kryptoschlüssel, NFC, Secure Enclave usw.).
- Nach einigen Wochen bis Monaten der “Inkubationszeit” wird eine Demonstration der Spezifikation in Chrome und Safari veröffentlicht
- Die Anbieter lassen dann “außer Acht”, wie Betriebssystem und Browser die Informationen überhaupt erhält (Credential Request) — es wird als “zu schwierig eingestuft, eine Einigung über die Details zu erzielen” und es endet damit, dass es auf eine proprietäre plattformspezifisch hinausläuft.
- Die Anbieter beantragen dann eine Erweiterung der Charta in einer bereits existierenden Gruppe mit einer großen Anzahl von Ergebnissen (so dass die Anfrage im im Lärm eines großen Re-Charters untergeht). Manchmal beantragen sie eine neue Gruppe, wie z.B. Web Payments Gruppe. Sobald es so aussieht, dass es viel Interesse an einer Gemeinschaftsspezifikation und einem offenen Ökosystem gibt, wird dann alles durch eine eher geschlossene Lösung ersetzt, weil “diese einzige Lösung, der die OS/Browser Anbieter zustimmen werden”.
- Ein Anbieter schlägt einen “Application Selection Dialogue” vor (z.B. Auswahl einer digitalen Wallettechnologie) und implementiert diese bestimmte Architekturdefinition (normalerweise Google). Der andere Anbieter sagt, dass er es vielleicht irgendwann unterstützen wird, implementiert es dann jahrelang nicht — in der Regel Apple. In diesem speziellen Fall sieht es so aus als würden die beiden Anbieter den Versuch, einen Dialog zur Auswahl der Architekturdefinition und Wallets durchzuführen, überspringen. Und die Anbieter gehen diesmal direkt den Weg in Richtung proprietäre Ökosystemlösung.
- Das Einzige, was dann in der W3C Standardisierung ankommt, ist die grundlegende Browser-API und der proprietäre Informationsaustausch zwischen der Betriebssystem-Kompnente (z. B., Google Wallet, Apple Wallet). Die Funktion “Auswahl von Wallettechnologien” wird von fast allen Anbietern jahrelang nicht implementiert und dann stillschweigend fallen gelassen, weil der verbleibende Anbieter “kein Interesse an der Implementierung” hat. Dieses Ergebnis ist das Beste, auf das man hoffen kann, wenn man Konkurrenten fernhalten will — “Wir haben es versucht! Wir konnten nur keinen Konsens finden … “.
Kurz gesagt, dies sieht nach einem strategischen Schachzug der OS/Browser Anbieteraus, um unüberwindbare Eintrittsbarrieren für ihre proprietären Wallet-Ökosysteme zu schaffen.
Dies Vorgehensweien sollten bei den Regulierungsbehörden stark verpönt sei. Aber die Regulierungsbehörden scheinen diesen speziellen Trick aus dem Trickkiste der großen Tech-Unternehmen nicht Unternehmen zu kennen. Es handelt sich wohl um wettbewerbswidriges Verhalten unter dem Deckmantel der gutgläubigen Bemühung, ein wettbewerbsfähiges Ökosystem zu schaffen.
Es ist genial, wenn man darüber nachdenkt, dass ein Technologieunternehmen sagt “Lasst uns offen sein”, und das andere sagt “Sicher, aber nachdem wir Version 1 ausgeliefert haben”, und dann, sobald Version 1 ausgeliefert ist, sagen sie “Nein, nur ein Scherz, die Auswahl des Wallets ist ein Sicherheitsrisiko”. Dann sagt der andere Anbieter : “Nun, wir haben es versucht, aber wir können Vendor X nicht dazu bringen, sich zu öffnen, also lassen wir die Funktion zur Auswahl des Wallets einfach weg, denn, wie sie dann sagen, ist es ein Sicherheitsrisiko, wenn man bei den Wallets Vielfalt zulässt.”
Das könnte man aus Sicht von Level of Assurance (LoA) auch tatsächlich so argumentieren, wenn Apple und Google bestimmte Konformitätskriterien out of the box per se einhalten und die anderen Anbieter halt nicht, da sie nur beschränkten Zugriff auf dafür notwendige Security Features auf Betriebssystemebene haben.
Diejenigen unter uns, die dafür kämpfen, dass OIDC für mDLs unterstützt wird, sollten sich auch Sorgen machen. Gründe und Nutzen, OIDC zu unterstützen, werden schnell entwertet, sobald die “Mobile Document Request API” in Chrome und Safari integriert ist.
Das o.g. Szenario wird umso wahrscheinlicher, da mDL (oder eine Abwandlung davon) Bestandteil des EUDI Wallets sein wird. Damit entsteht in Summe für viele Wallet-Anbieter und Projekte wie das BMWK “Schaufensterprojekt Digitale Identität” ein signifikantes Risiko im Bereich der sogenannten Bürgerwallets aus dem Spiel gedrängt zu werden.
Gleiches gilt dann auch für Mitarbeiter-Wallets im Kontext von Unternehmensanwendungen.
Sobald einfach zu konsumierende APIs von Apple/Google vorliegen, können 100.000de von Entwicklern, diese ohne technische Grundkenntnisse sehr einfach und elegant in ihre Anwendungen integrieren.
Um unabhängig vom Smartphone zu sein, müssen Cloudwallet-Komponenten in eine Gesamtarchitektur integriert werden. Diese Strategie werden Apple und Google auch von sich aus auch zusätzlich verfolgen, um Funktionen wie Cross-Device Wallet Synchronisation, Back-up und Recovery, Export und Import-Funktionen, Delegation für Eltern Kind Beziehungen sowie sicheres Key Management und Key Recovery abbilden und anbieten zu können.
Wir gehen davon aus, dass auch das EUDI Wallet zuerst mit Cloud als zentraler Komponente umgesetzt wird, da die Integration der Smartphones Hersteller- und Modell-übergreifend eher schwierig ist. Es wird spannend sein zu sehen, ob und wie Apple und Google Cloud bei Wallet-Funktionen mit einem EUDI Ansatz zusammen spielen können oder wollen.
Ähnliche Überlegungen in Hinblick auf die Bereitstellung von Bürger- oder Mitarbeiter-Wallets gibt es auch im Gaia-X Umfeld. Hier werden solche Wallets Personal Credential Manager (PCM) genannt. Auch die PCMs sollen Device und Cloud-Komponenten haben. Auch hier wird es interessant zu beobachten wie das Zusammenspiel mit Apple und Google Device- und Cloud-Komponenten in der Zukunft ausgestaltet sein wird.
Wir sollten auch nicht vergessen, dass wenn die Geschichte der letzten 20 Jahre ein Indikator ist — die OS/Browser Plattformanbieter sehr gut darin, ihre Ökosysteme geschlossen zu halten, um sich damit einen unfairen Wettbewerbsvorteil (unfair advantage) im Kampf um Marktanteile und Monetarisierungspotentiale zu erarbeiten.
Quellen:
- W3C CCG Community Diskussion, Manu Sporny
- Diskussion mit Mirko Mollik
