WO2014095850A1 - Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet - Google Patents

Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet Download PDF

Info

Publication number
WO2014095850A1
WO2014095850A1 PCT/EP2013/076885 EP2013076885W WO2014095850A1 WO 2014095850 A1 WO2014095850 A1 WO 2014095850A1 EP 2013076885 W EP2013076885 W EP 2013076885W WO 2014095850 A1 WO2014095850 A1 WO 2014095850A1
Authority
WO
WIPO (PCT)
Prior art keywords
wallet
data
internet service
terminal
electronic wallet
Prior art date
Application number
PCT/EP2013/076885
Other languages
English (en)
French (fr)
Inventor
Zhiyun Ren
Jörg Heuer
Klaus-Peter Hofman
Original Assignee
Deutsche Telekom Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom Ag filed Critical Deutsche Telekom Ag
Priority to EP13821459.8A priority Critical patent/EP2936406A1/de
Priority to US14/653,321 priority patent/US9898734B2/en
Publication of WO2014095850A1 publication Critical patent/WO2014095850A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3267—In-app payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the invention relates to a method and a system for terminal-based communication between foreign applications and an electronic wallet, wherein in particular data for the use of Internet services are managed via the electronic wallet.
  • API Programming Interface Application Programming Interface
  • An electronic wallet (hereinafter also referred to simply as a “wallet”) is a hardware and software module within a terminal, usually a mobile terminal such as a mobile phone or smartphone, which consists of two parts:
  • a “Secure Element”, hereinafter also referred to as “security element” eg in the form of a SIM card / UICC or a Javacard integrated in the chipset of the terminal, with Java applets thereon, on the one hand by applications can be addressed on the terminal and via wireless radio communication (for example NFC) of acceptance points (ie card readers) in card emulation mode.
  • security element eg in the form of a SIM card / UICC or a Javacard integrated in the chipset of the terminal
  • Java applets thereon on the terminal and via wireless radio communication (for example NFC) of acceptance points (ie card readers) in card emulation mode.
  • this architecture of the electronic wallet allows the mapping of real smart cards (for various applications such as payments, customer card, coupons) to the terminal, whereby the role of the chip of the real card is taken over by the Java applets on the security element, for example the UICC and the role of the imprint (ie, caption, design, logo, and / or other markings) on the physical card through the wallet software on the terminal, such as the mobile phone.
  • the role of the chip of the real card is taken over by the Java applets on the security element, for example the UICC and the role of the imprint (ie, caption, design, logo, and / or other markings) on the physical card through the wallet software on the terminal, such as the mobile phone.
  • Applet is here and below understood to mean an application which is configured for execution on a security element Instead of “applet”, the synonymous designation “cardlet” is also used in the following configured to run under the operating system of the terminal, referred to as "App”.
  • the electronic wallet is located on a mobile terminal, such as a mobile phone, then the electronic wallet should also be referred to as a "mobile wallet”.
  • the cards in the electronic wallet can then be used at appropriate acceptance points such as physical plastic cards, wireless wireless communication (for example, the NFC), applets on the security element (such as the UICC), for example, be addressed contactless at the cashier in the supermarket.
  • appropriate acceptance points such as physical plastic cards, wireless wireless communication (for example, the NFC), applets on the security element (such as the UICC), for example, be addressed contactless at the cashier in the supermarket.
  • this technique allows the use of a security element (such as the UICC) as a multi-functional smart card, allowing the user to enjoy the appropriate Security levels of a smart card application comes: Data can not be read from the smart card, the smart card can not be copied and releases your data if necessary after entering a PIN for use.
  • a security element such as the UICC
  • Similar procedures have been established for similar operations in the online world. For example, pay operations are performed by users on web pages reading information from their credit card and typing into web forms. The authentication of users to web pages is usually done by entering user ID and password.
  • platform On mobile platforms (here and below the term “platform” is understood to mean the operating system of a terminal, “mobile platform” is understood to mean the operating system of a mobile terminal), in turn, it is customary to pay for apps and other digital goods on the mobile Terminal, his payment card data once with an account of the mobile phone manufacturer to connect, so that the acquisition of such goods in the future, for example can be settled on a credit card.
  • apps and other digital goods on the mobile Terminal, his payment card data once with an account of the mobile phone manufacturer to connect, so that the acquisition of such goods in the future, for example can be settled on a credit card.
  • online services such as server-based storage of photos
  • US 2009/0234751 A1 discloses an electronic wallet for a wireless mobile device and a method of using the electronic wallet.
  • the electronic wallet includes: an invoker that responds to an external trigger external of the wallet; a user authentication device for authenticating the user of the electronic wallet when the wallet is called by the external trigger; and means for retrieving map information stored in the wallet in response to a form specified by the external trigger calling the wallet.
  • the external trigger may be a website visited via an Internet browser on the draleless mobile device, with a wallet trigger instruction embedded in the website.
  • the wallet trigger statement may be a supplement embedded in the header of the website visited via the internet browser.
  • the site may also contain field ID tags containing specific data fields in the wallet to form input fields provided by the website.
  • WO 2006/085805 A1 relates to a method for performing electronic transactions in a network, comprising: a mobile subscriber terminal with a digital wallet and a browser, a server for the management of the transactions and a content provider.
  • the subscriber selects a service and sends an application form to a content provider.
  • the content provider sends a transaction request form to the mobile subscriber.
  • the subscriber confirms the transaction and sends the transaction request form to the browser.
  • the browser reads the data required for the transaction form from the digital wallet and populates the application form with the transaction data read.
  • the complete form is then sent to the server, which converts the full form into a standard transaction format.
  • the content provider processes the complete application form and sends it to the content provider who answers the subscriber.
  • US 2012/01223868 A1 describes a system for dynamically adapting the wireless data emulation used by a portable communication device based on its geolocation.
  • the system determines a geolocation of the portable communication device by transmitting the current geolocation data to the server using the most appropriate channel; Receiving data from payment systems that might be in the vicinity of the portable communication device; and develop a payment system in the portable communication device with the data formats and other wireless point-of-sale data that are typical of payment systems that might be in the vicinity of the device.
  • US 2012/0166337 Al shows a near field communication (NFC) terminal for performing secure payment comprising an NFC unit and a control unit.
  • the NFC unit communicates with an external payment terminal, and the payment unit, using the NFC unit, transfers results acquired by the processing of transaction information and an electronic signature value of the transaction information to the payment terminal.
  • the payment terminal calls an external payment server to make the payment.
  • An authentication confirmation applet in the payment unit generates the electronic signature of the transaction information.
  • An electronic wallet applet included in the payment unit transmits the result obtained by the processing of the transaction information and the electronic signature value to the payment terminal.
  • US 2012/0 130 839 AI describes techniques for managing modules or applications installed in the mobile device.
  • each of the installed applications is provided with a server by the data transfer potential in a mobile device.
  • a provided application is associated with the personalized security element of the mobile device and works with a set of keys generated in accordance with a key set of the personalized security element. Furthermore, the control management of an installed application is described.
  • WO 2012/021 864 A2 shows a telephone-based electronic wallet that offers authenticated transactions over multiple trade routes.
  • the electronic wallet may be used for point-of-sale payments, remote mobile payments, and / or web-based payments, and may use authentication means such as offline PINs, SecureCode PINs, and / or online PINs.
  • the classic electronic wallet works only in the vicinity of an acceptance point by means of wireless radio communication (eg NFC radio technology).
  • wireless radio communication eg NFC radio technology
  • more and more people are using their mobile device to conduct transactions on the Internet. For example: (i) online payment of digital goods (eg MP3 download),
  • One aspect of the invention relates to a method for terminal based communication between a third party application and an electronic wallet.
  • the electronic wallet is installed on a terminal, and the third-party application is installed on the terminal.
  • the method comprises the following steps:
  • connection requires transmission of data to the Internet service; (b) receiving by the foreign application a request of the Internet service directed to the transmission of said data;
  • step (c) forwarding the request received by the Internet service in step (b) to the electronic wallet by the foreign application;
  • step (f) receiving an acknowledgment of the forwarding of the response to the Internet service according to step (e), wherein the receiving is done by the foreign application.
  • a security element is connected to the terminal; and step (d) of processing the request and generating a response comprises the steps of:
  • Radio communication for example, radio-based short-range communication (NFC) is configured.
  • NFC radio-based short-range communication
  • the security element is a universal integrated circuit card (UICC) or a SIM card.
  • UICC universal integrated circuit card
  • step (d) of processing the request and generating a response comprises the steps of:
  • the terminal is suitable for mobile radio communication; the terminal may be, for example, a mobile device or a smartphone and / or be suitable for WLAN communication. In which Terminal may also be, for example, a laptop / notebook or a tablet computer.
  • the data has confidential and / or user-specific information.
  • the data may include authentication information.
  • the data may include information for a login or for a payment transaction.
  • the data may also include personal information.
  • step (e) of forwarding the data comprises the following steps:
  • step (e) of forwarding the data comprises the following steps:
  • the foreign application is a service provider application installed on the terminal that is configured to use the Internet service.
  • the foreign application is an Internet browser installed on the terminal.
  • One aspect of the invention relates to a system for terminal-based communication between one or more foreign applications and an electronic wallet.
  • the system has a terminal.
  • the system is characterized in that an electronic wallet is installed on the terminal and one or more third-party application (s) are installed on the terminal.
  • the third-party application (s) are each configured to: establish a connection to an Internet service, the connection requiring transmission of data to the Internet service; for receiving a request for transmission of the data of the Internet service; and for forwarding the request received from the Internet service to the electronic wallet.
  • the electronic wallet is configured to: process the said request and generate a corresponding response; to forward the answer to the internet service.
  • the foreign application (s) are each configured to: receive an acknowledgment of a forwarding to the Internet service, the receiving being done by the foreign application.
  • the answer that is generated in accordance with the request for the transmission of said data all the requested data, a part of the requested data or none of the requested data (the latter corresponds to a denial of data transmission), the response in encrypted and / or unencrypted form.
  • the terminal is configured to receive one or more security elements, with one or more programming interfaces (APIs) installed on the terminal for listing, selecting, and interacting with the security elements.
  • the system further includes one or more security elements (e) incorporated in the terminal, the terminal being connected to the one or more security elements.
  • the electronic wallet is configured to process the said request and generate a corresponding response: to send requests for said data to the one or more security elements (e); for receiving replies to said data from or from the security element (s).
  • the security element is preferably configured for wireless radio communication, for example radio-based short-range communication (NFC).
  • NFC radio-based short-range communication
  • the security element is a Universal Integrated Circuit Card (UICC) or a SIM card.
  • the electronic wallet is further configured to process said request and generate a corresponding response: to send a request for said data to an app, for example, another foreign application; and for receiving a response regarding said data from the app.
  • the terminal is suitable for mobile radio communication; the terminal may be, for example, a mobile device or a smartphone, and / or be suitable for WLAN communication.
  • the terminal may also be, for example, a laptop / notebook or a tablet computer.
  • the data comprises confidential and / or user-specific information.
  • the data may have information for authentication.
  • the data may include information for a login or for a payment transaction.
  • the data may also include personal information.
  • the electronic wallet is configured to forward the response to the Internet service: to transmit the data to a wallet backend. It also configures the wallet backend: to connect the wallet backend to the internet service; and for transmitting the data to the Internet service.
  • the electronic wallet is configured to forward the response to the Internet service: transmitting the data to the foreign application (s). Furthermore, the foreign application (s) are each configured to transmit the data to the Internet service.
  • the third-party application is a service provider application installed on the terminal that is configured to use the Internet service. In one embodiment of the system, the third-party application is an Internet browser installed on the terminal.
  • the present invention shows how the electronic wallet can be extended by means of on-device APIs in such a way as to enable the execution of transactions on the Internet, and thus in particular also the scenarios described above under points (i) to (iv) the electronic wallet can be supported (see Fig. 1).
  • the electronic wallet is already designed for short-range use via wireless radio communication (such as NFC) as a secure application on the terminal.
  • This infrastructure can be reused for the storage of all security or privacy relevant personal data.
  • the smart card function of the security element for example the UICC
  • the security element for example the UICC
  • FIG 1 Use of wallet functions by third-party applications (third-party apps);
  • FIG. 1 Process of using on-device APIs
  • FIG. 3 an overview of the system according to the invention
  • FIG. 4 an (NFC) ecosystem with on-device API
  • FIG. 5 user operation 1: the user selects vouchers in the app of a third party and pays by means of a wallet;
  • FIG. 6 user operation 2: the user selects vouchers in the app of a third party by means of a wallet;
  • FIG. 7 a view of the components of the on-device API
  • FIG. 8 Shows dependencies between the wallet and an app of a third party
  • FIG. 9 a flow diagram of the anonym profile
  • FIG. 10 a flow chart of the minimum protection profile
  • Figure 11 A flow chart of the protection profile with high protection.
  • the user has a mobile phone or other device that can hold one or more security features.
  • APIs exist on the terminal to list, select and address security elements with APDU commands.
  • the platform allows the integration of separately installed apps via appropriate platform-specific mechanisms - the so-called “on-device APIs” or “wallet APIs”.
  • the inventive method is based on creating programming interfaces between any third-party applications (third-party apps) on the terminal and the wallet on the terminal in order to create a use of the functions of the electronic wallet by these third-party applications.
  • the third-party application on the terminal connects to a service on the Internet (Internet service), which requires authentication for login or payment or the transmission of personal data (step 1).
  • the third-party application receives data for transmission to the wallet from the Internet service (step 2).
  • the wallet may use authentication services of the security element, eg. the UICC (steps 4 and 5).
  • the wallet forwards the authentication information to a wallet backend (step 6A).
  • the Wallet Backend contacts the service on the Internet for forwarding the authentication information edited by the Wallet (step 7A)
  • the wallet forwards the authentication information to the foreign application (step 6B).
  • the foreign application forwards the authentication information to the service on the Internet (step 7B).
  • the foreign application learns of the successful authentication of the Internet service (step 8).
  • the on-device APIs are used here in particular in steps 3 and 6B. Some of these steps are optional depending on the specific application scenario.
  • the integration of the safety function is optional.
  • the invention also makes it possible to use wallet services with rich functionality on such limited platforms.
  • the wallet can bundle payment functions and, in this case, "routing" from a third-party application that requires a payment to an app-implemented payment instrument in the wallet (eg a special credit card and not the existing EC card) Using security features of a security element, this payment app can use other mechanisms to secure the transaction.
  • the wallet backend used in variant A in the above example is located on a server of the wallet operator and is in turn addressed by the terminal via an Internet connection.
  • the background is to inform the Internet service about the correct execution of the payment via a merchant interface if the communication flow is to be used via steps 6A and 7A.
  • Wallet APIs can be implemented according to this scheme and connected to the wallet in step 3.
  • Interprocess communication mechanisms of the platform are used (for example, intents on Android platforms):
  • In-app purchase The third-party application initiates a payment process for the delivery of digital goods from a server on the Internet. Information about the type of goods as well as the price is passed on to the wallet.
  • In-app authentication The third-party application initiates a login to a server on the Internet (eg to access cloud data). The wallet will be given information about the type of login.
  • Personal data configuration for social network The social network app logs on to a social network on the Internet and forwards the request for personal information to the wallet. The wallet returns after consultation with the user, the personal data.
  • data is delivered digitally signed, with an applet on the security element, such as a
  • UICC e.g., age verification
  • on-device APIs Many more on-device APIs are possible.
  • the scenarios of "in-app purchase” and “in-app authentication” can be easily extended to a web browser (for example, the mobile web browser on a smartphone) instead of the third-party application.
  • This uses the URL mechanism of the platform for the on-device API, i.
  • the Internet service can address the Wallet app directly via certain web wallet URLs using the web browser.
  • further examples relating to the on-device API according to the invention are given in connection with voucher handling and loyalty scenarios. While the API is not limited to a particular class, any additional scenario can be supported. Definition and area of loyalty / voucher handling
  • Loyalty refers to a point-based bonus program targeting one or more merchants.
  • the user gets a certain amount of points, which are calculated based on a logic that defines the provider of the loyalty model. Therefore, each time the user makes a purchase, he forwards his customer loyalty identification number via the NFC / QR to the POS system, which calculates the bonus points and adds them to the user's account balance.
  • This loyalty style is POS-IT backend-focused, i. the wallet is responsible only for storing and forwarding the user's loyalty code. The loyalty bonus processing and administration is done via the POS system and the IT of the loyalty provider.
  • Vouchers allow certain groups of users to receive discounts or other benefits when making a purchase. Vouchers can be a discount (relative or absolute) to the entire cart or to dedicated products. Certain vouchers may also have conditions that must be met by the user to redeem the particular voucher (eg, pay for one, get two). The settlement of coupons is handled by the POS system. The motivation of the issuer of the voucher is to direct the behavior of the user by creating an incentive for certain products or buying patterns. Vouchers are generally meant to be used only once. Therefore, every used coupon must be validated. User Journeys
  • the current range of the electronic wallet (e.g., mWallet) on-device API allows the user to follow two user journeys.
  • the focus of the journey is on the voucher settlement scenario, but it can be applied to loyalty and other cards in the same way.
  • a journey is described wherein the user selects coupons in the third-party app and pays with the wallet:
  • Step One The user can pre-select wallet vouchers in the third party app and click on the "Pay with Wallet” button to proceed to further payment with the wallet (Figure 5a).
  • Step two The wallet appears and must be opened by the user with the wallet PIN. After successful authentication, the coupon dialog is shown ( Figure 5b).
  • Step three The user is free to choose additional vouchers or payment cards before starting the payment process. Vouchers can be selected from various third-party apps (Figure 5c). Step four: When the user has completed the card selection, payment can be started by clicking on the "Send" button ( Figure 5d). Step Five: An overview of all selected cards I is displayed while the user is prompted to connect the mobile phone to the NFC terminal. Alternatively, the user may be prompted to scan a set of QR codes at the POS ( Figure 5e). Referring now to Figure 6, an alternative journey is described in which the user selects third party coupons with the wallet:
  • Step one From the coupon selection view of the wallet, the user can start a registered third party app for coupon selection (Figure 6a).
  • Step two Vouchers can be selected in the Third Party application. Clicking the "Pay with Wallet” button will take the user back to the wallet and see an updated view of all selected coupons (Figure 6b).
  • Step three The user is free to select additional vouchers by selecting from their own wallet or third-party vouchers. The list of third party coupons may be filtered according to some criteria defined by the third party's application ( Figure 6c).
  • Step four When the user has completed the card selection, payment can be started by clicking the "Send" button ( Figure 6d).
  • Step Five An overview of all the selected cards I is displayed while the user is prompted to connect the mobile terminal to the NFC terminal. Alternatively, the user may be prompted to scan a set of QR codes at the POS ( Figure 6e).
  • Use Case 1 (Register Item Provider): The entry point for third-party apps as an item provider for using the on-device API is an introductory login Call. The item provider login notifies the wallet of the existence of the IP app on the mobile device and enables on-device features supported by the item provider. Preferably, use case 1 is mandatory.
  • Use Case 2 After booting the electronics, the wallet (e.g., mWallet) asks all registered item providers for available items. It is up to the IP to decide which items to return to the electronic wallet (e.g., mWallet). Depending on the application, these may be items preselected by the user, items of interest or all available items. Items of all providers are displayed to the user in a list view for the item usage and selection for an additional detail view. The wallet does not presume to store these items and only keeps temporary references to the items that are in the item provider application. Preferably, use case 2 is mandatory.
  • Use Case 3 Depending on the item usage scenario (payment, access key), the user can either select one or more items from different domains for a transaction.
  • the transport channel (NFC, QR, HTTP) prescribes whether the user must sequentially specify the data of the item of the interacting party or whether all item data can be transmitted in a user interaction.
  • the user when using the wallet, the user should be able to select one or more items before starting the transaction. For example, at an NFC point of sale, tokens for the selected items are requested from the item provider or a corresponding cardlet is activated. If the use of a specific is token-based, the item provider must return the requested token to the electronic wallet (eg mWallet).
  • use case 3 is mandatory.
  • Use Case 4 (Use item from Item Provider): The Item Provider can open the electronic wallet (eg mWallet) to use an item through specific capabilities of the electronic wallet (eg mWallet), such as NFC, QR code or HTTP.
  • Use Case 5 In the case of an NFC transaction, the wallet knows the final transaction status and will report the item usage to the item provider. Depending on the contract between the NFC interaction point and the item provider, additional item-specific data may be forwarded to the item provider. For example, redeemed vouchers can be validated and removed from the mobile wallet, or earned loyalty points can be added to the user's loyalty account. Preferably, use case 5 is mandatory.
  • Use Case 6 Items displayed in the Wallet can be removed or deleted by the user. The responsible item provider is notified about this action and should remove the item from the item list provided to the wallet. It is up to the provider to perform additional actions, such as physical deletion from local storage or in the backend of the provider. Preferably, the use case 5 is optional.
  • Use Case 7 Item that is issued, for example, at a point of sale and retrieved from the mWallet via an NFC or scanning a QR code is imported by the electronic wallet (eg mWallet) passed on to the appropriate item provider application.
  • Use Case 8 (Define Default Item): Items can be marked as default items in the electronic wallet (e.g., mWallet). The default item (one per domain) is used as default without explicit selection. The item provider is notified if an item is set as default or if its setting is canceled. It is up to the IP to perform any actions, such as enabling or disabling a corresponding cardlet.
  • Use Case 9 (Item Call):
  • the electronic wallet eg mWallet
  • the electronic wallet can request dynamic item data from the item provider that will be used to get item details display. For example, this may be the actual number of loyalty points, the name of the owner, or the balance. If the item includes HTML-specific JavaScript code, the Wallet will query item-specific dynamic data at the Item Provider.
  • Use Case 10 To add additional items to the electronic wallet (e.g., mWallet), the item provider can provide a catalog from which the user can select additional items. For example, these can be found as 'should be provisioned to the wallet' or accessed online and physically imported into the provider's data store.
  • the item provider can provide a catalog from which the user can select additional items. For example, these can be found as 'should be provisioned to the wallet' or accessed online and physically imported into the provider's data store.
  • Permits required and enforced by the electronic wallet e.g., mWallet.
  • this requirement is mandatory.
  • the UICC can be used as a security anchor (prerequisite: OTA channel available). Preferably, this requirement optional.
  • the communication channel should be protected in an acceptable manner. Preferably, this requirement is optional.
  • the electronic wallet (e.g., mWallet) on-device API allows third party applications - so-called item providers (IP) - to benefit from the wallet functionality. For example, it allows items to be called in different transactions.
  • IP item providers
  • the on-device API targets multiple functional wallet components, resulting in two interfaces, which are described in detail below.
  • Wallet interface Wallet transactions, Item Provider registration, Payment and IdM;
  • Item Provider interface Wallet API with item management functionality.
  • Fig. 7 relationships are provided between components and the interfaces provided and used.
  • further elements of a complete wallet ecosystem on the UICC and backend side are shown by way of example.
  • the Wallet App which offers the Wallet Interface, which can use third party applications on the device to communicate with the Wallet.
  • third party applications from the areas of couponing and loyalty are shown, which use this interface.
  • applets are shown on the UICC or the Secure Element, which are managed by the Wallet.
  • the backend area also shows the backend systems of both the wallet and third party applications that communicate over the Internet with the corresponding client applications on the end device.
  • the on-device API defined below is an abstract API that can be mapped to mobile platforms, such as Android or Windows 8, as long as the mobile platform provides an IPC mechanism between apps, which does not require user interaction.
  • the following are the platform-specific implementation topics.
  • the wallet interface contains all the operations that are called by item providers.
  • AccessToken knows: tokens,
  • Item Provider Interface The following table lists operations that are implemented by the Item Provider App and should be called by the Wallet, if available.
  • the item provider ItemData IP-advice, a new item-specific identifier
  • Primitive data types are basic data types, such as string, integer, or arrays, that have restricted ranges of values such as enumerations.
  • the on-device API uses the following primitive types:
  • This data may be GS1 encoding or something else. Syntax and semantics must be understood between the IP and the interaction point.
  • Complex data types are compound data types that contain multiple element attributes.
  • the display token consists of the following attributes:
  • imageUrl URL URL that points to the image to be displayed.
  • the picture could be dynamic
  • Contain data such as loyalty points or the coupon product or discount to be presented to the user.
  • the attribute is optional if imageEmbedded exists.
  • Android is designed to host a variety of applications and maximize user choice.
  • the platform is intended to eliminate the duplication of functionality in various applications, to allow functionality to be spontaneously found and accessed, and to have users replace applications with others that provide similar functionality.
  • Applications must have as few dependencies as possible and must be able to assign operations to other applications that may change at the user's discretion.
  • Interprocess communication is therefore the basis for some key features of the Android programming model.
  • the technique for the on-device API relevant techniques are:
  • Intents can be sent to any recipient as a broadcast.
  • Intents can be sent to a specific recipient, and results are ignored.
  • Intents can be sent to a specific recipient and the sender will be notified of the results.
  • intents will be the start option 2 - Activity.startActivity () or the start option Activity. use startActivityForResult ().
  • the item retrieval operation will use another more efficient IPC mechanism provided by the Android named ContentProvider.
  • Content Providers manage the access to a structured data record.
  • Content Providers are the standard interface that connects data in one process with code that runs in another process.
  • Wallet interface illustration
  • the login intent sent by Item Providers informs the electronic wallet (e.g., mWallet) of the existence of the handset. In addition to the name, description, and image of the provider, it places its endpoint URI to the ContentProvider for querying DisplayTokens, and an Intent action prefix used by the electronic wallet (such as mWallet) to return the ItemProvider's intentions-based operations. Call the interface, ready.
  • the login intent should be sent on two events:
  • mWallet is sent as a broadcast.
  • the intent for mapping the login operation is defined by the following attributes:
  • the useltem operation can be called from the item provider app to open the electronic wallet (e.g., mWallet) with a preselected item that can be invoked immediately.
  • the electronic wallet e.g., mWallet
  • the IP application When retrieving a register intent that is sent as a broadcast to the Android system when the electronic wallet starts up (eg mWallet), the IP application should send the login intent defined above to the electronic wallet (eg mWallet).
  • the IP application To retrieve the broadcast intent, the IP application must implement a class that extends the BroadcastReceiver class of Android and overrides the onReceive () method.
  • the mWallet will call the android.content.ContextWreapper.sendBroadcast (Intent intent) - ethode with the following Intent attributes:
  • the operations getltems () and getDisplayToken () of the IP interface are implemented using ContentProvider feature.
  • the wallet uses the ContentProvider mechanism to query and update data provided by the IP app.
  • the IP App must implement a ContentProvider that conforms to the definitions described below.
  • the manifest defmitions of the provider should be as follows:
  • the ContentProvider should provide a table that is addressed by the following attributes: Authortty: content: / / ⁇ YOUR_AUTHORITY>
  • a single card item should be accessible through the URI:
  • the item table is intended to provide the following list of columns, which are attributes of the display token as defined above, plus some parameters required to map the ⁇ interface operations to the Android ContentProvider mechanism.
  • imageUrl String maps to display Token.imageUrl
  • the cursor instances returned by the ContentProvider.query () operation should have the provider content URI set with cursor.setNotificationUri (CONTENT_URI). This is a mandatory condition for a later change message if the record is changed. For example, refer to the removeItem () operation described below. Intent imaging
  • getToken is a mandatory operation called by the electronic wallet (e.g., m Wallet) to retrieve tokens to be used within a transaction.
  • the token is displayed via QR code, transmitted via NFC, or sent as an HTTP request to a callback URI.
  • mapping for this operation is defined by the following attributes:
  • the getToken operation is called with Activiry.startActivityforResult () and expects a result intent with the following attributes.
  • the notifyUsage operation is called by the electronic wallet (eg, mWallet) when an item has been used in a transaction. It is up to the IP to interpret the payload parameters or to take any action on this event. For example, one-time items can be marked as redeemed and removed from the wallet.
  • the intent for mapping this operation is defined by the following attributes:
  • the removeltem operation is called by the electronic wallet (e.g., mWallet) when the user deletes an item. It is up to the IP to delete the item from its own data store, but the item should no longer appear in the cursor returned with the next ContentProvider query () call.
  • the electronic wallet e.g., mWallet
  • mapping this operation is defined by the following attributes:
  • the implementing IP should call context.getContentResolver (). NotifyChange (CardProvider.CARD_CONTENT_URI, null) to trigger the update of the electronic wallet view (eg mWallet).
  • importItem When provided by the item provider, the importltem operation is called by the electronic wallet (eg mWallet) when a new item is received. For example, as a result of a payment transaction, a coupon may be issued. It is up to the IP to interpret the data and store the item in its own data store. The item should appear in the cursor returned with the next ContentProvider query () call.
  • mapping this operation is defined by the following attributes:
  • the implementing IP should call context.getContentResolver (). NotifyChange (CardProvider.CARD_CONTENT_URI, null) to trigger the update of the electronic wallet view (e.g., mWallet). setDefault () If provided by the item provider, the setDefault operation is called by the electronic wallet (e.g., mWallet) when an item is marked as a default item. For example, a payment card may be preselected for transactions to ensure a fast payment or a low power mode. It's up to the IP to activate a cardlet or do some other action.
  • the intent mapping for this operation is defined by the following attributes:
  • the unsetDaul operation When provided by the item provider, we call the unsetDaul operation from the electronic wallet (e.g., mWallet) when the setting of a default item is overridden.
  • the intent for the mapping for this operation is defined by the following attributes:
  • the invoceltem operation is called by the electronic wallet (e.g., mWallet).
  • the electronic wallet e.g., mWallet
  • a Java script in the detailed description HTML can call a wallet.invoke operation and pass any kind of parameters to it.
  • a JSON string is passed here.
  • the electronic wallet e.g., mWallet
  • the electronic wallet will forward this item to the item provider by invoking the invoceltem operation. It is up to the IP to interpret the parameter and return a result JSON string passed from the electronic wallet (e.g., mWallet) to the WebView. In this way, dynamic information of an item, such as the number of loyalty points, can be displayed.
  • mapping this operation is defined by the following attributes:
  • the operation is called with Activity.startAcivityforResult () and expects a result intent with the following attributes.
  • launchCatalogue When provided by the Item Provider, the launchCatalogue operation is called by the electronic wallet (e.g., mWallet). It is expected that the ⁇ application will open and provide the user with a list of additional items that can be placed in the wallet.
  • the intent for mapping this operation is defined by the following attributes:
  • a secure on-device API is critical to preventing the wallet feature and data from unregistered third-party apps from being accessed.
  • An unsecured API would provide numerous opportunities for hostile applications that could add spam data to the wallet or collect critical data. Nonetheless, there will be some methods that can be freely used by any application, and others that can only be used in the case of strong authentication.
  • the on-device API is under the control of the provider. Since this requirement conflicts with the security architecture of some mobile operating systems, at the level of On-device API additional protection mechanisms are defined. In addition, the user is free to grant an app of a third party at the OS level the right to access the wallet.
  • the wallet supports various types of items, such as coupons, loyalty cards, payment cards and more in the future. It is obvious that potential losses and damages are quite different for each manifestation of card types.
  • the registered third-party apps are assigned a protection profile during the registration process on the DT. The assigned profile defines the security measures that the app must comply with. Depending on the assigned profile, a limited set of functions is available on Wallet's on-device API. Allocation is agreed between DeutscheInstitut and the third party developer based on a risk and business analysis for the third party, the card issuer and the end user.
  • the wallet implements all defined protection profiles. It knows the association between a third party app and the associated protection profile, which ensures that the third party app authenticates itself with the correct authentication mechanism and credentials. In addition, the Wallet will be updated with new assignments if the new third party app is registered in a Wallet backend system and accepted by DT. Fig. 8 shows these dependencies.
  • Security measures assume a non-compromising mobile operating system. If the system is affected by malicious programs, such as key loggers or spyware, the measures can be bypassed.
  • the app provider should be sensitive to possible damage caused by the app to the end user or on the card issuer's site if abused or maliciously altered.
  • the decision as to which protection profile the developer should choose is a compromise between the potential for harm and expense for app development and key distribution.
  • Anonymous profile (Fig. 9)
  • the anonymous profile can not be seen as a true protection profile because any third-party application unknown to the wallet will be sorted into that profile. It does not require credentials that must be submitted by the third party app to identify the application.
  • the profile targets apps that want to use only a subset of noncritical functions provided by the wallet that are shared for use by each application.
  • Figure 9 shows the measures that must be taken at a high level to use the unprotected on-device API.
  • the minimal protection profile aims to protect the Wallet against the unexpected use of the on-device API to prevent damage and misuse by third-party apps at the level of basic protection. It provides assurance of low development and organizational costs for third-party developers or card issuers. But it does not protect against malicious attacks since it it will be possible to spy on credentials with some effort in spying or revising.
  • This profile targets apps with no potential for harm to the end user and minimal potential damage to the card issuer. For example, it works with free coupon apps or loyalty card apps that can not cause financial harm to the end user due to the functional nature of the card.
  • the damage potential for the card user can be limited in combination with unique card IDs and real-time validation at the point of sale during redemption.
  • a single identifier for a third party app acts as the same identifier across all third party installations.
  • Fig. 10 shows the one-time actions taken at a high level for using the on-device API.
  • Strong protection profile (Fig. 1 1)
  • the strong protection profile aims to protect the wallet to prevent damage and misuse by malicious third-party apps. It ensures cryptographically that the wallet is aware of and trusted by a third-party app. As a result, development and key deployment efforts are not trivial.
  • the profile protects the wallet against the use of unregistered third-party apps and does not allow a revocation of credentials. It targets apps with significant potential damage for the user and the card issuer. For example, it fits gift card or money-worthy cards, and possibly payment cards.
  • the Wallet application ID is unique to all Wallet installations on different mobile phones. Individual credentials must be verifiable by third-party apps.
  • Each identifier of a third-party app will act as a single identifier in the wallet domain.
  • Fig. 11 shows the individual measures which must be taken for using the on-device API at a high level.
  • the first step in communicating with a third party / wallet app is the registration phase, where a third party app is promoted to the wallet ecosystem and vice versa.
  • a third party app is promoted to the wallet ecosystem and vice versa.
  • some of the registration details differ from profile to profile. Details are described per profile in the next two subsections. Registration process for anonymous profile
  • the minimal protection profile defines the authentication mechanism between the third-party app and the wallet based on a shared secret.
  • the Wallet ecosystem needs to know the secret of a third party app, and a third party app needs to know the secret of the wallet.
  • the sharing of shared keys is done in the registration process, with the third party developer registering the app after developer registration and login to the DT wallet backend.
  • sharedKey Enter shared key from the third party app
  • this can be a generated random key or the digital signature of the installation package.
  • Authentication should be used. Depending on the OS capabilities, this may be a generated random key or the digital signature of the installation package
  • the third party developer is responsible for packing the three parameters into the installation package or for deploying the information after installing the app, for example through its own backend system.
  • Every installation (wallet and third-party app) in the Wallet ecosystem acts as a single identifier. This increases the number of existing identifiers, which requires either a strict assignment between the wallet and the installations of a third-party app or a certificate hierarchy that helps to reduce the tag management overheads.
  • the third party app is registered by the developer on the wallet backend.
  • the following parameters are exchanged:
  • registrationURL output The URL used by the third party app in the second
  • the second registration step must be performed by the third-party app and wallet and will take place after the application is installed on the mobile phone.
  • the application of a third party and the wallet must generate a private / public key pair that is used by the application (in the case of the Wallet
  • UICC UICC
  • the URL was retrieved in the first step and packaged in the app installation package.
  • the backend will check the sender's ID based on the mobile network and booked service offerings.
  • This parameter contains the CA certificate (s) for the
  • this parameter will include the wallet Ca cert to verify the wallet
  • the signed certificate and the Wallet CA certificate are returned to the installation of a third-party app.
  • the certificate in combination with a signature is passed to the wallet during the authentication process by a third-party app.
  • the Wallet CA cert is used to verify the Wallet's mutual authentication certificate.
  • the parties Before the wallet's on-device API can be used, the parties must authenticate each other. Depending on the agreed protection profile, the app must provide specific credentials and must use a profile-specific authentication method provided by the Wallet API.
  • the wallet processes the login call and verifies the credentials, and finally acts as a security token service issuing a session token.
  • the session token contains a temporary session key and additional attributes needed later to calculate an access token to be passed with each API call.
  • the resulting session token is independent of specific protection profiles and has the following format:
  • Session ID Unique identifier Pid Process identifier of the calling application to ensure that the token is issued by the correct process (pid of the caller must be during the
  • encSessionkey The shared session key used to calculate and verify access tokens on subsequent API calls.
  • the session key is encrypted with the wallet credentials that are the shared key in the minimum PP or the wallet's private key if the strong PP is used. Encryption prevents anyone else from getting the secret of the session,
  • signature A signature signs all token attributes to prevent modification of the token during transit.
  • the signature is generated with the credentials of the wallet, which are the shared keys in the minimum PP or the private keys of the wallet using the strong PP.
  • Apps that are not registered with the wallet require a session token to calculate a one-time access token on every API call.
  • the session token is retrieved by calling the login method without passing any credentials.
  • the wallet will assign the session to the anonymous profile and allow only the invocation of methods whose use is free for each application. Authentication process for minimal protection profile
  • the minimum protection profile-defined authentication is based on a shared secret between the wallet and a third-party app.
  • Third party apps authenticate to the wallet by calling the login method.
  • the shared key does not become direct passed on with the call.
  • the fragmented key is used to calculate an HMAC that is passed with the call.
  • the login method provides the following parameters:
  • the wallet first checks the assignment of the application identifier and the protection profile. If the wallet knows the app's assignment to the minimal protection profile, then the HMAC provided is verified by performing the same steps as the third party app did by using the shared reasoning registered for the given application identifier. If successful, a session token including the temporary session key and another HMAC for authenticating the wallet will be generated and returned to the third party app.
  • a third-party app is free to validate the returned HMAC to validate the Wallet's identifier. Authentication process for the strong protection profile
  • the strong protection profile-defined authentication is based on a digital signature that is calculated using the app's private key and a certificate hierarchy. On the third party and wallet side, the same mechanism is used to enable mutual authentication.
  • Third party apps authenticate to the wallet by calling the login method, providing the following parameters:
  • the wallet returns a new hmac using the same computation rules, but its own shared key, which is known to the third-party app through the registration process.
  • the wallet first checks the assignment of the application identifier and the protection profile. If the wallet knows of the allocation of the strong protection pro, the given digital signature is validated. This is done by decrypting the signature with the given certificate and then comparing the decrypted hash value to the result of its own hash computation following the same steps as the third party app did. A final certificate must be validated and checked to see if it is trusted, which means that it will be issued by one of the familiar CA certs known to the wallet. The wallet returns a session token, including a temporary symmetric key and additional attributes used for further on-device API calls. A third-party app is free to validate the returned HMAC to verify the wallet's identifier. On-device API usage process
  • the on-device API can only be used if the third-party app has successfully authenticated to the wallet and retrieves a session token. It can use any Wallet API operation that belongs to the protection profile that the app complies with. For example, a coupon application can use all the methods shown by the CoreWallet interface and coupon interface.
  • the API call is processed by the wallet only if the first parameter of the
  • the access token is a unique token and is sent by the sender of the message (either the app of a third party)
  • the access token format is a custom format that is similar to popular standardized token formats that unfortunately
  • Target network communication protocols that do not necessarily apply to the Wallet On-Device API.
  • OAuth is married to HTTP and SAML to the XML format, but the on-device API can be mapped to the planned mechanism of Android.
  • the access token consists of the following attributes:
  • Sessionld identifier that identifies the current session (token)
  • Including a nonce and a timestamp in the signature calculation ensures that the access token is valid for single use only and prevents replay attacks in the event that another process on the mobile has caught an API call.
  • the access token Before processing the API call functionality, the access token must be validated at the receiver side.
  • the signature is validated by computing the HMAC signature by processing the same computation steps as the sender did, but using the shared token from the session token.
  • the attributes of the session token are validated. This step validates the validFrom and validTo attributes of the session token and matches the process ID of the sender with the PID in the Session tokens. Only if both tokens are successfully validated will the method be processed.
  • the invention also includes individual features in the figures, even if they are shown there in connection with other features and / or not mentioned above.

Abstract

Die Erfindung betrifft ein Verfahren und ein System zur endgerätebasierten Kommunikation zwischen Fremdanwendungen und einem elektronischen Wallet. Das Verfahren weist dabei 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.

Description

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.
Figure imgf000024_0001
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.
Figure imgf000025_0001
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
Figure imgf000033_0001
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/Cards/#<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.

Claims

Patentansprüche
1. Verfahren zur endgerätebasierten Kommunikation zwischen einer Fremdanwendung und einem elektronischen Wallet, wobei:
das elektronische Wallet auf einem Endgerät installiert ist;
die Fremdanwendung auf dem Endgerät installiert ist;
mit den Schritten:
Aufbauen einer Verbindung zu einem Internetservice durch die Fremdanwendung,
wobei die Verbindung eine Übertragung von Daten an den Internetservice erfordert;
Empfangen einer auf die Übertragung der genannten Daten gerichteten Anfrage des Internetservices durch die Fremdanwendung;
Weiterleiten der vom Internetservice empfangenen Anfrage an das elektronische Wallet durch die Fremdanwendung;
Verarbeiten der Anfrage und Generieren einer entsprechenden Antwort durch das elektronische Wallet;
Weiterleiten der Antwort vom elektronischen Wallet an den Internetservice;
Empfangen einer Bestätigung über die erfolgte Weiterleitung der Antwort an den Internetservice, wobei das Empfangen durch die Fremdanwendung erfolgt, wobei ferner ein Sicherheitselement mit dem Endgerät verbunden ist; und
wobei der Schritt des Verarbeitens der Anfrage und Generierens einer Antwort die Schritte aufweist:
Senden einer Anfrage bezüglich der genannten Daten an das Sicherheitselement durch das elektronische Wallet; und
Empfangen einer Antwort bezüglich der genannten Daten vom Sicherheitselement durch das elektronische Wallet.
2. Verfahren nach Anspruch 1 , wobei das Sicherheitselement für die drahtlose Funkkommunikation, beispielsweise funkbasierte Nahbereichskommunikation (NFC), konfiguriert ist.
3. Verfahren nach Anspruch 1 oder 2, wobei das Sicherheitselement eine Universelle Karte mit integriertem Schaltkreis (Universal Integrated Circuit Card, UICC) oder eine SIM-Karte ist.
4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Endgerät zur Mobilfunkkommunikation geeignet ist und/oder zur WLAN-Kommunikation geeignet ist.
5. Verfahren nach Anspruch 4, wobei das Endgerät ein Mobilfunkgerät, ein Smartphone, Laptop, Notebook oder ein Tablet Computer ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, wobei die Daten vertrauliche und/oder nutzerspezifische Informationen aufweisen, beispielsweise:
Informationen zur Authentisierung, vorzugsweise Daten für ein Login oder für einen Bezahl Vorgang; und/oder
persönliche Daten.
7. Verfahren nach einem der Ansprüche 1 bis 6, wobei der Schritt des Weiterleitens der Daten die folgenden Schritte aufweist:
Ü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.
8. Verfahren nach einem der Ansprüche 1 bis 6, wobei Schritt 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.
9. Verfahren nach einem der Ansprüche 1 bis 8, wobei die Fremdanwendung eine auf dem Endgerät installierte Dienstanbieter-Anwendung ist, die für die Nutzung des
Internetdienstes konfiguriert ist, oder ein auf dem Endgerät installierter Internet-Browser.
10. System zur endgerätebasierten Kommunikation zwischen ein oder mehreren Fremdanwendung(en) und einem elektronischen Wallet,
wobei das System ein Endgerät aufweist, und
wobei das System dadurch gekennzeichnet ist, dass:
auf dem Endgerät ein elektronisches Wallet installiert ist;
auf dem Endgerät eine oder mehrere Fremdanwendung(en) installiert sind;
wobei:
die Fremdanwendung(en) jeweils konfiguriert sind:
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;
zum Weiterleiten der vom Internetservice empfangenen Anfrage an das elektronische Wallet;
das elektronische Wallet konfiguriert ist:
zum Verarbeiten der genannten Anfrage und Generieren einer entsprechenden Antwort;
zum Weiterleiten der Antwort an den Internetservice;
die Fremdanwendung(en) jeweils ferner konfiguriert sind zum:
Empfangen einer Bestätigung über eine erfolgte Weiterleitung an den Internetservice, wobei das Empfangen durch die Fremdanwendung erfolgt, wobei ferner:
das Endgerät konfiguriert ist zur Aufnahme eines oder mehrerer Sicherheitselemente;
auf dem Endgerät eine oder mehrere Programmierschnittstelle(n) (APIs) zum Auflisten, Auswählen und Interagieren mit den Sicherheitselementen installiert sind;
wobei das System ferner ein oder mehrere Sicherheitselement(e) aufweist, die in das Endgerät aufgenommen sind, wobei das Endgerät mit dem einen oder den mehreren Sicherheitselement(en) verbunden ist; und
wobei das elektronische Wallet in Bezug auf das Verarbeiten der genannten Anfrage und das Generieren einer entsprechenden Antwort ferner konfiguriert ist: 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).
1 1. System nach Anspruch 10, wobei vorzugsweise das Sicherheitselement für die drahtlose Funkkommunikation, beispielsweise funkbasierte Nahbereichskommunikation (NFC), konfiguriert ist.
12. System nach Anspruch 10 oder 11, wobei das Sicherheitselement eine Universelle Karte mit integriertem Schaltkreis (Universal Integrated Circuit Card, UICC) oder eine SIM-Karte ist.
13. System nach einem der Ansprüche 10 bis 13, wobei das Endgerät zur Mobilfunkkommunikation geeignet ist und/oder zur WLAN-Kommunikation geeignet ist.
14. System nach Anspruch 14, wobei das Endgerät ein Mobilfunkgerät, ein Smartphone, Laptop, Notebook oder ein Tablet Computer ist.
15. System nach einem der Ansprüche 10 bis 14, wobei die Daten vertrauliche und/oder nutzerspezifische Informationen aufweisen, beispielsweise:
Informationen zur Authentisierung, vorzugsweise Daten für ein Login oder für einen Bezahlvorgang; und/oder
persönliche Daten.
16. System nach einem der Ansprüche 10 bis 15, wobei:
das elektronische Wallet in Bezug auf das Weiterleiten der Antwort an den Internetservice ferner konfiguriert ist:
zum Übermitteln der Daten an ein Wallet Backend; wobei
das Wallet Backend konfiguriert ist:
zum Herstellen einer Verbindung zwischen dem Wallet Backend und dem
Internetservice;
zum Übermitteln der Daten an den Internetservice.
17. System nach einem der Ansprüche 10 bis 15, wobei:
das elektronische Wallet in Bezug auf das Weiterleiten der Antwort an den Internetservice ferner konfiguriert ist:
zum Übermitteln der Daten an die Fremdanwendung(en); und
die Fremdanwendung(en) jeweils konfiguriert sind:
zum Übermitteln der Daten an den Internetservice.
18. System nach einem der Ansprüche 10 bis 17, wobei die Fremdanwendung eine auf dem Endgerät installierte Dienstanbieter-Anwendung ist, die für die Nutzung des Internetdienstes konfiguriert ist, oder ein auf dem Endgerät installierter Internet-Browser.
PCT/EP2013/076885 2012-12-19 2013-12-17 Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet WO2014095850A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP13821459.8A EP2936406A1 (de) 2012-12-19 2013-12-17 Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet
US14/653,321 US9898734B2 (en) 2012-12-19 2013-12-17 Method and system for terminal device-based communication between third-party applications and an electronic wallet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP12198252.4 2012-12-19
EP12198252 2012-12-19

Publications (1)

Publication Number Publication Date
WO2014095850A1 true WO2014095850A1 (de) 2014-06-26

Family

ID=47471559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/076885 WO2014095850A1 (de) 2012-12-19 2013-12-17 Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet

Country Status (3)

Country Link
US (1) US9898734B2 (de)
EP (1) EP2936406A1 (de)
WO (1) WO2014095850A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3059918A1 (de) * 2015-02-23 2016-08-24 Giesecke & Devrient GmbH Verfahren zum zugriff auf ein sicherheitselement
EP3265973A4 (de) * 2015-03-03 2018-10-24 Mastercard Asia/Pacific Pte. Ltd. Verfahren zur standardisierung der kommunikation zwischen einer vielzahl von einlösungsanwendungen
WO2022101437A1 (fr) * 2020-11-13 2022-05-19 Banks And Acquirers International Holding Procédé de traitement d'une opération impliquant des données secrètes, terminal, système et programme d'ordinateur correspondant

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839321B2 (en) 1997-01-06 2020-11-17 Jeffrey Eder Automated data storage system
KR20140105682A (ko) * 2013-02-22 2014-09-02 삼성전자주식회사 월렛 구성요소에 관한 제휴 정보를 전달하는 단말 장치 및 그 제어 방법
US10068228B1 (en) * 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US10354325B1 (en) 2013-06-28 2019-07-16 Winklevoss Ip, Llc Computer-generated graphical user interface
US9892460B1 (en) 2013-06-28 2018-02-13 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US9602949B2 (en) * 2013-12-11 2017-03-21 Capital One Financial Corporation Systems and methods for populating online applications using third party platforms
CN105099984B (zh) * 2014-04-16 2019-07-02 百度在线网络技术（北京）有限公司 一种app间账号互通的方法和装置
US9807612B2 (en) * 2014-04-25 2017-10-31 Tendyron Corporation Secure data interaction method and system
US10084601B2 (en) * 2014-06-17 2018-09-25 Sony Corporation Method, system and electronic device
US9769122B2 (en) * 2014-08-28 2017-09-19 Facebook, Inc. Anonymous single sign-on to third-party systems
US9825934B1 (en) * 2014-09-26 2017-11-21 Google Inc. Operating system interface for credential management
TWI599903B (zh) * 2014-12-31 2017-09-21 鴻海精密工業股份有限公司 電子裝置的加解密系統及其加解密方法
KR101680525B1 (ko) * 2016-07-12 2016-12-06 김주한 앱 위변조 탐지 가능한 2채널 인증 대행 시스템 및 그 방법
CN111615105B (zh) * 2016-07-18 2023-08-04 创新先进技术有限公司 信息提供、获取方法、装置及终端
US10630682B1 (en) * 2016-11-23 2020-04-21 Amazon Technologies, Inc. Lightweight authentication protocol using device tokens
CN107018063A (zh) * 2017-01-19 2017-08-04 阿里巴巴集团控股有限公司 基于应用的数据交互方法及装置
US11669828B1 (en) * 2017-02-14 2023-06-06 Wells Fargo Bank, N.A. Mobile wallet artificial intelligence card underwriting
GB2561396B (en) * 2017-04-13 2020-07-15 Barclays Execution Services Ltd Data security using two operating environments operating in parallel
US11277269B2 (en) * 2017-12-13 2022-03-15 Arista Networks, Inc. System and methods for generating and authenticating verifiable network traffic
US10438290B1 (en) 2018-03-05 2019-10-08 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11909860B1 (en) 2018-02-12 2024-02-20 Gemini Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11025595B2 (en) 2018-04-16 2021-06-01 Samsung Electronics Co., Ltd. Secure and anonymous data sharing
US10922678B2 (en) * 2018-04-24 2021-02-16 Visa International Service Association System, method and computer program product for automatic and remote control of NFC transaction processing
WO2020006425A1 (en) * 2018-06-28 2020-01-02 Coinbase, Inc. Wallet recovery method
US11392924B2 (en) * 2019-09-11 2022-07-19 Ebay Inc. In-person transaction processing system
CN114222988A (zh) * 2019-09-29 2022-03-22 深圳市欢太科技有限公司 支付处理方法、装置、电子设备以及存储介质
CA3153291A1 (en) * 2019-10-02 2021-04-08 Evan Lerner Client device authentication using contactless legacy magnetic stripe data
CN111541542B (zh) * 2019-12-31 2023-09-15 远景智能国际私人投资有限公司 请求的发送和验证方法、装置及设备
CN112511510B (zh) * 2020-11-18 2022-09-30 中国建设银行股份有限公司 一种授权认证方法、系统、电子设备及可读存储介质
CN112732288A (zh) * 2020-12-11 2021-04-30 北京握奇智能科技有限公司 一种数字货币硬件钱包应用升级的方法和装置
US11074142B1 (en) * 2021-01-15 2021-07-27 Coupang Corp. Systems and methods for automatically resolving system failure through force supplying cached API data
US11546159B2 (en) 2021-01-26 2023-01-03 Sap Se Long-lasting refresh tokens in self-contained format
US11757645B2 (en) 2021-01-26 2023-09-12 Sap Se Single-use authorization codes in self-contained format
CN113672460B (zh) * 2021-08-19 2023-10-03 北京奇艺世纪科技有限公司 一种服务监控方法及装置
US11966460B2 (en) * 2022-01-25 2024-04-23 Dell Products, L.P. Facilitating generation of credentials and verification thereof within a distributed object storage system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006085805A1 (en) * 2005-02-14 2006-08-17 Smarttrust Ab Method for performing an electronic transaction
US20090234751A1 (en) * 2008-03-14 2009-09-17 Eric Chan Electronic wallet for a wireless mobile device
WO2012021864A2 (en) * 2010-08-12 2012-02-16 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
US20120123868A1 (en) * 2010-11-17 2012-05-17 David Brudnicki System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
US20120130839A1 (en) * 2006-09-24 2012-05-24 Rfcyber Corp. Mobile devices for commerce over unsecured networks
US20120166337A1 (en) * 2010-12-23 2012-06-28 Kt Corporation Near field communication terminal for performing secure payment and secure payment method using the same

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120266220A1 (en) * 2010-11-17 2012-10-18 Sequent Software Inc. System and Method for Controlling Access to a Third-Party Application with Passwords Stored in a Secure Element

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006085805A1 (en) * 2005-02-14 2006-08-17 Smarttrust Ab Method for performing an electronic transaction
US20120130839A1 (en) * 2006-09-24 2012-05-24 Rfcyber Corp. Mobile devices for commerce over unsecured networks
US20090234751A1 (en) * 2008-03-14 2009-09-17 Eric Chan Electronic wallet for a wireless mobile device
WO2012021864A2 (en) * 2010-08-12 2012-02-16 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
US20120123868A1 (en) * 2010-11-17 2012-05-17 David Brudnicki System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
US20120166337A1 (en) * 2010-12-23 2012-06-28 Kt Corporation Near field communication terminal for performing secure payment and secure payment method using the same

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ERIKA CHIN ET AL: "Analyzing inter-application communication in Android", MOBISYS '11, ACM, US, 28 June 2011 (2011-06-28), pages 239 - 252, XP058004575, ISBN: 978-1-4503-0643-0, DOI: 10.1145/1999995.2000018 *
See also references of EP2936406A1 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3059918A1 (de) * 2015-02-23 2016-08-24 Giesecke & Devrient GmbH Verfahren zum zugriff auf ein sicherheitselement
WO2016134837A1 (en) * 2015-02-23 2016-09-01 Giesecke & Devrient Gmbh Method for accessing a security element
EP3265973A4 (de) * 2015-03-03 2018-10-24 Mastercard Asia/Pacific Pte. Ltd. Verfahren zur standardisierung der kommunikation zwischen einer vielzahl von einlösungsanwendungen
TWI671694B (zh) * 2015-03-03 2019-09-11 Mastercard Asia/Pacific Pte Ltd 規範複數個兌換應用程式間之通訊的方法、託管處理應用程式的接收終端、非臨時性電腦可讀取媒介以及安裝複數個兌換應用程式的行動終端
WO2022101437A1 (fr) * 2020-11-13 2022-05-19 Banks And Acquirers International Holding Procédé de traitement d'une opération impliquant des données secrètes, terminal, système et programme d'ordinateur correspondant

Also Published As

Publication number Publication date
US20150348015A1 (en) 2015-12-03
EP2936406A1 (de) 2015-10-28
US9898734B2 (en) 2018-02-20

Similar Documents

Publication Publication Date Title
WO2014095850A1 (de) Verfahren und system zur endgerätebasierten kommunikation zwischen fremdanwendungen und einem elektronischen wallet
CN109478298B (zh) 区块链实现的方法和系统
EP3207661B1 (de) Identitätsinfrastruktur als dienstleistung
US7849204B2 (en) Distributed network identity
EP2533172B2 (de) Gesicherter Zugriff auf Daten in einem Gerät
JP5423397B2 (ja) アクセス権限管理システム、アクセス権限管理方法及びアクセス権限管理用プログラム
CN1829227B (zh) 在单个用户范例中集成多个身份、身份机制和身份提供者的方法和系统
DE60007883T2 (de) Verfahren und vorrichtung zum durchführen von elektronischen transaktionen
US9825917B2 (en) System and method of dynamic issuance of privacy preserving credentials
DE102011082101A1 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP3909221B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
DE102018005038A1 (de) Smartcard als Sicherheitstoken
CN108319827A (zh) 一种基于osgi框架的api权限管理插件及方法
EP3908946B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
US8181257B2 (en) Method to allow role based selective document access between domains
CN116915493A (zh) 安全登录方法、装置、系统、计算机设备和存储介质
Akram et al. A novel consumer-centric card management architecture and potential security issues
Kilian-Kehr Mobile Security with Smartcards
US7836510B1 (en) Fine-grained attribute access control
EP2397960B1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token über eine Telekommunikations-Chipkarte und ein Server-Computersystem
Rech et al. A decentralized service-platform towards cross-domain entitlement handling
Dmitrienko et al. Market-driven code provisioning to mobile secure hardware
RU92592U1 (ru) Система идентификации пользователя подвижной радиотелефонной связи на основе абонентского номера в сети подвижной радиотелефонной связи
Gomez-Skarmeta et al. User-Centric Privacy Management in Future Network Infrastructure
EP4092958A1 (de) Ausstellen eines digitalen verifizierbaren credentials

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13821459

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
REEP Request for entry into the european phase

Ref document number: 2013821459

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14653321

Country of ref document: US

Ref document number: 2013821459

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE