Verfahren und System zur endgerätebasierten Kommunikation zwischen Fremdanwendungen und einem elektronischen Wallet Die Erfindung betrifft ein Verfahren sowie ein System zur endgerätebasierten Kommunikation zwischen Fremdanwendungen und einem elektronischen Wallet, wobei insbesondere Daten für die Nutzung von Internetservices über das elektronische Wallet verwaltet werden.

Verwendete Abkürzung

NFC Near Field Communication

UICC Universal Integrated Circuit Card

SIM Subscriber Identity Module

APDU Application Protocol Data Unit

CRS Contactless Registry Service

PPSE Proximity Payment Systems Environment

API Programmierschnittstelle (Application Programming Interface)

IP Item Provider

mWallet Mobile Wallet

OTA Over The Air

POS Point of Sale

VAS Value added Service Stand der Technik

Unter einem elektronischen Wallet (im Folgenden auch einfach als„Wallet" bezeichnet) versteht man ein Hard- und Software-Modul innerhalb eines Endgeräts, zumeist eines mobilen Endgeräts wie beispielsweise einem Mobiltelefon oder Smartphone, das aus zwei Teilen besteht:

• Einem„Secure Element", im Folgenden auch„Sicherheitselement" genannt (z.B. in Form einer SIM-Karte/UICC oder einer in den Chipsatz des Endgeräts integrierten Javacard), mit darauf befindlichen Java Applets, die einerseits von Anwendungen auf dem Endgerät als auch über drahtlose Funkkommunikation (beispielsweise NFC) von Akzeptanzstellen (also Kartenlesern) im Card Emulation Mode angesprochen werden können.

• Einer Software zur Darstellung, Verwaltung sowie der Ermöglichung von Nutzerinteraktionen für die auf dem Sicherheitselement (Secure Element) befindlichen Javacard- Anwendungen.

Im Ergebnis erlaubt diese Architektur des elektronischen Wallets die Abbildung realer Smart Cards (für verschiedenste Anwendungsfelder wie Bezahlen, Kundenkarte, Coupons) auf das Endgerät, wobei die Rolle des Chips der realen Karte von den Java Applets auf dem Sicherheitselement, beispielweise der UICC, übernommen wird und die Rolle des Aufdrucks (also der Beschriftung, der Gestaltung, des Logos und/oder sonstigen Kennzeichnungen) auf der physischen Karte durch die Wallet-Software auf dem Endgerät, beispielsweise dem Mobiltelefon.

Unter einer„Applet" sei dabei hier und im Folgenden eine Anwendung verstanden, die für die Ausführung auf einem Sicherheitselement konfiguriert ist. Anstelle von„Applet" wird im Folgenden auch die synonyme Bezeichnung„Cardlet" verwendet. Ferner sei im Folgenden eine Anwendung, die für die Ausführung unter dem Betriebssystem des Endgeräts konfiguriert ist, als„App" bezeichnet.

Befindet sich das elektronische Wallet auf einem mobilen Endgerät wie etwa einem Mobiltelefon, so soll das elektronische Wallet auch als „Mobile Wallet" bezeichnet werden.

Die Karten im elektronischen Wallet lassen sich dann an entsprechenden Akzeptanzstellen wie physische Plastikkarten verwenden, durch drahtlose Funkkommunikation (z.B. die Nahfunktechnik NFC) können Applets auf dem Sicherheitselement (etwa der UICC) beispielsweise an der Kasse im Supermarkt kontaktlos angesprochen werden.

Diese Technik erlaubt also die Verwendung eines Sicherheitselements (wie etwa der UICC) als Mehrfunktions-Smartcard, wobei der Nutzer in den Genuss des entsprechenden Sicherheitsniveaus einer Smartcard-Anwendung kommt: Daten können aus der Smartcard nicht ausgelesen werden, die Smartcard lässt sich nicht kopieren und gibt Ihre Daten gegebenenfalls erst nach Eingabe einer PIN zur Nutzung frei. Für ähnliche Vorgänge in der Online- Welt haben sich jedoch andere Verfahren etabliert. So werden beispielsweise Bezahl Vorgänge durchgeführt, indem Nutzer auf Web-Seiten Informationen von ihrer Kreditkarte ablesen und in Web-Formulare eingeben. Die Authentifizierung von Nutzern gegenüber Web-Seiten erfolgt üblicherweise durch die Eingabe von Nutzerkennung und Passwort.

Auf mobilen Plattformen (hier und im Folgenden sei unter dem Begriff„Plattform" das Betriebsystem eines Endgeräts verstanden, unter„mobiler Plattform" sei das Betriebsystem eines mobilen Endgeräts verstanden) wiederum ist es üblich, zum Bezahlen für Apps und andere digitale Güter auf dem mobilen Endgerät, seine Bezahlkartendaten einmalig mit einem Konto des Handyherstellers zu verbinden, so dass der Erwerb solcher Güter in Zukunft z.B. auf eine Kreditkarte abgerechnet werden kann. Für die Nutzung von Online- Diensten (wie z.B. der server-basierten Speicherung von Fotos) ist es üblich, eine App bereitzustellen, die den Zugriff auf die zentral gespeicherten Daten vom mobilen Endgerät aus erlaubt. Dazu werden Nutzerkennung und Passwort in dieser App gespeichert.

Die US 2009/0 234 751 AI offenbart ein elektronisches Wallet für ein drahtloses mobiles Gerät und ein Verfahren zur Verwendung des elektronischen Wallets. In einer Ausführungsform weist das elektronische Wallet auf: eine Aufrufeinrichtung, die auf einen externen außerhalb des Wallet entstehenden Auslöser reagiert; eine Nutzerauthentifizierungseinrichtung um den Nutzer des elektronischen Wallets bei Aufrufen des Wallets durch den externen Auslöser zu authentifizieren; und eine Einrichtung zum Widergeben von in dem Wallet gespeicherten Karteninformationen abhängig von einem Formular, das von dem das Wallet anrufenden externen Auslöser spezifiziert wird. Der externe Auslöser kann eine Website sein, die über einen Internet Browser auf dem dralitlosen mobilen Gerät besucht wird, wobei in die Website eine Wallet-Auslöseanweisung eingebettet ist. Die Wallet-Auslöseanweisung kann eine Ergänzung sein, die im Header der über den Internet Browser besuchten Website eingebettet ist. Die Website kann ferner Feld ID Tags enthalten, die bestimmte Datenfelder in dem Wallet aufzeichnen um von der Website zur Verfügung gestellte Eingabefelder zu bilden.

Die WO 2006/085 805 AI betrifft ein Verfahren zum Durchführen elektronischer Transaktionen in einem Netzwerk, das aufweist: ein mobiles Subscriber- Terminal mit einem digitalen Wallet und einem Browser, einen Server für das Management der Transaktionen und einen Content-Provider. In dem Verfahren wählt der Subscriber einen Dienst aus und schickt ein Antragsformular an einen Content-Provider. Als Antwort schickt der Content-Provider ein Transaktionsantragsformular an den mobilen Subscriber. Der Subscriber bestätigt die Transaktion und schickt das Transaktionsantragsformular an den Browser. Der Browser liest die für das Transaktionsformular benötigten Daten von dem digitalen Wallet und füllt das Antragsformular mit den gelesenen Transaktionsdaten aus. Das vollständige Formular wird dann an den Server geschickt, der das vollständige Formular in ein Standardtransaktionsformat umwandelt. Der Content-Provider arbeitet das vollständige Antragsformular ab und schickt es and den Content-Provider, der dem Subscriber abtwortet.

Die US 2012/0 123 868 AI beschreibt ein System zur dynamischen Anpassung der von einer tragbaren Kommunikationseinrichtung verwendeten drahtlosen Datenemulation basierend auf dessen Geolokation. Das System bestimmt eine Geolokation der tragbaren Kommunikationseinrichtung durch Übertragen der derzeitigen Geolokationsdaten unter Verwendung des am besten geeigneten Kanals an den Server; Empfangen von Daten von Bezahlsystemen, die sich in der Nähe der tragbaren Kommunikationseinrichtung befinden könnten; und Erarbeiten eines Bezahlsystems in der tragbaren Kommunikationseinrichtung mit den Datenformaten und anderen drahtlosen Verkaufspunktdaten, die typisch sind für Bezahlsysteme, die sich in der Nähe der Einrichtung befinden könnten.

US 2012/0 166 337 AI zeigt ein Nahfeldkommunikations-(NFC)-Terminal zur Durchführung sicherer Bezahlung, das eine NFC-Einheit und eine Kontrolleinheit aufweist. Die NFC-Einheit kommuniziert mit einem externen Bezahl-Terminal und die Bezahleinheit überträgt unter Verwendung der NFC-Einheit Ergebnisse erworben durch die Verarbeitung von Transaktionsinformationen und eines elektronischen Signaturwertes der Transaktionsinformationen an das Bezahl-Terminal. Das Bezahl-Terminal fordert einen externen Bezahlserver auf, die Zahlung durchzuführen. Ein Authentifizierungsbestätigungsapplet in der Bezahleinheit generiert die elektronische Signatur der Transaktionsinformationen. Ein in der Bezahleinheit beinhaltetes elektronisches Wallet-Applet überträgt das durch die Verarbeitung der Transaktionsinformationen und des elektronischen Signaturwertes erhaltene Ergebnis an das Bezahlterminal.

Die US 2012/0 130 839 AI beschreibt Techniken zum Managen von in dem mobilen Gerät installierten Modulen oder Applikationen. Um authentische und sichere Transaktionen mit einem anderen Gerät zu ermöglichen, wird jede der installierten Applikationen durch das Datenübertragungspotential in einem mobilen Gerät mit einem Server versehen. Eine versehene Applikation steht in Verbindung mit dem personalisierten Sicherheitselement des mobilen Gerätes und arbeitet mit einem Satz Schlüssel, die in Übereinstimmung mit einem Schlüsselsatz des personalisierten Sicherheitselementes erzeugt wurden. Ferner wird das Kontrollmanagement einer installierten Applikation beschrieben.

Die WO 2012/021 864 A2 zeigt ein telefonbasiertes elektronisches Wallet, das authentifizierte Transaktionen über mehrere Handelswege bietet. Das elektronische Wallet kann verwendet werden für Verkaufsstellen-Zahlungen, entfernte mobile Zahlungen und/oder webbasierte Zahlungen und kann Authentifizierungsmittel wie beispielsweise Offline-PINs, SecureCode PINs und/oder Online-PINs verwenden.

Weiterer Stand der Technik findet sich in Erika Chin et al.„Analyzing inter-application communication in Android", MOBISYS, 11, ACM, US, 28. Juni 2011 (2011-06-28), Seiten 239-252, XP058004575, DOI: 10.1 145/1999995.2000018 ISBN: 978-1-4503-0643- 0.

Vorteile gegenüber dem Stand der Technik Das klassische elektronische Wallet funktioniert nur im Nahbereich einer Akzeptanzstelle mittels drahtloser Funkkommunikation (z.B. NFC-Funktechnologie). Immer mehr Menschen verwenden jedoch ihr mobiles Endgerät, um Transaktionen im Internet durchzuführen. Hier handelt es sich beispielsweise um: (i) Online-Bezahlung von digitalen Gütern (z.B. MP3 -Download),

(ii) Login in Web Sites (z.B. soziale Netze),

(iii) In-app-Bezahlung von digitalen Gütern (z.B. Erwerb von virtuellen Spielgegenständen in Spiele-Apps), (iv) Eingabe von persönlichen Daten in mobile Apps.

Es besteht also Bedarf für ein elektronisches Wallet, das die Durchführung von Transaktionen im Internet ermöglicht. Aufgabe der vorliegenden Erfindung ist es daher, ein elektronisches Wallet bereitzustellen, das die Durchführung von Transaktionen im Internet ermöglicht. Diese Aufgabe wird durch das Verfahren und das System zur endgerätebasierten Kommunikation zwischen einer Fremdanwendung und einem elektronischen Wallet gemäß den Patentansprüchen erreicht.

Ein Aspekt der Erfindung betrifft ein Verfahren zur endgerätebasierten Kommunikation zwischen einer Fremdanwendung und einem elektronischen Wallet. Dabei ist das elektronische Wallet auf einem Endgerät installiert, und die Fremdanwendung ist auf dem Endgerät installiert ist. Das Verfahren weist folgende Schritte auf:

(a) Aufbauen einer Verbindung zu einem Internetservice durch die Fremdanwendung,

wobei die Verbindung eine Übertragung von Daten an den Internetservice erfordert; (b) Empfangen einer auf die Übertragung der genannten Daten gerichteten Anfrage des Internetservices durch die Fremdanwendung;

(c) Weiterleiten der in Schritt (b) vom Internetservice empfangenen Anfrage an das elektronische Wallet durch die Fremdanwendung;

(d) Verarbeiten der Anfrage und Generieren einer entsprechenden Antwort durch das elektronische Wallet;

(e) Weiterleiten der Antwort vom elektronischen Wallet an den Internetservice;

(f) Empfangen einer Bestätigung über die erfolgte Weiterleitung der Antwort an den Internetservice gemäß Schritt (e), wobei das Empfangen durch die Fremdanwendung erfolgt. Dabei kann die Antwort, die entsprechend der Anfrage bezüglich der Übertragung der genannten Daten generiert wird, alle angefragten Daten, einen Teil der angefragten Daten oder keine der angefragten Daten (letzteres entspricht einer Verweigerung der Datenübertragung) aufweisen, wobei die Antwort die Daten in verschlüsselter und/oder unverschlüsselter Form aufweisen kann.

In einer Ausführungsform des Verfahrens ist ein Sicherheitselement mit dem Endgerät verbunden; und Schritt (d) des Verarbeitens der Anfrage und Generierens einer Antwort weist die Schritte auf:

Senden einer Anfrage bezüglich der genannten Daten an das Sicherheitselement durch das elektronische Wallet;

Empfangen einer Antwort bezüglich der genannten Daten vom Sicherheitselement durch das elektronische Wallet;

und wobei vorzugsweise das Sicherheitselement für die drahtlose

Funkkommunikation, beispielsweise funkbasierte Nahbereichskommunikation (NFC), konfiguriert ist.

In einer bevorzugten Ausführungsform des Verfahrens ist das Sicherheitselement eine Universelle Karte mit integriertem Schaltkreis (Universal Integrated Circuit Card, UICC) oder eine SIM-Karte.

In einer alternativen Ausführungsform des Verfahrens weist Schritt (d) des Verarbeitens der Anfrage und Generierens einer Antwort die Schritte auf:

Senden einer Anfrage bezüglich der genannten Daten an eine App, beispielsweise eine weitere Fremdanwendung, durch das elektronische Wallet;

Empfangen einer Antwort bezüglich der genannten Daten von der App durch das elektronische Wallet. In einer bevorzugten Ausführungsform des Verfahrens ist das Endgerät zur Mobilfunkkommunikation geeignet; das Endgerät kann beispielsweise ein Mobilfunkgerät oder ein Smartphone sein und/oder zur WLAN-Kommunikation geeignet sein. Bei dem Endgerät kann es sich beispielsweise auch um einen Laptop/ein Notebook oder einen Tablet Computer handeln.

In einer Ausführungsform des Verfahrens weisen die Daten vertrauliche und/oder nutzerspezifische Informationen auf. Beispielsweise können die Daten Informationen zur Authentisierung aufweisen. Insbesondere können die Daten Informationen für ein Login oder für einen Bezahlvorgang aufweisen. Die Daten können ferner persönliche Daten aufweisen. In einer Ausführungsform des Verfahrens weist Schritt (e) des Weiterleitens der Daten die folgenden Schritte auf:

Übermitteln der Daten vom elektronischen Wallet an ein Wallet Backend;

Herstellen einer Verbindung zwischen dem Wallet Backend und dem Internetservice;

Übermitteln der Daten vom Wallet Backend an den Internetservice.

In einer alternativen Ausführungsform des Verfahrens weist Schritt (e) des Weiterleitens der Daten die folgenden Schritte aufweist:

Übermitteln der Daten vom elektronischen Wallet an die Fremdanwendung;

Übermitteln der Daten von der Fremdanwendung an den Internetservice.

In einer Ausführungsform des Verfahrens ist die Fremdanwendung eine auf dem Endgerät installierte Dienstanbieter-Anwendung, die für die Nutzung des Internetdienstes konfiguriert ist.

In einer Ausführungsform des Verfahrens ist die Fremdanwendung ein auf dem Endgerät installierter Internet-Browser.

Ein Aspekt der Erfindung betrifft ein System zur endgerätebasierten Kommunikation zwischen ein oder mehreren Fremdanwendung(en) und einem elektronischen Wallet. Dabei weist das System ein Endgerät auf. Das System ist dadurch gekennzeichnet, dass auf dem Endgerät ein elektronisches Wallet installiert ist und auf dem Endgerät eine oder mehrere Fremdanwendung(en) installiert sind. Dabei sind die Fremdanwendung(en) jeweils konfiguriert: zum Aufbauen einer Verbindung zu einem Internetservice, wobei die Verbindung eine Übertragung von Daten an den Internetservice erfordert; zum Empfangen einer auf die Übertragung der Daten gerichteten Anfrage des Internetservices; und zum Weiterleiten der vom Internetservice empfangenen Anfrage an das elektronische Wallet. Das elektronische Wallet ist konfiguriert: zum Verarbeiten der genannten Anfrage und Generieren einer entsprechenden Antwort; zum Weiterleiten der Antwort an den Internetservice. Ferner sind die Fremdanwendung(en) jeweils konfiguriert zum: Empfangen einer Bestätigung über eine erfolgte Weiterleitung an den Internetservice, wobei das Empfangen durch die Fremdanwendung erfolgt.

Dabei kann die Antwort, die entsprechend der Anfrage bezüglich der Übertragung der genannten Daten generiert wird, alle angefragten Daten, einen Teil der angefragten Daten oder keine der angefragten Daten (letzteres entspricht einer Verweigerung der Datenübertragung) aufweisen, wobei die Antwort die Daten in verschlüsselter und/oder unverschlüsselter Form aufweisen kann.

In einer Ausführungsform des Systems ist das Endgerät konfiguriert zur Aufnahme eines oder mehrerer Sicherheitselemente, wobei auf dem Endgerät eine oder mehrere Programmierschnittstelle(n) (APIs) zum Auflisten, Auswählen und Interagieren mit den Sicherheitselementen installiert sind. Das System weist ferner ein oder mehrere Sicherheitselement(e) auf, die in das Endgerät aufgenommen sind, wobei das Endgerät mit dem einen oder den mehreren Sicherheitselement(en) verbunden ist. Ferner ist das elektronische Wallet in Bezug auf das Verarbeiten der genannten Anfrage und das Generieren einer entsprechenden Antwort konfiguriert: zum Senden von Anfragen bezüglich der genannten Daten an das eine oder die mehreren Sicherheitselement(e); zum Empfangen von Antworten bezüglich der genannten Daten von dem oder von den Sicherheitselement(en).

Dabei ist das Sicherheitselement vorzugsweise für die drahtlose Funkkommunikation, beispielsweise funkbasierte Nahbereichskommunikation (NFC), konfiguriert. In einer bevorzugten Ausführungsform des Systems ist das Sicherheitselement eine Universelle Karte mit integriertem Schaltkreis (Universal Integrated Circuit Card, UICC) oder eine SIM-Karte. In einer alternativen Ausführungsform des Systems ist das elektronische Wallet in Bezug auf das Verarbeiten der genannten Anfrage und das Generieren einer entsprechenden Antwort ferner konfiguriert: zum Senden einer Anfrage bezüglich der genannten Daten an eine App, beispielsweise eine weitere Fremdanwendung; und zum Empfangen einer Antwort bezüglich der genannten Daten von der App.

In einer bevorzugten Ausführungsform des Systems ist das Endgerät zur Mobilfunkkommunikation geeignet; das Endgerät kann beispielsweise ein Mobilfunkgerät oder ein Smartphone sein, und/oder zur WLAN-Kommunikation geeignet sein. Bei dem Endgerät kann es sich beispielsweise auch um einen Laptop/ein Notebook oder einen Tablet Computer handeln.

In einer Ausführungsform des Systems weisen die Daten vertrauliche und/oder nutzerspezifische Informationen auf Beispielsweise können die Daten Informationen zur Authentisierung aufweisen. Insbesondere können die Daten Informationen für ein Login oder für einen Bezahlvorgang aufweisen. Die Daten können ferner persönliche Daten aufweisen.

In einer Ausführungsform des Systems ist das elektronische Wallet in Bezug auf das Weiterleiten der Antwort an den Internetservice konfiguriert: zum Übermitteln der Daten an ein Wallet Backend. Ferner ist dabei das Wallet Backend konfiguriert: zum Herstellen einer Verbindung zwischen dem Wallet Backend und dem Internetservice; und zum Übermitteln der Daten an den Internetservice.

In einer alternativen Ausführungsform des Systems ist das elektronische Wallet in Bezug auf das Weiterleiten der Antwort an den Internetservice konfiguriert: zum Übermitteln der Daten an die Fremdanwendung(en). Ferner sind dabei die Fremdanwendung(en) jeweils konfiguriert zum Übermitteln der Daten an den Internetservice. In einer Ausführungsform des Systems ist die Fremdanwendung eine auf dem Endgerät installierte Dienstanbieter-Anwendung, die für die Nutzung des Internetdienstes konfiguriert ist In einer Ausführungsform des Systems ist die Fremdanwendung ein auf dem Endgerät installierter Internet-Browser.

Die vorliegende Erfindung zeigt, wie das elektronische Wallet vermittels On-device-APIs derart erweitert werden kann, dass die Durchführung von Transaktionen im Internet ermöglicht wird, und so insbesondere auch die oben unter den Punkten (i) bis (iv) beschriebenen Szenarien zentral durch das elektronische Wallet unterstützt werden können (siehe Fig. 1).

Insbesondere ergeben sich aus der im Folgenden im Detail beschriebenen Erfindung folgende Vorteile:

• Der Nutzer benötigt mit dem Wallet nur eine Anlaufstelle, um sämtliche Bezahlverfahren zu konfigurieren und zurückliegende Bezahltransaktionen einsehen zu können.

• Persönliche Daten und Login-Daten für verschiedene Dienste können komfortabel an einer zentralen Stelle abgelegt werden.

• Der Nutzer muss nicht mehr verschiedenen Apps auf seinem Endgerät Vertrauen in Bezug auf die Speicherung sicherheitsrelevanter oder persönlicher Daten entgegenbringen.

• Das elektronische Wallet wird bereits für den Einsatz im Nahbereich über drahtlose Funkkommunikation (wie beispielsweise NFC) als sichere Anwendung auf dem Endgerät konzipiert. Diese Infrastruktur kann für die Speicherung aller sicherheits- oder datenschutzrelevanten persönlichen Daten wiederverwendet werden.

• Insbesondere kann die Smartcard-Funktion des Sicherheitselements (Secure Element), beispielsweise der UICC, für beliebige Anwendungen nutzbar gemacht werden. Die Erfindung wird nachstehend anhand von Beispielen und der Zeichnung erläutert.

Es zeigen:

Figur 1 : Nutzung von Wallet-Funktionen durch Fremdanwendungen (Drittanbieter- Apps);

Figur 2: Ablauf der Verwendung von On-device-APIs;

Figur 3: eine Übersicht über das erfindungsgemäße System;

Figur 4: ein (NFC) Ecosystem mit On Device API;

Figur 5: Nutzerbedienung 1 : der Nutzer wählt Gutscheine in der App einer dritten Partei und bezahlt mittels Wallet;

Figur 6: Nutzerbedienung 2: der Nutzer wählt Gutscheine in der App einer dritten Partei mittels Wallet;

Figur 7: Eine Ansicht der Komponenten der On-Device-API;

Figur 8: Zeigt Abhängigkeiten zwischen dem Wallet und einer App einer dritten Partei; Figur 9: Ein Ablaufdiagramm des Anonymprofils;

Figur 10: Ein Ablaufdiagramm des Minimalschutzprofils;

Figur 11 : Ein Ablaufdiagramm des Schutzprofils mit hohem Schutz.

Wirkungsweise der Erfindung

Voraussetzungen:

1) Der Nutzer verfügt über ein Mobiltelefon oder anderes Endgerät, das ein oder mehrere Sicherheitselemente aufnehmen kann.

2) Es existieren APIs auf dem Endgerät, um Sicherheitselemente aufzulisten, auszuwählen und mit APDU-Befehlen anzusprechen.

3) Die Plattform erlaubt eine Verzahnung von separat installierten Apps über entsprechende plattform-spezifische Mechanismen - die so genannten„On-device- APIs" oder„Wallet-APIs".

Beschreibung des Verfahrens: Das erfindungsgemäße Verfahren basiert darauf, Programmierschnittstellen zwischen beliebigen Fremdanwendungen (Drittanbieter- Apps) auf dem Endgerät und dem Wallet auf dem Endgerät zu schaffen, um eine Nutzung der Funktionen des elektronischen Wallets durch diese Fremdanwendungen zu schaffen.

Die Nutzung der On-device-APIs des Wallets bettet sich in folgenden Ablauf ein (vgl. Fig. 2, die Nummerierung der Schritte in folgendem Beispiel entspricht nicht den Bezeichnungen der Schritte im Anspruchssatz):

• Die Fremdanwendung auf dem Endgerät verbindet sich zu einem Service im Internet (Internetservice), der eine Authentisierung zwecks Login oder Payment bzw. die Übertragung persönlicher Daten erfordert (Schritt 1).

• Die Fremdanwendung erhält Daten zur Übermittlung an das Wallet vom Internet- Service (Schritt 2).

• Die Fremdanwendung leitet diese Daten an das Wallet weiter (Schritt 3).

• Das Wallet nutzt gegebenenfalls Authentisierungsdienste des Sicherheitselements, z.b. der UICC (Schritt 4 und 5).

Variante A:

o Das Wallet leitet die Authentisierungsinformation an ein Wallet Backend weiter (Schritt 6A). o Das Wallet Backend kontaktiert den Service im Internet zwecks Weiterleitung der vom Wallet bearbeiteten Authentisierungsinformation (Schritt 7A)

Variante B:

o Das Wallet leitet die Authentisierungsinformation an die Fremdanwendung weiter (Schritt 6B).

o Die Fremdanwendung leitet die Authentisierungsinformation an den Service im Internet weiter (Schritt 7B).

Die Fremdanwendung erfährt von der erfolgreichen Authentisierung vom Internetservice (Schritt 8). Die On-device-APIs werden hier insbesondere in den Schritten 3 und 6B verwendet. Einige dieser Schritte sind je nach konkretem Anwendungsszenario optional.

Beispielsweise ist die Einbindung der Sicherheitsfunktion optional. So haben nicht alle Endgeräte die Möglichkeit des Zugriffs auf ein Sicherheitselement. Die Erfindung ermöglicht aber auch auf solcherart eingeschränkten Plattformen den Einsatz von Wallet- Diensten mit reichhaltiger Funktionalität. Das Wallet kann etwa Bezahlfunktionen bündeln und in diesem Falle ein „Routing" von einer Fremdanwendung, die eine Bezahlung benötigt, hin zu einem als App realisierten Bezahlinstrument im Wallet (z.B. einer speziellen Kreditkarte und nicht der ebenfalls vorhandenen EC-Karte) durchführen. Anstatt der Verwendung von Sicherheitsfunktionen eines Sicherheitselements kann diese Bezahl- App andere Mechanismen zur Absicherung der Transaktion verwenden.

Das bei der Variante A in obigem Beispiel verwendete Wallet Backend befindet sich auf einem Server des Wallet-Betreibers und wird wiederum vom Endgerät über eine Internet- Verbindung angesprochen. Hintergrund ist, dem Internetservice über eine Merchant- Schnittstelle die korrekte Durchfuhrung der Bezahlung mitzuteilen, wenn der Kommunikationsfluss über die Schritte 6A und 7A verwendet werden soll.

Beispielhaft können die folgenden On-device-APIs (Wallet-APIs) nach diesem Schema implementiert und in Schritt 3 an das Wallet angebunden werden. Dabei kommen Interprocess-Kommunikationsmechanismen der Plattform zur Anwendung (z.B. Intents auf Android-Plattformen):

• In-app purchase: Die Fremdanwendung initiiert einen Bezahlvorgang zur Auslieferung digitaler Güter von einem Server im Internet. An das Wallet wird eine Information über die Art der Güter sowie der Preis weitergegeben.

• In-app authentication: Die Fremdanwendung initiiert ein Login zu einem Server im Internet (z.B. zum Zugriff auf Cloud-Daten). An das Wallet wird eine Information über die Art des Logins weitergegeben. • Konfiguration persönlicher Daten für soziales Netzwerk: Die App eines sozialen Netzes meldet sich an ein soziales Netz im Internet an und leitet die Anfrage nach persönlichen Daten an das Wallet weiter. Das Wallet liefert nach Rückfrage beim Nutzer die persönlichen Daten zurück. Gegebenenfalls werden Daten digital signiert ausgeliefert, wobei ein Applet auf dem Sicherheitselement, etwa einer

UICC, zur Anwendung kommt (z.B. Altersverifikation).

Viele weitere On-device-APIs sind denkbar. Insbesondere können die Szenarien des„in- app purchase" sowie der „in-app authentication" leicht auf einen Web Browser (beispielsweise den mobilen Web Browser auf einem Smartphone) anstatt der Fremdanwendung ausgeweitet werden. In diesem wird für die On-Device-API der URL- Mechanismus der Plattform verwendet, d.h. über bestimmte Wallet-URLs kann der Internetservice mittels des Web Browsers die Wallet App direkt ansprechen. Im Folgenden werden weitere die On-Device-API betreffende Beispiele gemäß der Erfindung im Zusammenhang mit Gutscheinabwicklungs- und Treueszenarien gegeben. Während die API nicht auf eine gewisse Klasse beschränkt ist, kann jedes zusätzliche Szenario unterstützt werden. Definition und Bereich der Treue/der Gutscheinabwicklung

Treue: Treue bezieht sich auf ein auf Punktesammeln konzentriertes Bonusprogramm, das auf einen oder mehrere Händler abzielt. Hier bekommt der Nutzer eine gewisse Menge an Punkten, die basierend auf einer Logik berechnet werden, die der Anbieter des Treuemodells definiert. Daher leitet der Nutzer jedes Mal, wenn er einen Kauf tätigt, seine Kundentreuekennnummer über den NFC/QR an das POS-System weiter, welches die Bonuspunkte berechnet und sie zu dem Kontostand des Nutzers addiert. Diese Treueart ist POS-IT-Backend-konzentriert, d.h. das Wallet ist nur für das Speichern und Weiterleiten der Treuekennung des Nutzers verantwortlich. Die Treuebonuspunkteverarbeitung und Verwaltung wird über das POS-System und die IT des Treue-Providers erledigt.

Gutscheinabwicklung: Gutscheine ermöglichen bestimmten Nutzergruppen, Rabatte oder andere Vorteile zu beziehen, wenn sie einen Kauf tätigen. Gutscheine können einen Rabatt (relativ oder absolut) auf den gesamten Warenkorb oder auf fest zugeordnete Produkte geben. Gewisse Gutscheine können auch Bedingungen haben, die von dem Nutzer erfüllt werden müssen, um den bestimmten Gutschein einzulösen (zum Beispiel bezahle für eins, bekomme zwei). Die Abrechnung von Gutscheinen wird von dem POS-System erledigt. Die Motivation des Ausstellers des Gutscheins ist, das Verhalten des Nutzers zu lenken, indem ein Anreiz für gewisse Produkte oder Kaufmuster geschaffen wird. Gutscheine sind im Allgemeinen dafür gedacht, nur einmal verwendet zu werden. Daher muss jeder verwendete Gutschein entwertet werden. User Journeys

Im Folgenden werden Beispiele dafür gegeben, wie der Nutzer das elektronische Wallet gemäß der Erfindung verwenden kann ("User Journeys"). Der aktuelle Bereich des elektronischen Wallet (z.B. mWallet) On-Device-API ermöglicht zum Beispiel, dass der Nutzer zwei User Journeys folgt. Der Fokus der Journey liegt auf demGutscheinabwicklungs-Szenario, sie kann aber in der gleichen Weise auch auf Treue- und andere Karten angewendet werden. Bezug nehmend auf Fig. 5 wird eine Journey beschrieben, wobei der Nutzer in der App einer dritten Partei Gutscheine auswählt und mit dem Wallet bezahlt:

Schritt eins: Der Nutzer kann in der App der dritten Partei Gutscheine für die Wallet- Verwendung vorauswählen und auf den "Pay with Wallet" -Button klicken, um zu der weiteren Bezahlung mit dem Wallet weiterzugehen (Fig. 5a).

Schritt zwei: Das Wallet erscheint und muss von dem Nutzer mit dem Wallet-PIN geöffnet werden. Nach der erfolgreichen Authentifizierung wird der Gutschein-Dialog gezeigt (Fig. 5b).

Schritt drei: Es steht dem Nutzer frei, zusätzliche Gutscheine oder Bezahlkarten zu wählen, bevor er den Bezahlvorgang startet. Gutscheine können aus verschiedenen Apps dritter Parteien ausgewählt werden (Fig. 5c). Schritt vier: Wenn der Nutzer die Kartenauswahl beendet hat, kann die Bezahlung durch Klicken auf den "Send" -Button gestartet werden (Fig. 5d). Schritt fünf: Es wird ein Überblick aller ausgewählter Karten I angezeigt, während der Nutzer aufgefordert wird, das Mobiltelefon an das NFC-Endgerät anzustecken. Alternativ kann der Nutzer aufgefordert werden, einen Satz von QR-Codes an dem POS zu scannen (Fig. 5e). Nun Bezug nehmend auf Fig. 6 wird eine alternative Journey beschrieben, in der der Nutzer Gutscheine von dritten Parteien mit dem Wallet auswählt:

Schritt eins: Aus der Gutscheinauswahl ansieht des Wallet kann der Nutzer eine registrierte App einer dritten Partei für die Gutscheinauswahl starten (Fig. 6a).

Schritt zwei: In der Anwendung der dritten Partei können Gutscheine ausgewählt werden. Durch Klicken auf den "Pay with Wallet" -Button wird der Nutzer zu dem Wallet zurück geführt und sieht eine aktualisierte Ansicht aller ausgewählten Gutscheine (Fig. 6b). Schritt drei: Dem Nutzer steht es frei, durch Auswählen aus dem ihm gehörenden Wallet oder aus Gutscheinen dritter Parteien zusätzliche Gutscheine auszuwählen. Die Liste mit Gutscheinen dritter Parteien kann nach einigen Kriterien gefiltert werden, die von der Anwendung der dritten Partei definiert werden (Fig. 6c). Schritt vier: Wenn der Nutzer die Kartenauswahl beendet hat, kann die Bezahlung durch Klicken des "Send"-Button gestartet werden (Fig. 6d).

Schritt fünf: Es wird ein Überblick aller ausgewählten Karten I angezeigt, während der Nutzer aufgefordert wird, das mobile Endgerät an das NFC-Endgerät anzustecken. Alternativ kann der Nutzer aufgefordert werden, einen Satz von QR-Codes an dem POS zu scannen (Fig. 6e).

Use Cases Die On-Device API ermöglicht die folgenden Anwendungsfälle, die von den vorstehenden User Journeys bereits umrissen wurden: Use Case 1 (Item Provider registrieren): Der Eintrittspunkt für Apps dritter Parteien als Item Provider zur Nutzung der On-Device API ist ein einleitender Login- Anruf. Das Item Provider-Login setzt das Wallet über die Existenz der IP-App auf dem Mobilgerät in Kenntnis und ermöglicht von dem Item Provider unterstützte On-Device-Merkmale. Vorzugsweise ist der Use Case 1 obligatorisch.

Use Case 2 (Items anzeigen): Nach dem Hochfahren der Elektronik fragt das Wallet (z.B. mWallet) alle registrierten Item Provider nach verfügbaren Items ab. Es liegt an dem IP, zu entscheiden, welche Items dem elektronischen Wallet (z.B. mWallet) zurück geliefert werden. Abhängig von der Anwendung können diese vom Nutzer vorausgewählte Items, interessierende Items oder alle verfügbaren Items sein. Items aller Provider werden dem Nutzer in einer Listenansicht für die Item-Nutzung und Auswahl für eine zusätzliche Detailansicht angezeigt. Das Wallet macht sich nicht zueigen, diese Items zu speichern und hält nur vorübergehende Referenzen auf die Items, die sich in der Item Provider- Anwendung befinden. Vorzugsweise ist der Use Case 2 obligatorisch.

Use Case 3 (Item aus dem Wallet verwenden): Abhängig von dem Item -Nutzungsszenario (Bezahlung, Zugangsschlüssel) kann der Nutzer entweder ein oder mehrere Items aus verschiedenen Domains für eine Transaktion auswählen. Daneben schreibt der Transportkanal (NFC, QR, HTTP) vor, ob der Nutzer die Daten des Item der interagierenden Partei sequentiell angeben muss oder ob alle Item-Daten in einer Nutzerinteraktion übermittelt werden können. Wenn er das Wallet verwendet, soll der Nutzer jedoch fähig sein, ein oder mehrere Items auszuwählen, bevor er die Transaktion startet. Zum Beispiel werden an einem NFC-Point of Sale - Tokens für die ausgewählten Items bei dem Item Provider angefordert oder ein entsprechendes Cardlet wird aktiviert. Falls die Verwendung eines Spezifikums Token-basiert ist, muss der Item Provider das angeforderte Token an das elektronische Wallet (z.B. mWallet) zurück geben. Vorzugsweise ist der Use Case 3 obligatorisch. Use Case 4 (Item von Item Provider verwenden): Der Item Provider kann das elektronische Wallet (z.B. mWallet) öffnen, um ein Item durch spezifische Fähigkeiten des elektronischen Wallet (z.B. mWallet), wie NFC, QR-Code oder HTTP, zu verwenden. Use Case 5 (Nutzung melden): Im Fall einer NFC-Transaktion kennt das Wallet den abschließenden Transaktionsstatus und wird dem Item Provider die Item-Nutzung melden. Abhängig von dem Vertrag zwischen dem NFC-lnteraktionspunkt und dem Item Provider können zusätzliche item-spezifische Daten an den Item Provider weitergeleitet werden. Zum Beispiel können eingelöste Gutscheine entwertet und aus dem mobilen Wallet entfernt werden oder verdiente Treuepunkte können zu dem Treuekonto des Nutzers hinzuaddiert werden. Vorzugsweise ist der Use Case 5 obligatorisch.

Use Case 6 (Item entfernen): In dem Wallet angezeigte Items können von dem Nutzer entfernt oder gelöscht werden. Der verantwortliche Item Provider wird über diese Aktion benachrichtigt und soll das Item aus der Item-Liste, die dem Wallet bereitgestellt wird, entfernen. Es liegt an dem Provider, zusätzliche Aktionen, wie etwa das physische Löschen aus dem lokalen Speicher oder in dem Backend des Providers durchzuführen. Vorzugsweise ist der Use Case 5 optional. Use Case 7 (Item importieren): Ein Item, das zum Beispiel an einem Point of Sale ausgegeben wird und von dem mWallet über eine NFC oder das Scannen eines QR-Codes abgerufen wird, wird von dem elektronischen Wallet (z.B. mWallet) für den Import an die entsprechenden Item Provider- Anwendung weitergegeben. Use Case 8 (Default Item festlegen/Festlegung aufheben): Items können in dem elektronischen Wallet (z.B. mWallet) als Default Item markiert werden. Das Default Item (eines pro Domain) wird ohne explizite Auswahl als Voreinstellung verwendet. Dem Item Provider wird gemeldet, wenn ein Item als Default festgelegt oder seine Festlegung aufgehoben wird. Es liegt an dem IP, jegliche Aktionen, wie etwa das Aktivieren oder Deaktivieren eines entsprechenden cardlet durchzuführen.

Use Case 9 (Item aufrufen): Das elektronische Wallet (z.B. mWallet) kann dynamische Item-Daten von dem Item-Provider anfordern, die verwendet werden, um Item-Details anzuzeigen. Zum Beispiel kann dies die tatsächliche Anzahl von Treuepunkten, der Name des Besitzers oder der Kontostand sein. Falls das Item HTML spezifischen JavaScript- Code umfasst, wird das Wallet Item-spezifische dynamische Daten bei dem Item Provider abfragen.

Use Case 10 (Katalog starten): Um zu dem elektronischen Wallet (z.B. mWallet) zusätzliche Items hinzuzufügen, kann der Item Provider einen Katalog bereitstellen, aus dem der Nutzer zusätzliche Items auswählen kann. Diese können zum Beispiel als 'soll dem Wallet bereitgestellt werden" festgestellt werden oder online abgerufen werden und physisch in den Data Store des Providers importiert werden.

Allgemeine Anforderungen

Im Folgenden werden allgemeine Anforderungen für die On-Device-API aufgelistet:

• Die Registrierung eines Item Providers erfordert die Berechtigung. Die meisten Interaktionen werden von dem elektronischen Wallet (z.B. mWallet) gestartet. Für diese ist keine zusätzliche Zugangssteuerung außer der Registrierung erforderlich. Nur für Interaktionen, die von dem Item Provider gestartet werden, sind das Aufrufen der Funktionalität des elektronischen Wallet (z.B. mWallet) zusätzliche

Genehmigungen erforderlich und werden von dem elektronischen Wallet (z.B. mWallet) erzwungen. Vorzugsweise ist diese Anforderung obligatorisch.

Entwickler, die die gesamte On-Device API nutzen möchten, sollten sich registrieren, um eine Form von Berechtigungsnachweis (Passwort, Anwendungsschlüssel, oder Entwicklerzertifikat, etc.) zu erhalten. Diese Daten müssen von ihren Apps verwendet werden, um die Registrierung/ Authentifizierung auf dem Device gegen das elektronische Wallet (z.B. mWallet) durchzuführen. Vorzugsweise ist diese Anforderung obligatorisch.

Es wird erwartet, dass die UICC als ein Sicherheitsanker verwendet werden kann (Voraussetzung: OTA-Kanal verfügbar). Vorzugsweise ist diese Anforderung optional.

• In dem Fall, dass heikle Daten (z.B. Prepaid-Beleg) zwischen dem Wallet und dem Item Provider übertragen werden, sollte der Kommunikationskanal in einer annehmbaren Weise geschützt werden. Vorzugsweise ist diese Anforderung optional.

On-Device API- Spezifikation Das elektronische Wallet (z.B. mWallet) On-Device-API erlaubt Anwendungen dritter Parteien - sogenannter Item Provider (IP) - von der Wallet-Funktionalität zu profitieren. Zum Beispiel lässt es zu, dass Items in verschiedenen Transaktionen aufgerufen werden.

Die On-Device API zielt auf mehrere funktionale Wallet-Komponenten ab, was zwei Schnittstellen ergibt, die nachstehend im Detail beschrieben werden.

• Wallet-Schnittstelle: Wallet-Transaktionen, Item Provider-Registrierung, Bezahlung und IdM;

• Item Provider-Schnittstelle: Wallet API mit Item- Verwaltungsfunktionalität.

In Fig. 7 sind Beziehungen zwischen Komponenten und den bereitgestellten und verwendeten Schnittstellen bereitgestellt. Zudem werden beispielhaft weitere Elemente eines kompletten Wallet-Ökosystems auf UICC- und Backend-Seite dargestellt. Auf dem Endgerät gibt es zunächst die Wallet App, die das Wallet Interface anbietet, das Drittawendungen auf dem Endgerät zur Kommunikation mit den Wallet nutzen können. Exemplarisch sind hier zwei Drittanwendungen aus den Bereichen Couponing und Loyalty dargestellt, die diese Schnittstelle nutzen. Desweiteren sind illustrativ zwei Applets auf der UICC bzw. dem Secure Element dargestellt, die vom Wallet verwaltet werden. Im Backend-Bereich werden zudem die Backend- Systeme sowohl des Wallets als auch der Drittanwendungen dargestellt, die über das Internet mit den entsprechend Client- Anwendungen auf dem Endgerät kommunizieren.

Plattformunabhängige Schnittsteilenspezifikation Die im Folgenden definierte On-Device-API ist eine abstrakte API, die auf mobile Plattformen, wie Android oder Windows 8 abgebildet werden kann, solange die mobile Plattform einen IPC-Mechanismus zwischen Apps bereitstellt, was keine Nutzerinteraktion vorschreibt. Im Folgenden werden die plattformspezifischen Implementierungsthemen behandelt.

Wallet-Schnittstelle

Die Wallet-Schnittstelle enthält alle Operationen, die von Item Providern aufgerufen werden.

Andernfalls kennt das AccessToken: Token,

Wallet den IP nicht und das geprüft werden soll,

wird keine Items von der ob Item Provider die

IP App abfragen und alle Erlaubnis hat, diese

Operationsaufrufe von Operation aufzurufen.

ihr ablehnen.

Tabelle 1: Wallet-Schnittstelle

Item Provider-Schnittstelle Die folgende Tabelle listet Operationen auf, die von der Item Provider App implementiert werden und von dem Wallet, wenn verfügbar, aufgerufen werden sollen.

UC 6 removeItem() Itemld StatusCode

Ein Item aus dem Wallet Itemld: IP-spezifische

entfernen. Der Item Kennung des Item, das

Provider soll dieses Item entfernt werden soll.

mit dem nächsten

getItems()-Aufruf nicht

mehr bereitstellen. Ob

das Item auf der IP-Seite

gelöscht wird, ist

außerhalb des

Betrachtungsbereichs.

UC 7 importItem() ItemData StatusCode

Dem Item Provider ItemData: IP- anraten, ein neues Item spezifische Kennung

zu importieren, das das des Default Item.

Wallet durch

Eingangskanäle, wie

NFC oder QR-Code

empfangen hat.

UC 8 setDefaultO Itemld StatusCode

Markieren eines Item als Itemld: IP-spezifische

das Default Item dieser Kennung des Default

Domain. Diese Item.

Information ist

hauptsächlich für das

Wallet relevant, aber der

IP soll über den Default- Zustand benachrichtigt

werden. Auf diese Weise

können zusätzliche

Maßnahmen ergriffen

werden.

UC 8 unsetDefault() Itemld StatusCode

Default-Markierung Itemld: IP-spezifische

eines Item entfernen. Kennung des Default

Diese Information ist Item.

hauptsächlich für das

Wallet relevant, aber der

IP soll über den Default- Zustand benachrichtigt

werden. Auf diese Weise

können zusätzliche

Maßnahmen ergriffen

werden.

UC 9 invokeItem() Itemld, InvokationPara InvokationPara

Aktuelle Metadaten für Itemld: IP-spezifische

ein Item bekommen. Kennung des Item, das

Dies kann der aktuelle aufgerufen werden soll.

Kontostand einer

InvokationParameter:

Bezahlkarte sein.

undurchsichtige Daten

von JavaScript, die an

den Item Provider

weitergeleitet und von

ihm interpretiert werden

sollen.

12 UC 10 launchCatalogue() Domain StatusCode

Starten eines Item- Domain: Die Domain

Katalogs der Item von interessierenden

Provider App. Der Items.

Nutzer kann mehrere

Items auswählen, die

dem Wallet bereitgestellt

werden sollen.

Tabelle 2: Dienstanbieterschnittstelle

Datentypspezifikation Primitive Datentypen

Primitive Datentypen sind grundlegende Datentypen, wie string, integer oder arrays, die beschränkte Wertebereiche wie Aufzählungen haben. Die On-Device-API verwendet die folgenden primitiven Typen:

Name Typ Beschreibung

StatusCode Integer Satz fester Statuscodes. 0 für Erfolg.

Itemld String Item Provider- spezifische Kennung eines

Item.

Token Bytef] Undurchsichtige Item-Daten von dem Item

Provider. Diese Daten können GS1- Codierung oder etwas anders sein. Syntax und Semantik müssen zwischen dem IP und dem Interaktionspunkt verstanden werden.

UsageData Byte[] Verwendungsstatus eines Item. Syntax und Semantik müssen zwischen dem IP und dem

Interaktionspunkt verstanden werden.

ItemData Byte[] Item Provider-spezifische Darstellung von

Item-Daten.

InvokationPara Byte[] Item Provider-spezifische Darstellung der

Parameter, die aufgerufen werden sollen.

Domain Enum<coupon, Typ eines Item.

loyal ty,...>

Name String Name

Description String Beschreibung

Domains enum[] Satz von domains

Image Byte[] Provider-Bild

Callback String Rückruf-URL an die Item Provider- Implementierung auf dieser On-Device API

Komplexe Datentypen

Komplexe Datentypen sind Zusammengesetze Datentypen, die mehrere Elementattribute enthalten.

Display Token

Das Display Token besteht aus den folgenden Attributen:

Name Typ Beschreibung

Id String IP-eindeutige Item-Kennung

Name String Anzeigename des Item

Domain Integer Domain (Kennung=l/Bezahlung=2/True=3(Ereignis=4/Bewegung=5/

Zugang=6/Gutschein=7)

Type String Typ der Karte

imageUrl URL URL, die auf das anzuzeigende Bild zeigt. Das Bild könnte dynamische

Daten, wie etwa Treuepunkte oder das Gutscheinprodukt oder den Rabatt, enthalten, die dem Benutzer dargestellt werden sollen. Das Attribut ist optional, falls imageEmbedded vorhanden ist.

imageEmbedded Byte[] Base64-codiertes Bild, das angezeigt werden soll. Dieses Attribut ist optional, falls imageUrl vorhanden ist.

shortDescription String HTML-Darstellung der in Listenansichten verwendeten

Kurzbeschreibung

detailedDescription String HTML-Darstellung der detaillierten Beschreibung

Issuer String Aussteller der Karte

timelssued Date-time Optional: Karte ist ab diesem Datum/Zeit gültig timeExpires Date-time Optional: Karte läuft zu diesem Datum/Zeit ab

Implementierung auf Android OS

Die vorstehend definierte plattformunabhängige On-Device API muss für die Inter-App- Kommunikation auf Android-Mechanismen abgebildet werden. Zuerst werden verfügbare Inter-App-Mechanismen eingeführt, die für die API-Abbildung verwendet werden. Anschließend wird die On-Device-API für Android definiert, die für die Implementierung passt. Inter-App-Kommunikation auf Android

Android ist konzipiert, um eine Vielfalt an Anwendungen zu hosten und die Nutzerauswahl zu maximieren. Die Plattform ist dafür gedacht, um die Vervielfältigung der Funktionalität in verschiedenen Anwendungen zu beseitigen, um zu ermöglichen, dass Funktionalität spontan gefunden und aufgerufen wird, und um Nutzer Anwendungen durch andere, die ähnliche Funktionalität bieten, ersetzen zu lassen. Anwendungen müssen so wenige Abhängigkeiten wie möglich haben und müssen fähig sein, Operationen an andere Anwendungen zu vergeben, die sich nach Gutdünken des Nutzers ändern können. Die Interprozess-Kommunikation (IPC) ist folglich die Basis für einige Schlüsselmerkmale des Android-Programmiermodells. Die Technik für die On-Device API relevanten Techniken sind:

Intents

Diese ermöglichen einer Anwendung, eine Aktivität basierend auf der Aktion, die jemand aufrufen möchte, und den Daten, auf denen sie arbeitet, auszuwählen. Mit anderen Worten braucht man keinen hartcodierten Pfad zu einer Anwendung, um ihre Funktionen zu verwenden und Daten damit auszutauschen. Daten können unter Verwendung von "Intenf'-Objekten in beide Richtungen weitergegeben werden, und dies ermöglicht ein praktisches System der Inteiprozess-Kommunikation auf hoher Ebene. Teile der On-device-APIs sollen unter Verwendung von intents implementiert werden Intents können auf verschiedene Weisen gestartet werden.

1. Intents können an jeden Empfänger als Broadcast gesendet werden.

2. Intents können an einen bestimmten Empfänger abgeschickt werden, und Ergebnisse werden ignoriert.

3. Intents können an einen bestimmten Empfänger abgeschickt werden, und der Sender wird über die Ergebnisse benachrichtigt.

In dem Fall der Option 3 kann der Empfänger des Intent Informationen über den Sender finden, indem er Activity.getCallingPackage() aufruft. Aus diesem Grund werden alle Operationen der Wallet- Schnittstelle in einer derartigen Weise auf Android-Intents abgebildet, dass sie ein Ergebnis erwarten:

• Wenn die Funktion ein Ergebnis erwartet, ist dies sowieso der Fall.

• Wenn die Funktion kein Ergebnis erwartet, ist der Android-Intent derart implementiert, dass er ein "in '-Ergebnis erwartet. Der Wert "0" soll keinen Fehler anzeigen. Werte, die größer als "0" sind, sollen einen Fehler anzeigen.

Die meisten, aber nicht alle Operationen der ItemProvider-Schnittstelle sollen auf Android- Intents abgebildet werden. Abhängig davon, ob ein Ergebnis erforderlich ist oder der Anrufe nur weitermachen kann, nachdem die Operation beendet wurde, werden Intents die Start-Option 2 - Activity.startActivity() oder die Start-Option Activity. startActivityForResult() verwenden.

Die Operation für das Abrufen eines Item wird einen anderen effizienteren IPC- Mechanismus verwenden, der von dem Android mit dem Namen ContentProvider bereitgestellt wird.

ContentProvider Content providers verwalten den Zugang zu einem strukturierten Datensatz. Content Providers sind die Standardschnittstelle, die Daten in einem Prozess mit Code, der in einem anderen Prozess läuft, verbindet. Wallet- S chnittstellenabbildung

Alle Operationen, die von der Wallet-Schnittstelle bereitgestellt werden, werden auf den Android intent-Mechanismus abgebildet. Intent-Objekte werden für die Betriebseingabe- und Ausgabeparameter verwendet.

LoginO

Das login intent, das von Item Providers gesendet wird, informiert das elektronische Wallet (z.B. mWallet) über die Existenz des Handgeräts. Neben dem Namen, der Beschreibung und dem Bild des Providers stellt er seine Endpunkt-URI an den ContentProvider zum Abfragen von DisplayTokens und ein Intent-Aktionspräfix, das von dem elektronischen Wallet (z.B. mWallet) verwendet wird, um Intent-basierte Operationen der ItemProvider- Schnittstelle aufzurufen, bereit. Das login intent soll bei zwei Ereignissen gesendet werden:

1. Proaktiv während jedes Item Pro vi der- Anwendungsstarts.

2. Bei Abruf eines register Intent, das von dem elektronischen Wallet (z.B.

mWallet) als Broadcast gesendet wird.

Details dieses Broadcast werden nachstehend als Teil der Item Provider- Schnittstellenabbildung beschrieben.

Der Intent für die Abbildung der login-Operation ist durch folgende Attribute definiert:

Attribut- Name WertBeschreibung

typ typ

Action de.dtag.tlabs.wallet.cards.intent.action.LOGIN Operation, die aufgerufen werden soll

Extra de.dtag.tlabs.wallet.cards.intent.extra.DOMAIN String Unterstützte Domains der

Anwendung, die registriert werden soll (Gutschein=l/Treue=2)

Extra de.dtag.tlabs.wallet.cards.intent.extra.NAME String Name der registrierten App, die dem

Nutzer angezeigt wird

Extra de.dtag.Iabs.wallet.cards.intent.extra.CA D_AUTHORJTY URI Zulässige Quell-URI des Karten- contentProvider

Extra de.dtag.tlabs.walIet.cards.intent.extra.CARD_HANDLER String Intent-Präfix, das von mWallet verwendet wird, um den Aktionsparameter aufzubauen, der mit einem Intent zum Aufrufen von On-Device API-Operationen verwendet werden soll

Extra de.dtag.tlabs.wallet.cards.intent.extra.SHORTDESCRIPTIO String Kurze Beschreibung des Item N Provider Extra de.dtag.tlabs.wallet.cards.intent.extra.DETAILDESCRIPTIO String Detaillierte Beschreibung des Item N Provider

Extra de.dtag.tlabs.wallet.cards.intent.extra.IMAGEURL URL URL zu dem Item Provider-Bild

Extra de.dtag.tlabs.wallet.cards.intent.extra.IMAGEEMBEDDED Byte[] Item Provider-Bild

Extra de.dtag.tlabs.wallet.cards.intent.extra.AUTHOKEN String Authentifizierungs-Token

Extra de.dtag.tlabs.wallet.cards.intent.extra.AUTHOKEN TYPE String Tokentyp ('SHARED KEY') useltem()

Die useltem-Operation kann von der item provider-App aufgerufen werden, um das elektronische Wallet (z.B. mWallet) mit einem vorausgewählten Item zu öffnen, das sofort aufgerufen werden kann.

Der Intent für die Abbildung der use!tem()-Operation ist durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action walletAPI.UseCard Operation, die aufgerufen werden soll

Extra Issuer String Item-Aussteller

Extra Cardld String Item-ID

Extra de.dtag.tlabswallet.cards.intent.extra.CARD AUTHOKEN URI Zugangs-Token

Diese Operation wird mit Activity.startActivityO aufgerufen und gibt kein Ergebnis-Intent zurück.

Item Provider-Registrierung

Bei Abrufen eines register intent, der beim Hochfahren des elektronischen Wallet (z.B. mWallet) als Broadcast an das Android-System gesendet wird, soll die IP- Anwendung den vorstehend definierten Login-Intent an das elektronische Wallet (z.B. mWallet) senden. Für das Abrufen des broadcast intent muss die IP -Anwendung eine Klasse implementieren, die die BroadcastReceiver-Klasse von Android erweitert und die onReceive()-Methode überschreibt. In der Manifestdatei der empfangenden Aktivität muss die Broadcast- Empfänger-Klasse deklariert werden und der Register-Intent muss in dem Intent-Filter definiert werden. android ; na * "de , dtag, t i obs . l Let . opi . cards ,Car ProviderRegi straiion" androie ; enabled= "trm "" >

•"intent ~ filter>

<<i.: t:io!) android iirog, ti ofcs. wai Let . cards , intent . action . REGISTER" />

</ iriteni: - j i iter '

Das mWallet wird die android.content.ContextWreapper.sendBroadcast(Intent intent)- ethode mit den folgenden Intent-Attributen aufrufen:

AttributName Wert Beschreibung

typ

Action de.dtag.tlabs.mwallet.intent.action.REGISTE Operation, die aufgerufen werden soll

Content Provider-Definition

Die meisten Operationen der SP-Schnittstelle sind datenzentriert und können leicht auf SQL-Datenbank-artige Abfragen abgebildet werden. Zu diesem Zweck werden Android Content Providers verwendet, die für die gemeinsame Nutzung von strukturierten Dantesätzen über Anwendungsgrenzen hinweg sorgen.

Für die Android-Plattform werden die Operationen getltems() und getDisplayToken() der IP-Schnittstelle unter Verwendung ContentProvider-Merkmals implementiert. Das Wallet verwendet den ContentProvider-Mechanismus zum Abfragen und Aktualisieren von Daten, die von der IP -App bereitgestellt werden. Die IP-App muss einen ContentProvider implementieren, der den im Folgenden beschriebenen Definitionen entspricht.

Die Manifestdefmitionen des Providers sollen wie folgt sein:

< prfHf ider android ; label= "CatdProvider"

andro L i : u t hör i t i e s = "<YOUR_AUTHOR1TY> "

«sndroid : fidme* CardPtovider"

andro id : r eatlPermi $s i o«="de , dtag . 11obs , «wo t l et . provider, Readcard "/>

Der ContentProvider soll eine Tabelle bereitstellen, die durch die folgenden Attribute adressiert wird: Authortty: content : / / <YOUR_AUTHORITY>

List path: Cards

Item path: Cards /#

Zum Beispiel soll ein einziges Card Item durch die URI zugänglich sein:

content://de.dtag.tlabs.mwallet.provider.cardprovider/Car ds/#<CARD_ID>

Die folgenden Datentypen sollen verwendet werden und auf die CursorWindow-Klasse abgebildet werden:

Typenname Cursortyp- Abbildung

String CursorWindow.putStringO

Integer CursorWindow.putStringO

Short CursorWindow.putStringO

Long CursorWindow.putLongO

Double CursorWindow. put DoubleO

ByteD CursorWindow.putBlobO

Die Item-Tabelle soll die folgende Liste von Spalten bereitstellen, die Attribute des Display Token, wie vorstehend definiert, plus einige Parameter, die zum Abbilden der ΓΡ- Schnittstellenoperationen auf den Android ContentProvider-Mechanismus erforderlich sind, sind.

Name Typ Beschreibung

id Integer Numerische ContentProvider Id

id String Bildet auf Display Token.id ab

issuer String Bildet auf Display Token.id ab

name String Bildet auf Display Token.name ab

domain Short Bildet auf Display Token.domain ab

type String Bildet auf Display Token.type ab

imageUrl String Bildet auf Display Token.imageUrl ab

imageEmbedded Byte[] Bildet auf Display Token. imageEmbedded ab

listDescription String Bildet auf Display Token.short Description ab

detailedDescription String Bildet auf DisplayToken.detailedDescription ab

expiryTime String Bildet auf Display Token.timeExpires ab

Um automatische Aktualisierungen der Ansicht in dem elektronischen Wallet (z.B. mWallet) zu ermöglichen, sollten die Cursor-Instanzen, die von der ContentProvider.query()-Operation zurückgegeben werden, die URI des Providerinhalts mit cursor.setNotificationUri(CONTENT_URI) festgelegt haben. Dies ist eine obligatorische Bedingung für eine spätere Änderungsmeldung, falls der Datensatz geändert wird. Bitte beziehen Sie sich z.B. auf die nachstehend beschriebene removeItem()- Operation. Intent-Abbildung

Die folgenden Operationen der Item Provider-Schnittstellen werden auf Android-Intents abgebildet. Dieser Abschnitt definiert die Intent-Aktion und zusätzliche Attribute für jede Operation. getToken() Die getToken-Operation ist eine obligatorische Operation, die von dem elektronischen Wallet (z.B. m Wallet) aufgerufen wird., um Token abzurufen, die innerhalb einer Transaktion verwendet werden sollen. Abhängig von dem Transportkanal wird der Token über QR-Code angezeigt, über NFC übertragen oder als HTTP -Anforderung an eine Rückruf-URI gesendet.

Der Intent für die Abbildung für diese Operation wird durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.GetCardToken

Extra Issuer String Aussteller des Item

Extra CardID String Item ID

Extra Domain URI Domain des Token im Fall von

Mehrzweck-Items.

Extra RequestBundle String Zusätzliche Attribute

Die Operation getToken wird aufgerufen mit Activiry.startActivityforResult() und erwartet ein Ergebnis-lntent mit den folgenden Attributen.

Extra Token Byte[] Ergebnis notifyUsage()

Wenn sie von dem Item Provider bereitgestellt wird, wird die notifyUsage-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen, wenn ein Item in einer Transaktion verwendet wurde. Es liegt an dem IP, die Nutzlastparameter zu interpretieren oder bei diesem Ereignis irgendwelche Aktionen durchzuführen. Zum Beispiel können Items für die einmalige Verwendung als eingelöst markiert und aus dem Wallet entfernt werden. Der Intent für die Abbildung dieser Operation wird durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.NotifyUsage

Extra Issuer String Aussteller des Item

Extra CardID String Item ID

Extra Payload Byte[] Daten, die während einer

Transaktion von der interagierenden Partei empfangen werden.

Diese Operation wird mit Activity.startActivity() aufgerufen und gibt kein Ergebnis Intent zurück. removeItem()

Wenn sie von dem Item Provider bereitgestellt wird, wird die removeltem-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen, wenn der Nutzer ein Item löscht. Es liegt an dem IP, das Item aus seinem eigenen Data Store zu löschen, aber das Item soll in dem Cursor, der mit dem nächsten ContentProvider query()-Aufruf zurückgegeben wird, nicht mehr erscheinen.

Der Intent für die Abbildung dieser Operation wird durch folgende Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.DeleteCard

Extra Issuer String Aussteller des Item

Extra CardID String Item ID

Diese Operation wird mit Activity.startActivityForResult() aufgerufen, um auf das Löschen zu warten und den Ergebniscode zu prüfen.

Der implementierende IP soll context.getContentResolver().notifyChange(CardProvider.CARD_ CONTENT_URI, null) aufrufen, um die Aktualisierung der Ansicht des elektronischen Wallet (z.B. mWallet) auszulösen. importItem() Wenn sie von dem Item Provider bereitgestellt wird, wird die importltem-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen, wenn ein neues Item empfangen wurde. Zum Beispiel kann als ein Ergebnis einer Bezahlungstransaktion ein Gutschein ausgegeben werden. Es liegt an dem IP, die Daten zu interpretieren und das Item in seinem eigenen Data Store zu speichern. Das Item soll in dem Cursor erscheinen, der mit dem nächsten ContentProvider query()-Aufruf zurück gegeben wird.

Der Intent für die Abbildung dieser Operation wird durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.ImportCard

Extra Issuer String Aussteller des Item

Extra CardID String Item ID Diese Operation wird mit Activity.startActivityForResult() aufgerufen, um auf das Löschen zu warten und den Ergebniscode zu prüfen.

Der implementierende IP soll context.getContentResolver().notifyChange(CardProvider.CARD_ CONTENT_URI, null) aufrufen, um die Aktualisierung der Ansicht des elektronischen Wallet (z.B. mWallet) auszulösen. setDefault() Wenn sie von dem Item Provider bereitgestellt wird, wird die setDefault-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen, wenn ein Item als ein Default Item markiert ist. Zum Beispiel kann eine Bezahlkarte für Transaktionen vorausgewählt sein, um ein schnelles Bezahlen oder einen Niedrigenergiemodus zu gewährleisten. Es liegt an dem IP, ein cardlet zu aktivieren oder irgendeine andere Aktion durchzuführen.

Die Intent-Abbildung für diese Operation ist durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.setDefaultCard

Extra Issuer String Aussteller des Item

Extra CardID String Item ID Diese Operation wird mit Activity.startActivityForResult() aufgerufen, um auf das Löschen zu warten und den Ergebniscode zu prüfen. unsetDefault()

Wenn sie von dem Item Provider bereitgestellt wird, wir die unsetDefaul-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen, wenn die Festlegung eines Default Item aufgehoben wird. Der Intent für die Abbildung für diese Operation wird durch die folgenden Attribute definiert:

AttributName WertBeschreibung

typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.UnsetDefaultCard

Extra Issuer String Aussteller des Item

Extra CardID String Item ID

Diese Operation wird mit Activity.startActivityForResult() aufgerufen, um auf das Löschen zu warten und den Ergebniscode zu prüfen. invokeItem()

Wenn sie von dem Item Provider bereitgestellt wird, wird die invokeltem-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen. Ein Java Script in dem detaillierten Beschreibungs-HTML kann eine wallet.invoke -Operation aufrufen und jede Art von Parametern an sie weitergeben. Normalerweise wird hier ein JSON-String weitergegeben. Das elektronische Wallet (z.B. mWallet) wird dieses Item durch Aufrufen der invokeltem- Operation an den Item Provider weiterleiten. Es liegt an dem IP, den Parameter zu interpretieren und einen Ergebnis-JSON-String zurückzugeben, der von dem elektronischen Wallet (z.B. mWallet) an die WebView weitergegeben wird. Auf diese Weise können dynamische Informationen eines Items, wie etwa die Anzahl von Treuepunkten, angezeigt werden.

Der Intent für die Abbildung dieser Operation wird durch die folgenden Attribute definiert:

Attribut- Name Wert- Beschreibung Action <ITEM PROVIDER PREFIX>.intent.action.InvokeCard

Extra Issuer String Aussteller des Item

Extra CardID String Item ID

Extra Parameter String Item Provider-spezifische JSON.

Die Operation wird mit Activity.startAcivityforResult() aufgerufen und erwartet ein Ergebnis-Intent mit den folgenden Attributen.

Extra Parameter String Item Provider-spezifische JSON

launchCatalogue() Wenn sie von dem Item Provider bereitgestellt wird, wird die launchCatalogue-Operation von dem elektronischen Wallet (z.B. mWallet) aufgerufen. Es wird erwartet, dass die ΓΡ- Anwendung sich öffnet und dem Nutzer eine Liste zusätzlicher Items bereitstellt, die in das Wallet gelegt werden können. Der Intent für die Abbildung dieser Operation wird durch die folgenden Attribute definiert:

Altribut- Name WertBeschreibung typ typ

Action <ITEM PROVIDER PREFIX>.intent.action.LaunchCartImport

Extra Domain String Aussteller des Item

Diese Operation wird mit Activity.startActivityO aufgerufen und gibt kein Ergebnis- Intent zurück. Schutz von On-Device APIs

Aus der Perspektive des Wallet ist eine sichere On-Device API kritisch, um zu verhindern, dass auf die Wallet-Funktion und Daten von nicht registrierten Apps einer dritten Partei zugegriffen wird. Eine nicht gesicherte API würde zahlreiche Möglichkeiten für feindliche Anwendungen ermöglichen, die Spamdaten in das Wallet hinzufügen oder kritische Daten sammeln könnten. Nichtsdestotrotz wird es einzelne Methoden geben, die von jeder Anwendung frei verwendet werden können, und andere, die nur im Falle einer scharfen Authentifizierung verwendet werden können.

Es sollte hervorgehoben werden, dass die Zugriffssteuerung auf die On-Device API unter der Steuerung des Providers ist. Da diese Anforderung im Widerspruch zu der Sicherheitsarchitektur einiger mobiler Betriebssysteme steht, müssen auf der Ebene der On-Device API zusätzliche Schutzmechanismen definiert werden. Außerdem steht es dem Nutzer frei, einer App einer dritten Partei auf der OS-Ebene das Zugriffsrecht auf das Wallet zu gewähren. Das Wallet unterstützt verschiedene Arten von Items, wie etwa Gutscheine, Treuekarten, Bezahlkarten und in der Zukunft weitere. Es ist offensichtlich, dass mögliche Verluste und Schäden für jede Erscheinungsform von Kartentypen ziemlich verschieden sind. Um den entsprechenden Schutznotwendigkeiten zu genügen, werden die registrierten Apps dritter Parteien während des Registrierungsvorgangs an dem DT einem Schutzprofil zugewiesen. Das zugewiesene Profil definiert die Sicherheitsmaßnahmen, denen die App entsprechen muss. Abhängig von dem zugewiesenen Profil ist ein begrenzter Satz von Funktionen der On-Device API des Wallet zugänglich. Die Zuweisung wird zwischen der Deutschen Telekom und dem Entwickler der dritten Partei basierend auf einer Risiko- und Geschäftsanalyse für die dritte Partei, die Kartenaussteller und die Endnutzer vereinbart.

Das Wallet implementiert alle definierte Schutzprofile. Es kennt die Zuweisung zwischen einer App einer dritten Partei und dem zugehörigen Schutzprofil, was sicherstellt, dass die App der dritten Partei sich selbst mit dem richtigen Authentifizierungsmechanismus und den richtigen Berechtigungsnachweisen authentifiziert. Außerdem wird das Wallet mit neuen Zuweisungen aktualisiert, falls die neue App der dritten Partei in einem Wallet- Backendsystem registriert und von dem DT akzeptiert wird. Fig. 8 zeigt diese Abhängigkeiten.

Schutzprofile für Apps dritter Parteien

Die folgenden Schutzprofile und abgeleiteten Sicherheitsmaßnahmen werden von dem Wallet definiert und implementiert.

Annahme: Sicherheitsmaßnahmen nehmen ein nicht kompromittierendes mobiles Betriebssystem an. Falls das System von Schadprogrammen, wie Key Logger oder Spyware, betroffen ist, können die Maßnahmen umgangen werden.

Annahme: Durch die Profile definierte Sicherheitsmaßnahmen erfordern, dass die On- Device-Interprozesskommunikation von dem Betriebssystem geschützt wird und gegen Man-in-the-Middle-Angriffe oder Ausspähen geschützt wird. Die zwischen dem Wallet und der App der dritten Partei ausgetauschten Daten werden nicht verschlüsselt.

Der App-Provider sollte sensibel für mögliche Schäden sein, die von der App bei dem Endnutzer oder auf der Seite des Kartenausstellers verursacht werden, wenn sie missbraucht oder bösartig geändert wird. Die Entscheidung darüber, welches Schutzprofil der Entwickler auswählen sollte, ist ein Kompromiss zwischen dem Schadenspotential und Aufwänden für die App-Entwicklung und Schlüsselverteilung. Anonymes Profil (Fig. 9)

Das anonyme Profil kann nicht als ein echtes Schutzprofil gesehen werden, da jede dem Wallet unbekannte Anwendung einer dritten Partei in dieses Profil einsortiert wird. Es erfordert keine Berechtigungsnachweise, die von der App der dritten Partei übermittelt werden müssen, um die Anwendung zu identifizieren.

Das Profil zielt auf Apps ab, die nur eine Teilmenge von unkritischen Funktionen, die von dem Wallet bereitgestellt werden, die für die Verwendung durch jede Anwendung freigegeben sind, nutzen wollen. Fig. 9 zeigt die Maßnehmen, die auf einer hohen Ebene ergriffen werden müssen, um die ungeschützte On-Device API zu verwenden.

Da die On-Device API ein Zugangstoken für jeden Operationsaufruf verlangt, muss zuerst eine Login-Methode ohne irgendwelche Berechtigungsnachweisen aufgerufen werden. Das Ergebnis wird ein Sitzungstoken, das benötigt wird, um jede API-Operation aufzurufen.

Minimales Schutzprofil (Fig. 10)

Das minimale Schutzprofil zielt darauf ab, das Wallet gegen die unerwartete Nutzung der On-DeviceAPI zu schützen, um Schäden und den Missbrauch durch Apps dritter Parteien auf dem Niveau des grundlegenden Schutzes zu verhindern. Es stellt den Bsisschutz für geringe Entwicklungs- und organisatorische Aufwände für Entwickler einer dritten Partei oder den Kartenaussteller bereit. Aber es schützt nicht gegen bösartige Angriffe, da es möglich sein wird, mit etwas Aufwand in Ausspähung oder Überarbeitung Berechtigungsnachweise auszuspionieren.

Dieses Profil zielt auf Apps ohne Schadenspotential für den Endnutzer und nur minimalem möglichem Schadenspotential für den Kartenaussteller ab. Zum Beispiel passt es für kostenlose Gutschein-Apps oder Treuekarten-Apps, die aufgrund des funktionellen Wesens der Karte bei dem Endnutzer keinen finanziellen Schaden verursachen können. Das Schadenspotential für den Kartennutzer kann in Kombination mit eindeutigen Karten- IDs und Echtzeit-Gültigkeitsprüfungen an dem Point of Sale während der Einlösung begrenzt werden.

Die folgenden Vordefinitionen bringt dieses Profil mit sich:

• Eine Wallet-Kennung für alle Installationen Die Anwendungskennung des Wallet ist die gleiche für alle Wallet-Installationen auf verschiedenen Mobiltelefonen. Dies bedeutet, dass gemeinsame

Berechtigungsnachweise verwendet werden, die Apps dritter Parteien bekannt sein müssen.

• Eine einzige Kennung für die App einer dritten Partei über alle Installationen einer dritten Partei hinweg als die gleiche Kennung agieren.

Schlussfolgerung: Wenn einmal ein Secret/Zertifikat, das/der für die Authentifizierung verwendet wird, kompromittiert ist, sind alle anderen Installationen möglicherweise ebenfalls kompromittiert. Basierend auf diesen Vordefinitionen definiert dieses Profil die folgenden S chutzmaßnahmen :

• Wechselseitige Authentifizierung basierend auf einem Nachrichtenauthentifizierungscode (MAC) unter Verwendung eines Shared Secret, das mit der App einer dritten Partei paketiert und ausgebracht wird.

· Berechtigung basierend auf einem einmaligen Zugangstoken.

Fig. 10 zeigt die einmaligen Maßnahmen, die auf einer hohen Ebene für die Verwendung der On-Device API ergriffen werden. Starkes Schutzprofil (Fig. 1 1)

Das starke Schutzprofil zielt darauf ab, das Wallet zu schützen, um Schaden und Missbrauch durch bösartige Apps einer dritten Partei zu verhindern. Es stellt kryptographisch sicher, dass dem Wallet die App einer dritten Partei bekannt ist und ihr vertraut wird. Als Folge sind die Entwicklungs- und Schlüsselbereitstellungsaufwände nicht trivial. Das Profil schützt das Wallet gegen die Verwendung von nicht registrierten Apps einer dritten Partei und lässt keine Überarbeitung von Berechtigungsnachweisen zu. Sie zielt auf Apps mit erheblichem Schadenspotential für den Nutzer und den Kartenaussteller ab. Zum Beispiel passt es für Geschenkgutschein-Apps oder Karten, die einen Geldwert haben, und möglicherweise für Bezahlkarten.

Die folgenden Vordefinitionen bringt dieses Profil mit sich:

· Eine einzige Wallet-Kennung für jede Wallet-Installation Die Kennung der Anwendung des Wallet ist für alle Wallet-Installationen auf verschiedenen Mobiltelefonen eindeutig. Einzelne Berechtigungsnachweise müssen durch Apps dritter Parteien verifizierbar sein.

• Einzelne Keimung für die App einer dritten Partei für jede Installation einer App einer dritten Partei

Jede Kennung einer App einer dritten Partei wird in der Wallet Domain als eine einzelne Kennung agieren.

Schlussfolgerung: Wenn einmal ein Secret/ein Berechtigungsnachweis kompromittiert ist, ist nur eine einzige App/Wallet beeinträchtigt und kann gesperrt werden, ohne andere Mobilnutzer zu beeinträchtigen.

Dieses Profil definiert die folgenden Schutzmaßnahmen:

• Wechselseitige Authentifizierung des Wallet und der App einer dritten Partei basierend auf einer digitalen Signatur unter Verwendung einer asynchronen

Schlüsselkryptographie.

Die Autorisierung basiert auf einem temporären Sitzungsschlüssel/Token. Fig. 1 1 zeigt die einzelnen Maßnahmen, die für die Verwendung der On-Device API auf einer hohen Ebene ergriffen werden müssen.

App-Registrierungsvorgang

Die Abfolgediagramme in den vorstehenden Abschnitten geben einen knappen Eindruck der Schritte, die für die sichere On-Device-Kommunikation notwendig sind. Details sollen in den nächsten Abschnitten erklärt werden.

Der erste Schritt für die Kommunikation einer App einer dritten Partei/eines Wallet ist die Registrierungsphase, in der die App einer dritten Partei dem Wallet-Ökosystem bekannt gemacht wird und umgekehrt. Abhängig von dem Schutzprofil, das der App einer dritten Partei zugewiesen wird, unterscheiden sich einige der Registrierungsdetails von Profil zu Profil. Details werden pro Profil in den nächsten zwei Unterabschnitten beschrieben. Registrierungsvorgang für anonymes Profil

Für anonyme Apps ist keine Registrierung erforderlich.

Registrierungsvorgang für Apps einer dritten Partei mit minimalem Schutzprofil

Das minimale Schutzprofil definiert den Authentifizierungsmechanismus zwischen der App einer dritten Partei und dem Wallet, der auf einem Shared Secret basiert. Das Wallet- Ökosystem muss das Secret der App einer dritten Partei kennen und die App einer dritten Partei muss das Secret des Wallet kennen. Der Austausch von gemeinsam genutzten Schlüsseln wird in dem Registrierungsvorgang erledigt, wobei der Entwickler der dritten Partei das App nach der Entwicklerregistrierung und dem Login an dem DT-Wallet- Backend registriert.

Die folgenden Parameter werden für die App-Registrierung ausgetauscht:

Name Richtung Beschreibung

sharedKey Eingabe Gemeinsam genutzter Schlüssel, der von der App einer dritten Partei

für die Authentifizierung verwendet werden soll. Abhängig von den OS-Fäl igkeiten kann dieser ein generierter Zufallsschlüssel oder die digitale Signatur des Installationspakets sein.

applicationID Ausgabe Kennung, die App in dem Wallet-Ökosystem identifiziert

walletKey Ausgabe Gemeinsam genutzter Schlüssel, der von dem Wallet für die

Authentifizierung verwendet werden soll. Abhängig von den OS- Fähigkeiten kann dieser ein generierter Zufallsschlüssel oder die digitale Signatur des Installationspakets sein Der Entwickler der dritten Partei ist dafür verantwortlich, die drei Parameter in das Installationspackage zu packen oder die Informationen nach der Installation der App zum Beispiel durch sein eigenes Backend System auszubringen.

Alle Wallet-Installationen werden über den OTA-Kanal mit der Liste gültiger Anwendungskennungen und gemeinsam genutzter Schlüssel aktualisiert. Diese heiklen Informationen werden auf der UICC sicher gespeichert.

Registrierungsvorgang für das starke Schutzprofil

Ein Hauptunterschied zu dem minimalen Schutzprofil ist, dass jede Installation (Wallet und App einer dritten Partei) in dem Wallet-Ökosystem als eine einzelne Kennung agiert. Dies vergrößert die Anzahl vorhandener Kennungen, was entweder eine strenge Zuweisung zwischen dem Wallet und den Installationen einer App einer dritten Partei oder eine Zertifikathierarchie, die dazu beiträgt, die Kennungsverwaltungsaufwände zu senken, erfordert.

Das Letztere wird hier eingeführt, was zu einem Zweischritt-Registrierungsvorgang für das starke Schutzprofil führt. In dem ersten Schritt wird die App einer dritten Partei von dem Entwickler an dem Wallet- Backend registriert. Die folgenden Parameter werden ausgetauscht:

Name Richtung Beschreibung

application ID Eingabe Name und Version der App einer dritten Partei. Die Kennung wird

zur Ausgabe des Zertifikats einzelner Installationen in dem zweiten Registrierungsschritt verwendet.

registrationURL Ausgabe Die URL, mit der sich die App einer dritten Partei im zweiten

Registrierungsschritt verbinden muss.

Der zweite Registrierungsschritt muss von der App einer dritten Partei und dem Wallet durchgeführt werden und findet statt, nachdem die Anwendung auf dem Mobiltelefon installiert ist. Die Anwendung einer dritten Partei und das Wallet müssen ein privates/öffentliches Schlüsselpaar generieren, das von der Anwendung (im Fall des Wallet

UICC) sicher gespeichert wird. Bei IP-Verbindungsmöglichkeit wird eine

Zertifikatanforderung an die Wallet Backend URL gesendet, um den neu erzeugten öffentlichen Schlüssel zu signieren. Im Fall der App einer dritten Partei wurde die URL in dem ersten Schritt abgerufen und in dem App-Installationspaket paketiert. Das Backend wird die Kennung des Senders basierend auf dem Mobilnetzwerk und den gebuchten Dienstangeboten prüfen.

Die folgenden Parameter werden in dem zweiten Registrierungsschritt ausgetauscht:

Name Richtung Beschreibung

applicationID Eingabe Name und Version der App einer dritten Partei. Die Kennung wird

zur Ausgabe des Zertifikats einzelner Installationen in dem zweiten Registrierungsschritt verwendet.

certRequest Eingabe Anforderung, dass ein öffentliches Schlüsselzertifikat von dem Wallet

Backend mit dem RootCA signiert wird, dem das Wallet vertraut.

signedCert Ausgabe Zertifikat der Installation einer dritten Partei.

walletCaCert Ausgabe Liste vertrauter CA-Zertifikate. Falls das Wallet diese Methode

aufruft, enthält dieser Parameter das/die CA-Zertifikat(e) zur

Verifizierung von Zertifikaten einer App einer dritten Partei.

Falls die App einer dritten Partei diese Operation aufruft, enthält dieser Parameter das Wallet Ca cert zur Verifizierung der Wallet-

Zertifikate.

Das signierte Zertifikat und das Wallet CA-Zertifikat werden an die Installation einer App einer dritten Partei zurück gegeben. Das Zertifikat in Kombination mit einer Signatur wird während des Authentifizierungsverfahrens von der App einer dritten Partei an das Wallet weitergegeben. Das Wallet CA cert wird verwendet, um das Zertifikat des Wallet für die wechselseitige Authentifizierung zu verifizieren.

Authentifizierungsvorgang

Bevor die On-Device API des Wallet verwendet werden kann, müssen die Parteien sich (gegenseitig) authentifizieren. Abhängig von dem vereinbarten Schutzprofü muss die App spezifische Berechtigungsnachweise bereitstellen und muss eine profilspezifische Authentifizierungsmethode verwenden, die von der Wallet-API bereitgestellt wird.

Das Wallet verarbeitet den Login-Aufruf und verifiziert die Berechtigungsnachweise und agiert schließlich als ein Sicherheitstokendienst, der ein Sitzungstoken ausgibt. Das Sitzungstoken enthält einen temporären Sitzungsschlüssel und zusätzliche Attribute, die später benötigt werden, um ein Zugangstoken zu berechnen, das mit jedem API-Aufruf weitergegeben werden soll.

Das sich ergebende Sitzungstoken ist unabhängig von spezifischen Schutzprofilen und hat das folgende Format:

Name Beschreibung

Sessionld Eindeutige Kennung Pid Prozesskennung der aufrufenden Anwendung, um sicherzustellen, dass das Token von dem richtigen Prozess ausgegeben wird (pid des Aufrufers muss während der

Validierung des Zugangstoken verifiziert werden).

validFrom Startzeit der Tokengültigkeit

validTo Abiaufzeit des Token, um sicherzustellen, dass die Anwendung sich häufig neu authentifiziert.

encSessionkey Der gemeinsam genutzte Sitzungsschlüssel, der verwendet wird, um Zugangstoken bei anschließenden API-Aufrufen zu berechnen und zu verifizieren. Der Sitzungsschlüssel wird mit den Berechtigungsnachweisen des Wallet, die in dem minimalen PP der gemeinsam genutzte Schlüssel sind, oder dem privaten Schlüssel des Wallet verschlüsselt, wenn das starke PP verwendet wird. Die Verschlüsselung verhindert, dass irgendjemand anders das Secret der Sitzung erhält,

signature Eine Signatur signiert alle Tokenattribute, um die Modifikation des Token während des Transits zu verhindern. Die Signatur wird mit den Berechtigungsnachweisen des Wallet erzeugt, welche in dem minimalen PP der gemeinsam genutzte Schlüssel oder bei Verwendung des starken PP der private Schlüssel des Wallet sind.

Authentifizierungsvorgang für das anonyme Profil

Apps, die nicht bei dem Wallet registriert sind, benötigen bei jedem API- Aufruf ein Sitzungstoken zur Berechnung eines einmaligen Zugriffstoken. Das Sitzungstoken wird abgerufen, indem die Login-Methode aufgerufen wird, ohne irgendwelche Berechtigungsnachweise weiterzugeben. Das Wallet wird die Sitzung dem anonymen Profil zuweisen und nur den Aufruf von Methoden zulassen, deren Verwendung für jede Anwendung frei steht. Authentifizierungsvorgang für minimales Schutzprofil

Die für das minimale Schutzprofil definierte Authentifizierung basiert auf einem Shared Secret zwischen dem Wallet und der App einer dritten Partei. Apps einer dritten Partei authentifizieren sich an dem Wallet durch Aufrufen der Login-Methode. Um zu verhindern, dass der gemeinsam genutzte Schlüssel für andere Anwendungen, die ebenfalls den Login-Aufruf abrufen könnten (zum Beispiel in dem Fall, dass der für Android vorgesehene Mechanismus für IPC verwendet wird) verfügbar gemacht wird, wird der gemeinsam genutzte Schlüssel nicht direkt mit dem Ruf weitergegeben. Als eine Alternative wird der zerstückelte Schlüssel zur Berechnung eines HMAC, der mit dem Aufruf weitergegeben wird, verwendet. Die Login-Methode stellt die folgenden Parameter bereit:

Name Richtung Beschreibung

applicationID Eingabe Eindeutige Kennung, die von dem Wallet Backend während des App- Registrierungsvorgangs an die dritte Partei bereitgestellt wird.

Hmac Eingabe/ Nachrichtenauthentifizierungscode, der berechnet wird, indem die

Ausgabe Anwendungskennung + Zeitstempel + Nonce + gemeinsam genutzter

Schlüssel, die während des App-Registrierungsvorgangs von dem Wallet Backend an die dritte Partei bereitgestellt wurden, zerhackt werden

timestamp Eingabe/ Zeitstempel, der verwendet wird, um den hmac zu berechnen

Ausgabe

nounce Eingabe/ Zufallszahl zur Berechnung des hmac

Ausgabe

sessionToken Ausgabe Token, das den Sitzungsschlüssel enthält

Während des Aufrufs der Login-Methode prüft das Wallet zuerst die Zuweisung der Anwendungskennung und des Schutzprofils. Wenn das Wallet die Zuweisung der App an das minimale Schutzprofil kennt, wird der bereitgestellte HMAC verifiziert, indem die gleichen Schritte durchgeführt werden wie es die App einer dritten Partei tat, indem der gemeinsam genutzte Schlüsse verwendet wird, der für die gegebene Anwendungskennung registriert ist. Bei Erfolg wird ein Sitzungstoken einschließlich der temporären Sitzungsschlüssels und einem anderen HMAC zum Authentifizieren des Wallet bei der App einer dritten Partei erzeugt und zurück gegeben.

Der App einer dritten Partei steht es frei, den zurück gegebenen HMAC zu validieren, um die Kennung des Wallet zu prüfen. Authentifizierungsvorgang für das starke Schutzprofil

Die für das starke Schutzprofil definierte Authentifizierung basiert auf einer digitalen Signatur, die mit dem privaten Schlüssel der App und einer Zertifikathierarchie berechnet wird. Auf der Seite der dritten Partei und des Wallet wird der gleiche Mechanismus verwendet, um die wechselseitige Authentifizierung zu ermöglichen.

Apps einer dritten Partei authentifizieren sich bei dem Wallet durch Aufrufen der Login- Methode, wobei die folgenden Parameter bereitgestellt werden:

Name Richtung Beschreibung

applicationID Eingabe Eindeutige Kennung, die von dem Wallet Backend während des App- Registrierungsvorgangs an die dritte Partei bereitgestellt wird.

signature Eingabe/ Digitale Signatur, die berechnet wird, indem die Ausgabe Anwendungskennung + Zeitstempel + Nonce berechnet wird und der

private Schlüssels der App verschlüsselt wird.

Das Wallet gibt unter Verwendung der gleichen Berechnungsregeln, aber seines eigenen gemeinsam genutzten Schlüssels, welcher der App einer dritten Partei durch den Registrierungsvorgang bekannt ist, einen neuen hmac zurück.

certificate Eingabe/ Zertifikat, das zum Verifizieren der Signatur verwendet werden soll

Ausgabe

timestamp Eingabe/ Zeitstempel, der verwendet wird, um den hmac zu berechnen

Ausgabe

nounce Eingabe/ Zufallszahl zur Berechnung des hmac

Ausgabe

sessionToken Ausgabe Token, das den Sitzungsschlüssel enthält

Während des Aufrufs der Login-Methode prüft das Wallet zuerst die Zuweisung der Anwendungskennung und des Schutzprofils. Wenn das Wallet von der Zuweisung des starken Schutzprofiis weiß, wird die gegebene digitale Signatur validiert. Dies wird erledigt, indem die Signatur mit dem gegebenen Zertifikat entschlüsselt wird und der entschlüsselte hash-Wert anschließend an die gleichen Schritte wie sie die App einer dritten Partei durchgeführt hat, mit dem Ergebnis seiner eigenen hash-Berechnung verglichen wird. Ein letztes Zertifikat muss validiert werden und es muss geprüft werden, ob ihm vertraut wird, was bedeutet, dass es von einem der vertrauten CA certs ausgegeben wird, die dem Wallet bekannt sind. Das Wallet gibt ein Sitzungstoken einschließlich eines temporären symmetrischen Schlüssels und zusätzlicher Attribute zurück, die für weitere On-Device API-Aufrufe verwendet werden. Es steht der App einer dritten Partei frei, den zurück gegebenen HMAC zu validieren, um die Kennung des Wallets zu prüfen. On-Device API-Verwendungsvorgang

Wie bereits dargelegt, kann die On-Device API nur verwendet werden, wenn die App einer dritten Partei sich erfolgreich bei dem Wallet authentifiziert hat und ein Sitzungstoken abruft. Sie kann alle Wallet API-Operationen verwenden, die zu dem Schutzprofil gehören, dem die App entspricht. Zum Beispiel kann eine Gutscheinanwendung alle Methoden verwenden, die von der CoreWallet-Schnittstelle und der Gutscheinschnittstelle gezeigt werden.

Der API-Aufruf wird von dem Wallet nur verarbeitet, wenn als erster Parameter des

Aufrufs ein gültiges Zugangstoken weitergegeben wird. Das Zugangstoken ist ein einmaliges Token und wird von dem Sender der Nachricht (entweder der App einer dritten

Partei oder dem Wallet) mit Hilfe des Sitzungstoken, das als Ergebnis einer erfolgreichen Authentifizierung ausgetauscht wurde, berechnet. Das Format des Token und die Verarbeitungsregeln unterscheiden sich nicht zwischen den Schutzprofilen. Als ein Ergebnis müssen in diesem Abschnitt keine profilspezifischen Schritte beschrieben werden.

Das Zugangstokenformat ist ein kundenangepasstes Format, das an beliebte standardisierte Tokenformate angelehnt ist, die unglücklicherweise auf

Netzwerkkommunikationsprotokolle abzielen, die nicht notwendigerweise für die Wallet On-Device API gelten. Zum Beispiel ist OAuth mit HTTP und SAML mit dem XML- Format verheiratet, aber die On-Device API kann auf den geplanten Mechanismus von Android abgebildet werden.

Das ZugangsToken besteht aus den folgenden Attributen:

Name Beschreibung

Sessionld Kennung, die die aktuelle Sitzung identifiziert (Token)

timeStamp Aktuelle Zeit

nonce Zufallsstring

signature HMC, der aus den drei Tokenattributen aus dem Obigen plus dem Sitzungsschlüssel von dem Sitzungstoken berechnet wird.

Das Aufnehmen eines nonce und eines Zeitstempels in die Signaturberechnung stellen sicher, dass das Zugangstoken nur für die einmalige Verwendung gültig ist, und verhindern Replay-Angriffe in dem Fall, dass ein anderer Prozess auf dem Mobiltelefon einen API- Aufruf aufgefangen hat.

Vor der Verarbeitung der API-Aufruffunktionalität muss das Zugangstoken auf der Empfängerseite validiert werden. Zuerst wird die Signatur validiert, indem die HMAC- Signatur berechnet wird, indem die gleichen Berechnungsschritte verarbeitet werden wie es der Sender tat, aber der gemeinsam genutzte Schlüssel aus dem Sitzungstoken verwendet wird. Bei erfolgreicher Validierung des Zugangstoken werden die Attribute des Sitzungstoken validiert. Dieser Schritt validiert die validFrom- und validTo-Attribute des Sitzungstoken und gleicht die Prozesskennung des Senders mit der PID in dem Sitzungstoken ab. Nur wenn beide Token erfolgreich validiert werden, wird die Methode verarbeitet.

Obwohl die Erfindung mittels der Figuren und der zugehörigen Beschreibung dargestellt und detailliert beschrieben ist, sind diese Darstellung und diese detaillierte Beschreibung illustrativ und beispielhaft zu verstehen und nicht als die Erfindung einschränkend. Es versteht sich, dass Fachleute Änderungen und Abwandlungen machen können, ohne den Umfang der folgenden Ansprüche zu verlassen. Insbesondere umfasst die Erfindung ebenfalls Ausführungsformen mit jeglicher Kombination von Merkmalen, die vorstehend zu verschiedenen Aspekten und/oder Ausführungsformen genannt oder gezeigt sind.

Die Erfindung umfasst ebenfalls einzelne Merkmale in den Figuren auch wenn sie dort im Zusammenhang mit anderen Merkmalen gezeigt sind und/oder vorstehend nicht genannt sind.

Im Weiteren schließt der Ausdruck„umfassen" und Ableitungen davon andere Elemente oder Schritte nicht aus. Ebenfalls schließt der unbestimmte Artikel„ein" bzw.„eine" und Ableitungen davon eine Vielzahl nicht aus. Die Funktionen mehrerer in den Ansprüchen aufgeführter Merkmale können durch eine Einheit erfüllt sein. Die Begriffe „im Wesentlichen",„etwa",„ungefähr" und dergleichen in Verbindung mit einer Eigenschaft beziehungsweise einem Wert definieren insbesondere auch genau die Eigenschaft beziehungsweise genau den Wert. Alle Bezugszeichen in den Ansprüchen sind nicht als den Umfang der Ansprüche einschränkend zu verstehen.