DE102013022448B3 - Electronic transaction process and computer system - Google Patents

Abstract

Electronic transaction method using an ID token (106) that is assigned to a user (102), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, wherein access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reading device of a user computer system (100), with the following Steps: - Establishment of a first session (201) between an application program (112) and a service computer system (150) via a network (116), - Reception of a transaction request (158) via the first session by the service computer system from the application program (112), - generation of a request (166) by the service computer system based on the receipt of the transaction request, the request being signed by the service computer system and the request an attribute specification to be read from the ID token for carrying out the transaction attributes, transaction data for specifying the transaction, an identifier (180) of the request, a URL of an ID provider computer system and a URL of the service computer system,- transmission of a web page (160) and the request via the first session of the service - Computer system to the user computer system, the website having an input field (162) for entering additional information (168) for carrying out the transaction,- display of the website by the application program and input of the additional information by the user in the input field,- structure a second session (202) between the application program (112) and the ID provider computer system via the network using the URL of the ID provider computer system, the second session being established with a secure transport layer,- forwarding of the request and the additional information from the application program to the ID provider computer system via the second session, - based on the receipt of the request, generation of a session ID for a third session (203) by the ID provider computer system and storage of the request and the additional information by the ID provider computer system, - sending a message from the ID provider computer system to the application program (112) with the session ID of the third session and a logical address via the second session, - setting up the third session between a program (113 ) of the user computer system and the ID provider computer system via the secure transport layer of the second session, wherein the program can be different from the application program (112),- transmission of at least one certificate (144) of the ID provider computer system to the program (113), the certificate containing an indication of reading rights of the ID provider computer system for reading one or more of the attributes stored in the ID token, the transmission of the certificate taking place via the third session, - checking by the program ( 113) whether the reading rights specified in the certificate are sufficient to permit read access by the ID provider computer system to the attribute(s) to be read according to the attribute specification, and only if the reading rights are sufficient:a) Establishment of a local connection ( 176) between the reader of the user computer system and the ID token,b) authentication of the user to the ID token, with a session key being agreed upon,c) establishment of a fourth session (204) between the ID token and the ID provider computer system via the local connection and the third session with end-to-end encryption using the session key,d) mutual authentication of the ID token and the ID provider computer system via the fourth session,e) reading of the attribute(s) according to the attribute specification by the ID provider computer system via the fourth session from the ID token.- Generation of a response (174) which contains the attribute(s) read and at least the identifier (180) of the request, and which is signed by the ID provider computer system, - storage of the response for retrieval using the logical address, - reading of the response from the ID provider computer system by the user computer system by retrieving the response using a read command from the logical address via the network,- forwarding of the response by the user computer system via the first session to the service computer system,- assignment of the response to the request using the identifier contained in the response by the service computer system,- implementation the transaction using the response by the ID provider computer system, the method comprising the following further steps:- displaying an optically readable pattern on a screen (188) of a terminal (186), wherein information is encoded in the optically readable pattern , which contains at least one URL of the service computer system and a payment amount,- detection of the pattern using an optical sensor (190) of the user computer system and decoding of the pattern,- calling up the URL of the service computer system that was recorded via the pattern, to set up the first session, the payment amount being transmitted with the transaction request (158) to the service computer system via the first session, the terminal being an automat, the user entering a request into the automat, whereupon the Automat displays the pattern, and wherein the service computer system signals the automat to carry out the transaction, whereupon the automat fulfills the request entered by the user.

Description

The invention relates to an electronic transaction method and a computer system.

Various transaction methods are known for electronic commerce, ie so-called e-commerce. This includes standard payment methods such as paper-based bank transfers or cash on delivery payments, as well as electronic payment methods such as credit card payments, payments via online banking, debt collection/billing systems, factory systems, electronic direct debits, prepaid methods, payment by telephone bill and Cell Phone Payment Systems. Such payment methods are also used in part for e-government applications.

In contrast, the invention is based on the object of creating an improved electronic transaction method and a corresponding computer system.

The object on which the invention is based is achieved in each case with the features of the independent patent claims. Embodiments of the invention are specified in the dependent claims.

Known from the prior art are technical guidelines for a server to simplify electronic proof of identity in web applications (BSI TR-03130, Technical Guideline eID Server, Federal Office for Information Security, Ver. 1.6, 04/20/2012), a technical guideline for an API framework for providing an interface that enables the standardized use of chip cards (Technical Guideline TR-03112-7 eCard-API-Framework - Protocols, Federal Office for Information Security, Ver. 1.1.2, 28.02 .2012) and an information-processing device with an optical data reader, server, and a method for electronic commerce ( U.S. 2003/0120555 A1 ).

The Technical Guideline TR-03110, Ver. 2.05 of the Federal Office for Information Security describes extended security mechanisms for machine-readable travel documents.

A "transaction" is defined here as a financial transaction, such as the payment of a payment amount by making a bank transfer, direct debit or credit card charge, an ordering process for ordering and delivery of a physical good or data and other logistical, commercial and/ or financial transactions understood.

A "session" is understood here as a temporary communication connection, i.e. a so-called communication session, which according to the OSI layer model can refer to the transport layer or the application layer. In particular, a session can be an http session or an https session, with the latter having the transport layer protected by symmetric encryption.

An “ID token” is understood here to mean, in particular, a portable electronic device which has at least one data memory for storing the at least one attribute and a communication interface for reading out the attribute. The ID token preferably has a secure memory area for storing the at least one attribute in order to prevent the attribute stored in the memory area from being changed in an unauthorized manner or from being read out without the authorization required for this.

In particular, the ID token can be a USB stick or a document, in particular a value or security document. According to the invention, a “document” is understood to mean paper-based and/or plastic-based documents, such as electronic identification documents, in particular passports, ID cards, visas and driver’s licenses, vehicle registration documents, vehicle registration documents, company ID cards, health cards or other ID documents, as well as chip cards, means of payment, in particular banknotes , Bank cards and credit cards, bills of lading or other proof of authorization, such as an admission ticket, in which a data memory for storing the at least one attribute is integrated.

The ID token can be a hardware token or a soft token if it is cryptographically linked to a hardware token, ie to a so-called secure element, for example.

In particular, such a soft token cryptographically bound to a secure element according to DE 10 2011 082 101 be generated.

An “ID provider computer system” is understood here to mean a computer system which is designed to read at least one attribute from a user's ID token. The ID provider computer system is preferably operated in a so-called trust center in order to create the highest possible level of security.

A "service computer system" is understood here to mean a computer system which has has a network interface for connecting to the network, so that Internet pages stored or generated by the service computer system can be accessed using an Internet browser or another application program. In particular, the service computer system can be an internet server for providing an e-commerce or e-government application, in particular an online shop or a government agency server.

A "user computer system" is understood here as a computer system to which the user has access. This can be, for example, a personal computer (PC), a tablet PC or a mobile phone, in particular a smartphone, with a standard Internet browser such as Microsoft Internet Explorer ^® , Safari ^® , Google Chrome™, Firefox ^® or another application program act to access the service computer system. The user computer system has an interface for connecting to the network, which network can be a private or public network, in particular the Internet.

According to one embodiment of the invention, the request from the service computer system is a SAML request and the response from the ID provider computer system is a SAML response (cf. Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, 25 March 2008).

According to embodiments of the invention, the request is transmitted from the service computer system to the ID provider computer system via the user computer system. The further process for generating the response, including the authentication of the user and the ID provider computer system, is triggered on the basis of the receipt of the request by the user computer system.

According to one embodiment of the invention, the ID provider computer system has a certificate in which the reading rights for carrying out the read access are specified.

A "certificate" is understood here as a digital certificate, which is also referred to as a public key certificate. A certificate is structured data used to associate a public key of an asymmetric cryptosystem with an identity, such as a person or device. For example, the certificate can conform to the X.509 standard or another standard. The certificate is preferably a Card Verifiable Certificate (CVC).

The certificate can specify for which attribute or attributes of the user, which are stored in the protected memory area of the ID token, the ID provider computer system is authorized to carry out the read access. These attributes can be personal attributes of the user, such as their name, place of residence and age. In combination, these attributes can be used as user identification in order to access the payment information of the registered user. Alternatively or additionally, a pseudonym of the user, which is stored at least temporarily by the ID token, can also be used as the user identifier.

Embodiments of the invention are particularly advantageous because a computer-implemented payment method that is universally suitable for e-commerce and e-government applications is created, which is flexible, easy to use and secure at the same time. This is made possible in particular by the fact that the payment method is based on an ID token, with the prerequisite for carrying out a payment transaction being both the authentication of the user to the ID token and the authentication of the ID provider computer system to the ID token.

According to embodiments of the invention, a first session is initially set up between the Internet browser of the user computer system and the service computer system over the Internet, it being possible for the first session to be an http session or an https session. The user can enter a transaction request into the Internet browser, for example to initiate a payment process. For example, the user has previously ordered a product via the service computer system and would like to pay for this ordered product, for which purpose the user enters the corresponding transaction request in the Internet browser, which is transmitted to the service computer system via the first session.

The service computer system then generates a request, ie a request for a request-response protocol. The request can have a predefined or standardized structure. For example, the request can be text-based, have an XML, ASN.1 or binary structure, or be in the form of a SAML request. The request, for example the SAML request, contains an attribute specification that specifies the attributes to be read out of the ID token to carry out the transaction. These can be attributes that identify the user who is assigned to the ID token and/or that specify payment information, such as account details or credit card information Information and/or attributes relating to the ID token itself, such as its validity period, date of issue and/or the issuing organization or authority.

In particular, the attribute specification can contain the user's date of birth if, for example, the user's majority is to be checked by the service computer system as a prerequisite for carrying out the transaction. The request also contains transaction data for specifying the transaction, ie for example a payment amount and account information, in particular the account details of the service computer system to which the payment is to be made. The request also includes a Uniform Resource Locator (URL) of the ID provider computer system, which is to read the attributes from the ID token, and a URL of the service computer system for specifying a recipient for the response, which is due to the request from the ID provider computer system is to generate.

The service computer system generates an identifier for the request that uniquely identifies the request, such as a globally unique identifier (GUID). The request contains this identifier.

The request is signed by the service computer system using a private key of a cryptographic key pair which is assigned to the service computer system.

Due to the transaction request, a website is transmitted from the service computer system to the user computer system via the first session and displayed by the Internet browser or the application program, in particular an app. The request is transmitted together with the website, but is not displayed.

The website has at least one input field for entering additional information that is required to carry out the transaction. This additional information can be, for example, account details or credit card information for the user and/or authentication information to authenticate the user to the service computer system. For example, the authentication information can be a one-time password (OTP). The additional information is preferably encrypted by the user computer system using the public key of the service computer system, so that only the encrypted additional information is then forwarded via a second session from the Internet browser or the application program to the ID provider computer system via the network.

The request is also forwarded via this second session. The second session is set up by calling up the URL of the ID provider computer system, which is contained in the request. The second session is set up as a protected communication connection, with an encrypted transport layer, i.e. with Transport Layer Security (TLS), which is also referred to as Secure Sockets Layer (SSL), in particular as an https session.

According to embodiments of the invention, based on the receipt of the request via the second session, the ID provider computer system generates an identifier for a third session that is still to be set up, i.e. a so-called session ID. The ID provider computer system stores the request and the additional information received together with the request about the second session with the session ID for the third session.

The ID provider computer system then sends a message via the second session, which contains a logical address of the ID provider computer system and, for example, also the session ID of the third session. The Internet browser or the application program can call up the response to the previously forwarded request from this logical address at a later point in time. The logical address can be a uniform resource locator (URL) through which the response can be retrieved.

The third session is then set up on the application layer between a program in the user computer system and the ID provider computer system, specifically via the secure transport layer of the second session. The program can be, for example, a browser plug-in of the Internet browser or an application program that is different from the Internet browser.

The ID provider computer system then transfers the information about the third session to the program that is required for reading the attribute or attributes from the ID token. This information contains at least one certificate from the ID provider computer system, which contains an indication of reading rights for the ID provider computer system to read one or more attributes.

1. a) Es wird eine lokale Verbindung zwischen dem Lesegerät des Nutzer-Computersystems und dem ID-Token aufgebaut. Bei einem ID-Token mit einer kontaktbehafteten Schnittstelle, beispielsweise einer Chipkarten-Schnittstelle, kann dies durch Einführen des ID-Tokens in das Lesegerät erfolgen. Bei einem ID-Token mit einer kontaktlosen Schnittstelle, wie zum Beispiel einer RFID oder einen NFC-Schnittstelle, kann dies dadurch erfolgen, dass der ID-Token auf das Lesegerät gelegt wird. Hier sind auch Token mit USB, BlueTooth oder microSD-Karten möglich sowie auch virtuelle SmartCards.
2. b) Der Nutzer authentifiziert sich gegenüber dem ID-Token, beispielsweise durch Eingabe seiner Personal Identification Number (PIN) oder durch Eingabe einer anderen Information, wie zum Beispiel der Erfassung eines biometrischen Merkmals des Nutzers. Bei der Authentifizierung des Nutzers gegenüber dem ID-Token wird ein Session Key vereinbart. Insbesondere kann die Vereinbarung eines Session Keys mithilfe eines Diffie-Hellman-Protokolls erfolgen.
3. c) Anschließend wird eine vierte Session auf dem Application Layer aufgebaut, und zwar zwischen einem Programm des ID-Tokens und dem ID-Provider-Computersystem, wobei diese vierte Session über die lokale Verbindung und die dritte Session verläuft und auf dem Application Layer eine zusätzliche Ende-zu-Ende Verschlüsselung mithilfe des in Schritt b vereinbarten Session Keys erfolgt.
4. d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems, beispielsweise mithilfe eines Challenge-Response-Protokolls.
5. e) Das oder die Attribute gemäß der Attributspezifikation, welche das ID-Provider-Computersystem mit dem Request empfangen hat, werden nun über die vierte Session von dem ID-Provider-Computersystem aus dem ID-Token ausgelesen. Dies setzt die erfolgreiche Authentifizierung des Nutzers in Schritt b sowie die erfolgreiche gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems in Schritt d) voraus und erfolgt verschlüsselt über die vierte Session, sodass ein Maximum an Sicherheit und Vertrauenswürdigkeit hinsichtlich des oder der ausgelesenen Attribute gegeben ist.

The program of the user computer system then checks whether the reading rights specified in the certificate are sufficient to allow read access by the ID provider computer system to the or Allow the attributes to be read according to the request's attribute specification. If the reading rights of the ID provider computer system are sufficient, the following further steps are carried out:

1. a) A local connection is established between the reader of the user computer system and the ID token. In the case of an ID token with a contact-based interface, for example a chip card interface, this can be done by inserting the ID token into the reading device. In the case of an ID token with a contactless interface, such as an RFID or an NFC interface, this can be done by placing the ID token on the reading device. Tokens with USB, BlueTooth or microSD cards are also possible here, as well as virtual SmartCards.
2. b) The user authenticates himself to the ID token, for example by entering his personal identification number (PIN) or by entering other information, such as the capture of a biometric feature of the user. A session key is agreed upon when the user is authenticated against the ID token. In particular, a session key can be agreed using a Diffie-Hellman protocol.
3. c) A fourth session is then set up on the application layer, between a program of the ID token and the ID provider computer system, with this fourth session running over the local connection and the third session and an additional one on the application layer End-to-end encryption takes place using the session key agreed in step b.
4. d) A mutual authentication of the ID token and the ID provider computer system then takes place via the fourth session, for example using a challenge-response protocol.
5. e) The attribute or attributes according to the attribute specification, which the ID provider computer system has received with the request, are now read out of the ID token by the ID provider computer system via the fourth session. This requires the successful authentication of the user in step b and the successful mutual authentication of the ID token and the ID provider computer system in step d) and is encrypted over the fourth session, so that maximum security and trustworthiness with regard to the read attributes is given.

The ID provider computer system then generates a response that contains the attribute or attributes read out and the identifier of the request and/or the additional information, specifically in accordance with the request-response protocol to which the request is subject. In the case of a SAML request, a SAML response is generated accordingly. The logical assignment of request and response, i.e. the so-called binding, is established via the identifier of the request, which is also contained in the response.

The response is signed by the ID provider computer system and stored for retrieval from the logical address previously communicated to the user computer system via the message.

The user computer system then reads this response from the ID provider computer system using the logical address, for example the URL, and forwards the response to the service computer system via the first session. Using the identifier of the response, this is assigned to the request and thus to the requested transaction, and then the transaction is executed by the service computer system, ie a payment process is triggered and/or an ordered product is delivered if the content of the response allows this.

According to one embodiment of the invention, the program of the user's computer system is a browser plug-in of the Internet browser, the Internet browser being a standard browser program such as Microsoft Internet ^Explorer® , ^Safari® , Google Chrome™ or Firefox ^® can act. Alternatively, the program on the user's computer system can be an application program that is separate from the Internet browser.

According to one embodiment of the invention, the additional information entered by the user is payment information, such as the user's account details, from which the payment amount specified in the request is to be debited or collected.

The so-called clearing, ie checking the customer's creditworthiness and initiating the payment process, can then be initiated by the ID provider computer system, which confirms the execution of the payment with the response to the service computer system. This has the advantage that the service computer system does not need to know anything about the user's payment information, ie in particular his account details.

Alternatively, the user can encrypt his payment information with the public key of the service computer system, so that only the user's encrypted payment information is transmitted to the ID provider computer system. The ID provider computer system then forwards the encrypted payment information with the response to the service computer system, which decrypts the payment information and then carries out the clearing and collects the payment amount from the user's account according to the payment information. This has the advantage that the ID provider computer system has no knowledge of the user's payment information.

According to the invention, the computer system includes a terminal, such as an ATM or vending machine. The user can enter a request into the machine, such as withdrawing cash or purchasing a specific product, such as a drink. In response to this user request, the machine displays an optically detectable pattern, such as a QR code, on its screen, which contains information to initiate the transaction.

In the following, embodiments of the invention are explained in more detail with reference to the drawings.

• 1 ein Blockdiagramm eines ID-Tokens,
• 2 eine Anordnung eines Computersystems zur Durchführung eines erfindungsgemäßen Verfahrens.

Show it:

• 1 a block diagram of an ID token,
• 2 an arrangement of a computer system for carrying out a method according to the invention.

Elements of the following figures which are identical or correspond to one another are each marked with the same reference numbers.

The 1 shows an ID token 106, which can be, for example, an electronic identity card.

The protected memory area 120 of the ID token 106 is used to store a reference value that is required to authenticate a user 102 to the ID token 106 . This reference value is, for example, an identifier, in particular a so-called personal identification number (PIN), or reference data for a biometric feature of the user 102, which can be used to authenticate the user to the ID token 106.

The protected area 122 is used to store a private key and the protected memory area 124 is used to store attributes, for example of the user 102, such as his name, place of residence, date of birth, gender, and / or attributes that the ID token themselves, such as the institution that created or issued the ID token, the period of validity of the ID token, an identifier of the ID token, such as a passport number or a credit card number.

The electronic memory 118 can also have a memory area 126 for storing a certificate. The certificate contains a public key which is associated with the private key stored in the protected memory area 122 . The certificate can have been created according to a Public Key Infrastructure (PKI) standard, for example according to the X.509 standard.

The certificate does not necessarily have to be stored in the electronic memory 118 of the ID token 106. Alternatively or additionally, the certificate can also be stored in a public directory server.

The ID token 106 has a processor 128. The processor 128 is used to execute program instructions 130, 132 and 134. The program instructions 130 are used for user authentication, i.e. to authenticate the user 102 to the ID token.

When using a PIN, the user enters 102 his PIN for his authentication in the ID token 106, for example via the user computer system 100. By executing the program instructions 130, the protected memory area 120 is then accessed to the entered PIN with the there to compare the stored reference value of the PIN. In the event that the entered PIN matches the reference value of the PIN, the user 102 is considered authenticated.

Alternatively, a biometric feature of the user 102 is recorded. For example, the ID token 106 has a fingerprint sensor for this purpose or a fingerprint sensor is connected to the user computer system 100 . The biometric data recorded by the user 102 is compared with the biometric reference data stored in the protected memory area 120 by executing the program instructions 130 . If the biometric data recorded by the user 102 matches the biometric reference data sufficiently, the user 102 is deemed to have been authenticated.

The program instructions 134 are used to execute the ID token 106 relevant steps of a cryptographic protocol for authentication of an ID provider computer system 136 against the ID token 106. The cryptographic protocol can be a challenge-response protocol based on a symmetric key or an asymmetric key pair.

For example, an extended access control method is implemented by the cryptographic protocol, as specified by the international aviation authority (ICAO) for machine-readable travel documents (MRTD). By successfully executing the cryptographic protocol, the ID provider computer system 136 authenticates itself to the ID token and thereby proves its authorization to read the attributes stored in the protected memory area 124 . The authentication can also be mutual, i.e. the ID token 106 must then also authenticate itself to the ID provider computer system 136 using the same or a different cryptographic protocol.

The program instructions 132 are used for end-to-end encryption between the ID token 106 and an ID provider computer system 136 (cf. 2 ) transmitted data, but at least the attributes read by the ID provider computer system 136 from the protected memory area 124. A symmetric key can be used for the end-to-end encryption, which is agreed between the ID token 106 and the ID provider computer system 136 when the cryptographic protocol is executed, for example.

The ID token 106 has an interface 108 for communication with a corresponding interface 104 of a user computer system 100 (cf 2 ). The interface can be contactless or contact-based. In particular, it can be an RFID or an NFC communication interface.

Access to the protected memory area 124 to read one or more of the attributes can only take place via the processor 128 of the ID token 106, since the protected memory area 124 and the other protected memory areas 120, 122 are not directly connected, for example via a bus system with the Interface 108 are connected, but only to the processor 128, that is, access via the interface 108 directly to the protected memory area 124 is already circuitry excluded. Only the processor 128 can therefore have read access to the protected memory area 124 in order to then optionally output the attributes read out via the interface 108 .

The 2 shows a user computer system 100 of the user 102. The user computer system 100 can be a personal computer (PC), a portable computer such as a laptop, notebook or tablet computer, a mobile telecommunications device, in particular a Trade smartphone.

The user computer system has at least one processor 110 for executing an application program 112. The application program 112 is designed to communicate via a network interface 114 of the user computer system 100 via a network 116. For example, the application program is an Internet browser or another specialized application program that can communicate via the network 116, in particular an HTML-enabled application program.

The processor 110 is used to run another program 113, which can be, for example, a plug-in for the application program 112, for example a browser plug-in if the application program 112 is designed as an Internet browser, or a program separate from the application program.

The network can be a computer network such as the Internet. In particular, the network 116 can also include a cellular network.

The ID provider computer system 136 has a network interface 138 for communication over the network 116. The ID provider computer system 136 also has a memory 140 with a protected memory area 141 in which a private key 142 of the ID provider computer system 136 is stored, as well as the corresponding certificate 144. This certificate can also be a certificate based on a PKI standard, such as X.509, for example.

The ID provider computer system 136 also has at least one processor 145 for executing program instructions 146 and 148. By executing the program instructions 146, the steps of the cryptographic protocol relating to the ID provider computer system 136 are executed. Overall, therefore, the cryptographic protocol by executing the program instructions 134 by the processor 128 of the ID token 106 and by executing the program instructions 146 implemented by the processor 145 of the ID provider computer system 136 .

The program instructions 148 are used to implement the end-to-end encryption on the part of the ID provider computer system 136, for example based on the symmetric key that is used when executing the cryptographic protocol between the ID token 106 and the ID provider Computer system 136 has been agreed. In principle, any previously known method for agreeing the symmetric key for the end-to-end encryption can be used, such as a Diffie-Hellman key exchange.

The ID provider computer system 136 is preferably located in a particularly protected environment, in particular in a so-called trust center, so that the ID provider computer system 136 in combination with the need to authenticate the user 102 to the ID token 106 the An anchor of trust for the authenticity of the attributes read from the ID token 106 forms.

A service computer system 150 can be designed to receive an order or an order for a service or a product, in particular an online service. For example, user 102 may open an account with a bank online via network 116 or use some other financial or banking service. The service computer system 150 can also be embodied as an online store, so that the user 102 can, for example, purchase a cell phone or the like online. Furthermore, the service computer system 150 can also be designed to deliver digital content, for example for downloading music and/or video data.

For this purpose, the service computer system 150 has a network interface 152 for connecting to the network 116. The service computer system 150 also has at least one processor 154 for executing program instructions 156. By executing the program instructions 156, dynamic HTML pages are generated, for example, via which the user 102 can enter his order or his order, as well as transactions carried out.

• - Der Nutzer 102 startet das Anwendungsprogramm 112 des Nutzer-Computersystems, wobei im Weiteren ohne Beschränkung der Allgemeinheit davon ausgegangen wird, dass es sich hierbei um einen Internet-Browser handelt. Der Nutzer 102 gibt eine URL des Dienst-Computersystems 150 in den Internet-Browser ein, so dass daraufhin eine erste Session 201 zwischen dem Internet-Browser 112 und dem Dienst-Computersystem 150 über das Netzwerk 116 aufgebaut wird. Der Nutzer kann dann über die erste Session 201 einen von dem Dienst-Computersystem 150 angebotenen Dienst anfordern, wie zum Beispiel ein Produkt bestellen, Daten zum Download anfordern oder die Durchführung einer finanziellen Transaktion anfordern. Hierzu wird von dem Internet-Browser 112 eine entsprechende Transaktionsanforderung 158 an das Dienst-Computersystem 150 gesendet, die diese Anforderung signalisiert.
• - Das Dienst-Computersystem empfängt also von dem Internet-Browser über die erste Session eine Transaktionsanforderung 158 des Nutzers 102.
• - Aufgrund des Empfangs der Transaktionsforderung 158 über die erste Session 201 erzeugt das Dienst-Computersystem 150 einen Request 166. Der Request 166 beinhaltet (i) eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute. Bei diesen Attributen kann es sich um persönliche Angaben zu dem Nutzer 102 und/oder Daten betreffend den ID-Token 106 selbst oder ein Pseudonym des Nutzers 102, welches von dem ID-Token 106 verfügbar ist, handeln. Der Request beinhaltet ferner (ii) die Transaktionsdaten zur Spezifizierung der Transaktion, wie zum Beispiel einen Bezahlbetrag, der für den Kauf des bestellten Produkts oder die Durchführung des bestellten Dienstes an das Dienst-Computersystem 150 oder einen Dritten zu entrichten ist, und/oder andere Transaktionsdaten, die die durchzuführende Transaktion spezifizieren. Der Request beinhaltet ferner (iii) eine Kennung 180 des Requests, beispielsweise eine GUID, die für das sogenannte Binding des Requests und einer daraufhin empfangenen Response 174 erforderlich ist. Für die Erzeugung der Kennung kann das Dienst-Computersystem 150 einen GUID-Generator aufweisen. Die Request beinhaltet ferner (iv) eine URL des ID-Provider-Computersystems 136 und (v) eine URL des Dienst-Computersystems 150 selbst. Der Request wird von dem Dienst-Computersystem 150 signiert, nämlich mit Hilfe eines privaten Schlüssels des Dienst-Computersystems 150. Bei dem Request 166 kann es sich um einen SAML-Request oder einen anderen Request eines Request-Response-Protokolls handeln.
• - Als Antwort auf die Transaktionsanforderung 158 sendet dann das Dienst-Computersystem 150 eine Webseite 160 über die erste Session 201 an das Nutzer-Computersystem 100, wobei die Webseite 160 ein Eingabefeld 162 zur Eingabe einer Zusatzinformation durch den Nutzer 102 für die Transaktion aufweist und ferner ein Eingabeelement 164, das der Nutzer 102 zum Beispiel durch Anklicken selektieren kann, wenn die Webseite 160 durch den Internet-Browser 112 wiedergegeben wird, um die Weiterleitung des Request 166 zu erlauben. Zusammen mit der Webseite 160 wird auch der Request 166 über die erste Session 201 zu dem Internet-Browser 112 übertragen.
• - Aufgrund des Empfangs der Webseite 160 und des Requests 166 wird die Webseite 160 durch den Internet-Browser 112 wiedergegeben, so dass der Nutzer 102 die Zusatzinformation in das Eingabefeld 162 eingeben kann. Beispielsweise handelt es sich bei der Zusatzinformation um eine Kontoverbindung des Nutzers 102, eine Kreditkartennummer des Nutzers 102 oder andere ergänzende Transaktionsdaten und/oder um eine Authentifizierungsinformation zum Nachweis der Berechtigung des Nutzers 102 für die Durchführung der Transaktion, wozu der Nutzer 102 beispielsweise ein One-Time-Passwort (OTP) in das Eingabefeld 162 eingibt. Vorzugsweise wird die von dem Nutzer 102 eingegebene Zusatzinformation 168 mit dem öffentlichen Schlüssel des Dienst-Computersystems 150 durch das Nutzer-Computersystem 100 verschlüsselt, um ein entsprechendes Chiffrat zu erhalten.
• - Anschließend wird eine zweite Session 202 zwischen dem Internet-Browser 112 und dem ID-Provider-Computersystem 136 über das Netzwerk 116 aufgebaut, und zwar mit Hilfe der URL des ID-Provider-Computersystems 136, die das Nutzer-Computersystem 100 mit dem Request 166 empfangen hat. Die zweite Session 202 wird mit einem gesicherten Transportlayer aufgebaut, beispielsweise als https-Session.
• - Über die zweite Session 202 werden der Request 166 und die Zusatzinformation 168 oder nur das mit Hilfe des öffentlichen Schlüssels des Dienst-Computersystems 150 gewonnene Chiffrat der Zusatzinformation 168 von dem Nutzer-Computersystem 100 an das ID-Provider-Computersystem 136 weitergeleitet.
• - Aufgrund des Empfangs des Requests 166 durch das ID-Provider-Computersystem 136 erzeugt dieses durch Ausführen seiner Programminstruktionen 170 eine Session-ID für eine noch aufzubauende dritte Session 203. Der Request 166 und die Zusatzinformation 168 werden in dem Speicher 140 des ID-Provider-Computersystems 136 gespeichert.
• - Das ID-Provider-Computersystem 136 generiert dann eine Nachricht 172, die die Session-ID für den Aufbau der dritten Session 203 und eine logische Adresse beinhaltet. Mit Hilfe der logischen Adresse kann die von dem ID-Provider-Computersystem 136 aufgrund des Request 166 zu erzeugende Response 174 abgerufen werden. Insbesondere kann die logische Adresse als eine URL ausgebildet sein. Die Nachricht 172 wird über die zweite Session 202 von dem ID-Provider-Computersystem 136 an den Internet-Browser 112 gesendet.
• - Aufgrund des Empfangs der Nachricht 172 wird die dritte Session 203 zwischen dem Programm 113 des Nutzer-Computersystems 100 und dem ID-Provider-Computersystem 136 über den gesicherten Transportlayer der zweiten Session 202 aufgebaut. Beispielsweise handelt es sich bei dem Programm 113 um ein Browser-Plug-in des Internet-Browsers 112. Alternativ kann es sich bei dem Programm 113 auch um ein weiteres Anwendungsprogramm handeln. Es ist dabei auch möglich, die Funktionalitäten des Internet-Browsers 112 und die des Programms 113 in einem Programm zu implementieren.
• - Über die dritte Session 203 wird dann zumindest das Zertifikat 144 an das Programm 113 übertragen.
• - Durch das Programm 113 wird dann geprüft, ob die in dem Zertifikat 144 angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-Computersystems 136 auf das oder die gemäß der Attributspezifikation, die in dem Request 166 beinhaltet ist, zu lesenden Attribute zuzulassen. Nur dann, wenn diese Leserechte ausreichend sind, werden die folgenden Schritte durchgeführt:
  1. a) Es wird eine lokale Verbindung 176 zwischen den Schnittstellen 104 und 108 aufgebaut. Beispielsweise erscheint auf dem Bildschirm des Nutzer-Computersystems 100 eine Aufforderung für den Nutzer 102 zum Einführen des ID-Tokens 106 in ein Lesegerät des Nutzer-Computersystems 100, welches die Schnittstelle 104 aufweist oder zum Auflegen des ID-Tokens 106 auf eine kontaktlos ausgebildete Schnittstelle 104.
  2. b) Der Nutzer 102 authentifiziert sich dann gegenüber dem ID-Token beispielsweise durch Eingabe seiner PIN in das Nutzer-Computersystem 100 bzw. dessen Lesegerät. Die Authentifizierung des Nutzers kann mit Hilfe eines kryptographischen Protokolls erfolgen, beispielsweise mittels eines Challenge-Response-Protokolls oder basierend auf einem Diffie-Helman-Schlüsselaustausch, wobei im Rahmen der Authentifizierung des Nutzers ein Session-Key vereinbart wird.
  3. c) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers wird eine vierte Session 204 zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 aufgebaut, und zwar über die lokale Verbindung 176 und die dritte Session 203. Die vierte Session 204 wird mit einer Ende-zu-Ende-Verschlüsselung mit Hilfe des Session-Keys, der bei der Authentifizierung des Nutzers in dem Schritt b) vereinbart worden ist, geschützt.
  4. d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens 106 und des ID-Provider-Computersystems 136 mit Hilfe der jeweiligen privaten Schlüssel, das heißt den in dem geschützten Speicherbereich 122 gespeicherten privaten Schlüssels des ID-Tokens 106 und dem privaten Schlüssels 142 des ID-Provider-Computersystems 136. Für diese gegenseitige Authentifizierung können die Zertifikate des ID-Tokens 106 aus dem Speicherbereich 126 (vergleiche 1) sowie das Zertifikat 144 des ID-Provider-Computersystems 136 über die vierte Session ausgetauscht werden.
  5. e) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers gegenüber dem ID-Token und der erfolgreichen gegenseitigen Authentifizierung des ID-Tokens 106 und des ID-Provider-Computersystems 136 liest dann das ID-Provider-Computersystem 136 das oder die Attribute gemäß der Attributspezifikation aus dem ID-Token 106 aus, wobei die Attribute durch die Ende-zu-Ende-Verschlüsselung bei der Übertragung von dem ID-Token 106 zu dem ID-Provider-Computersystem 136 geschützt werden. Hierzu sendet das ID-Provider-Computersystem über die vierte Session 204 ein Lesekommando über die vierte Session an den ID-Token 106. Das Lesekommando 182 beinhaltet die Attributspezifikation, das heißt die Auswahl derjenigen Attribute, die aus dem geschützten Speicherbereich 124 des ID-Tokens 106 ausgelesen werden sollen. Durch Ausführung der Programminstruktionen 178 wird dann von dem ID-Provider-Computersystem 136 die Response 174, beispielsweise ein SAML-Response, auf dem Request 166 erzeugt. Die Response 178 beinhaltet die zuvor über die vierte Session 240 aus dem ID-Token 106 ausgelesenen Attribute, die Zusatzinformation 168 oder - alternativ - nicht die Zusatzinformation 168, sondern nur das Chiffrat der Zusatzinformation 168, sowie die Kennung 180, die das Dienst-Computersystem 150 initial für den Request 166 vergeben hat. Die Response 174 wird von dem ID-Provider-Computersystem 136 mit Hilfe des privaten Schlüssels 142 signiert und dann in dem Speicher 140 gespeichert, so dass die Request 166 von der logischen Adresse abrufbar ist.
• - Das Nutzer-Computersystem 100, wie zum Beispiel dessen Internet-Browser 112, liest dann mit Hilfe der logischen Adresse die Response 174 beispielsweise über die zweite Session 202 aus dem Speicher 140.
• - Die Response 174 wird dann von dem Nutzer-Computersystem 100, beispielsweise von dem Internet-Browser 112, über die erste Session 201 an das Dienst-Computersystem 150 weitergeleitet. Hierbei kann vorgesehen sein, dass der Nutzer 102 von dem Internet-Browser 112 zur Eingabe einer Bestätigung aufgefordert wird, bevor die Response 174 an das Dienst-Computersystem weitergeleitet wird. Dabei kann ferner vorgesehen sein, dass von dem Internet-Browser der Inhalt der Response 174 ganz oder teilweise angezeigt wird, insbesondere die aus dem ID-Token ausgelesenen Attribute und/oder die Zusatzinformation 168, damit sich der Nutzer 102 von der Richtigkeit dieser Daten überzeugen kann, bevor sie an das Dienst-Computersystem 150 zur Durchführung der Transaktion weitergeleitet werden.

• - Das Dienst-Computersystem 150 ordnet die empfangene Response 174 dem Request 166 anhand der übereinstimmenden Kennungen 180 des Requests 166 und der Response 174 zu.
• - Das Dienst-Computersystem 150 prüft dann die Signatur der Response 166 und liest das oder die erforderlichen Attribute aus der Response 174 aus. Anhand der Attribute wird dann geprüft, ob die angeforderte Transaktion durchgeführt werden kann, indem das oder die Attribute mit einem oder mehreren vorgegebenen Kriterien verglichen wird. Bei diesen Kriterien kann es sich zum Beispiel um das Alter oder die Kreditwürdigkeit des Nutzers 102 handeln. Bei dem Attribut kann es sich auch um ein Pseudonym des Nutzers 102 handeln, mit Hilfe dessen das Dienst-Computersystem 150 dann ein in einer Datenbank des Dienst-Computersystems 150 gespeichertes Attribut des Nutzers 102, wie zum Beispiel eine Lieferadresse ausliest. Das Prüfkriterium ist hierbei, ob ein Nutzer mit dem in der Response 174 beinhalteten Pseudonym seitens des Dienst-Computersystems 150 registriert ist.
• - Ergibt die Prüfung des Dienst-Computersystems 150, dass die Transaktion durchführbar ist, so wird die Transaktion anhand der Transaktionsdaten und der Zusatzinformation 168 durchgeführt.

Depending on the type of product or service commissioned or ordered, the service computer system 150 must check one or more attributes of the user 102 and/or their ID token 106 using one or more predetermined criteria. Only if this check is passed is the order or assignment from the user 102 accepted and/or executed. To carry out an electronic transaction, you can proceed as follows:

• - The user 102 starts the application program 112 of the user computer system, it being assumed below, without restricting the generality, that this is an Internet browser. The user 102 enters a URL of the service computer system 150 into the Internet browser, so that a first session 201 is then set up between the Internet browser 112 and the service computer system 150 via the network 116 . The user can then use the first session 201 to request a service offered by the service computer system 150, such as ordering a product, requesting data to be downloaded or requesting a financial transaction to be carried out. For this purpose, the Internet browser 112 sends a corresponding transaction request 158 to the service computer system 150, which signals this request.
• - The service computer system thus receives a transaction request 158 from the user 102 from the Internet browser via the first session.
• - Due to the receipt of the transaction request 158 via the first session 201, the service computer system 150 generates a request 166. The request 166 contains (i) an attribute specification of the attributes to be read from the ID token for carrying out the transaction. These attributes can be personal information about the user 102 and/or data relating to the ID token 106 itself or a pseudonym of the user 102, which is available from the ID token 106. The request also includes (ii) the transaction data specifying the transaction, such as a payment amount to be paid to the service computer system 150 or a third party to purchase the ordered product or perform the ordered service, and/or others Transaction data specifying the transaction to be performed. The request also includes (iii) an identifier 180 of the request, for example a GUID, which is required for the so-called binding of the request and a response 174 that is subsequently received. The service computer system 150 can have a GUID generator for generating the identifier. The request also contains (iv) a URL of the ID provider computer system 136 and (v) a URL of the service computer system 150 itself. The request is signed by the service computer system 150, namely using a private key of the service Computer system 150. The request 166 can be a SAML request or another request of a request-response protocol.
• - In response to the transaction request 158, the service computer system 150 then sends a website 160 via the first session 201 to the user computer system 100, the website 160 having an input field 162 for the user 102 to enter additional information for the transaction and also an input element 164 that the user 102 may select, for example by clicking on, when the web page 160 is rendered by the internet browser 112 to allow the request 166 to be forwarded. The request 166 is also transmitted to the Internet browser 112 via the first session 201 together with the website 160 .
• - Due to the receipt of the website 160 and the request 166, the website 160 is reproduced by the Internet browser 112, so that the user 102 can enter the additional information in the input field 162. For example, the additional information is a bank account of the user 102, a credit card number of the user 102 or other supplementary transaction data and/or authentication information to prove the authorization of the user 102 to carry out the transaction, for which the user 102, for example, Enter the time password (OTP) in the input field 162. The additional information 168 entered by the user 102 is preferably encrypted by the user computer system 100 using the public key of the service computer system 150 in order to obtain a corresponding ciphertext.
• - A second session 202 is then set up between the Internet browser 112 and the ID provider computer system 136 via the network 116, using the URL of the ID provider computer system 136, which the user computer system 100 with the request 166 received. The second session 202 is set up with a secure transport layer, for example as an https session.
• - Via the second session 202, the request 166 and the additional information 168 or only the ciphertext of the additional information 168 obtained using the public key of the service computer system 150 are forwarded from the user computer system 100 to the ID provider computer system 136.
• - Due to the receipt of the request 166 by the ID provider computer system 136, this generates a session ID for a third session 203 still to be established by executing its program instructions 170. The request 166 and the additional information 168 are stored in the memory 140 of the ID provider -Computer system 136 saved.
• - The ID provider computer system 136 then generates a message 172 which contains the session ID for setting up the third session 203 and a logical address. The response 174 to be generated by the ID provider computer system 136 on the basis of the request 166 can be retrieved with the aid of the logical address. In particular, the logical address can be in the form of a URL. The message 172 is sent from the ID provider computer system 136 to the Internet browser 112 via the second session 202 .
• - Due to the receipt of the message 172, the third session 203 is set up between the program 113 of the user computer system 100 and the ID provider computer system 136 via the secure transport layer of the second session 202. For example, program 113 is a browser plug-in for Internet browser 112. Alternatively, program 113 can also be another application program. It is also possible to implement the functionalities of the Internet browser 112 and those of the program 113 in one program.
• At least the certificate 144 is then transmitted to the program 113 via the third session 203 .
• - The program 113 then checks whether the reading rights specified in the certificate 144 are sufficient to allow read access by the ID provider computer system 136 to the attribute(s) to be read according to the attribute specification contained in the request 166 . The following steps are only carried out if these reading rights are sufficient:
  1. a) A local connection 176 between the interfaces 104 and 108 is established. For example, a prompt appears on the screen of user computer system 100 for user 102 to insert ID token 106 into a reader of user computer system 100, which has interface 104, or to place ID token 106 on a contactless interface 104
  2. b) The user 102 then authenticates himself to the ID token, for example by entering his PIN in the user computer system tem 100 or its reader. The user can be authenticated using a cryptographic protocol, for example using a challenge-response protocol or based on a Diffie-Helman key exchange, with a session key being agreed upon as part of the user authentication.
  3. c) Provided that the user has been successfully authenticated, a fourth session 204 is established between the ID token 106 and the ID provider computer system 136, via the local connection 176 and the third session 203. The fourth session 204 is an end-to-end encryption with the help of the session key, which has been agreed in the authentication of the user in step b), protected.
  4. d) During the fourth session, the ID token 106 and the ID provider computer system 136 are then mutually authenticated using the respective private key, i.e. the private key of the ID token 106 stored in the protected memory area 122 and the private Key 142 of the ID provider computer system 136. For this mutual authentication, the certificates of the ID token 106 from the memory area 126 (cf 1 ) and the certificate 144 of the ID provider computer system 136 can be exchanged over the fourth session.
  5. e) Subject to the successful authentication of the user against the ID token and the successful mutual authentication of the ID token 106 and the ID provider computer system 136, the ID provider computer system 136 then reads the attribute or attributes according to the attribute specification the ID token 106, the attributes being protected by end-to-end encryption during transmission from the ID token 106 to the ID provider computer system 136. To do this, the ID provider computer system sends a read command via the fourth session 204 to the ID token 106. The read command 182 contains the attribute specification, i.e. the selection of those attributes from the protected memory area 124 of the ID token 106 are to be read out. The response 174 , for example a SAML response, to the request 166 is then generated by the ID provider computer system 136 by executing the program instructions 178 . The response 178 contains the attributes previously read from the ID token 106 via the fourth session 240, the additional information 168 or - alternatively - not the additional information 168, but only the ciphertext of the additional information 168, as well as the identifier 180, which the service computer system 150 initially assigned for the request 166. The response 174 is signed by the ID provider computer system 136 using the private key 142 and then stored in the memory 140 so that the request 166 can be retrieved from the logical address.
• - The user computer system 100, such as its Internet browser 112, then uses the logical address to read the response 174, for example via the second session 202, from the memory 140.
• The response 174 is then forwarded to the service computer system 150 by the user computer system 100, for example by the Internet browser 112, via the first session 201. Provision can be made here for the user 102 to be prompted by the Internet browser 112 to enter a confirmation before the response 174 is forwarded to the service computer system. Provision can also be made for the Internet browser to display the content of the response 174 in whole or in part, in particular the attributes read from the ID token and/or the additional information 168, so that the user 102 is convinced of the correctness of this data before being forwarded to the service computer system 150 for the execution of the transaction.

• - The service computer system 150 assigns the received response 174 to the request 166 using the matching identifiers 180 of the request 166 and the response 174.
• - The service computer system 150 then checks the signature of the response 166 and reads the required attribute or attributes from the response 174. The attributes are then used to check whether the requested transaction can be carried out by comparing the attribute or attributes with one or more specified criteria. These criteria can be the age or the creditworthiness of the user 102, for example. The attribute can also be a pseudonym of the user 102, with the help of which the service computer system 150 then reads out an attribute of the user 102 stored in a database of the service computer system 150, such as a delivery address. The test criterion here is whether a user with the pseudonym contained in the response 174 is registered by the service computer system 150 .
• - If the examination of the service computer system 150 shows that the transaction can be carried out, then the transaction is carried out using the transaction data and the additional information 168 .

For example, the program 113 is a browser plug-in that is registered in a registry of an operating system of the user computer system with a plug-in identifier, the operating system being a ^Windows® operating system, for example , Android™ or iOS ^® . In this case, the message 172 from the ID provider computer system to the Internet browser 112 contains this plug-in identifier 184, so that the plug-in 113 is started as a result of receiving the message.

In another example, the program 113 is an application program that is separate from the Internet browser 112, such as a so-called citizen app or ID app. This application program 113 is started by the Internet browser 112 by calling up a local URL, the local URL containing a permanently specified port number in accordance with the TCP protocol. This local URL is transmitted together with the website 160 from the service computer system 150 to the user computer system 100 via the first session 201 in order to cause the application program 113 to be started by the Internet browser 112 using the local URL.

In the event that only the ciphertext of the additional information 168, but not the additional information 168 itself, is transmitted via the second session 202 from the user computer system 100 to the ID provider computer system 136, the response 174 only contains this ciphertext, not but the additional information 168 itself. In this case, the service computer system 150 decrypts the ciphertext using the private key of the service computer system 150 in order to then use the additional information 168 to carry out the requested transaction. This can be, for example, the execution of a financial transaction, such as the execution of a transfer in the amount of the payment that is specified in the additional information 168 .

Alternatively, however, it is also possible for the ID provider computer system 136 to initiate the payment. This can be done in such a way that the ID provider computer system 136 receives the transaction data required for this via the request 166 and the additional information 168 and then carries out or initiates the payment. The response 174 then includes a confirmation from the ID provider computer system 136 that the payment has been made.

A transmission of the additional information 168 to the service computer system 150 can then be omitted, which is advantageous for protecting the confidentiality of this additional information 168 because this additional information 168 then only has to be disclosed to the trustworthy ID provider computer system 136 . The actual transaction, e.g. the delivery of the ordered product, is then initiated by the service computer system 150 after receipt of the payment confirmation, which is contained in the response 174.

For example, the additional information 168 contains an OTP. As an additional prerequisite for carrying out the transaction, the service computer system 150 then checks whether the OTP is valid. The OTP is preferably encrypted by the user computer system 100 with the public key of the service computer system 150 and then decrypted by the service computer system 150 after receiving the additional information with the encrypted OTP in order to then check its validity.

The computer system includes a terminal 186, which can be, for example, an automat, in particular an ATM or vending machine. For example, user 102 may enter an amount of money into terminal 186 to withdraw cash from their account. An optically detectable pattern, such as a QR code, which contains a URL of the service computer system 150 and the amount of money desired by the user 102, is then shown on a display 188 of the machine.

This optical pattern is captured by the display 188 using a camera 190 of the user computer system 100 . User computer system 100 then generates transaction request 158 specifying this amount of money. The first session 201 is set up here using the URL of the service computer system 150 detected from the optical pattern and the transaction request 158 with the desired amount of money is transmitted to the service computer system 150 via this first session 201 . The service computer system 150 then generates a corresponding request 166 in order to query the attributes and additional information 168 required for the payment of the desired amount of money.

Then either by the ID provider computer system 136 or by the service computer system 150 debiting an account of the user 102, which this example in the addition information 168 provided. Due to the receipt of the response 174 and the initiation of the payment, the terminal 186 then receives a signal to issue the desired amount of money, for example in the form of cash or to load a cash card of the user 102. This can be done in such a way that the terminal 186 immediately is connected to the service computer system 150 or via the network 116.

Alternatively, the terminal 186 can also be a vending machine, in which case a desired product, such as a beverage can or a packet of cigarettes, is dispensed from the vending machine instead of cash, after the service computer system 150 signals that the payment has been made has been.

Reference List

100

user computer system

102

user

104

interface

106

ID token

108

interface

110

processor

112

Application program/Internet browser

113

program/application program

114

network interface

116

network

118

electronic storage

120

protected storage area

122

protected storage area

124

protected storage area

126

storage area

128

processor

130

program instructions

132

program instructions

134

program instructions

136

ID provider computer system

138

network interface

140

Storage

141

protected storage area

142

private key

144

certificate

145

processor

146

program instructions

148

program instructions

150

service computer system

152

network interface

154

processor

156

program instructions

158

transaction request

160

website

162

input box

164

input element

166

request

168

extra information

170

program instructions

172

News

174

response

176

local connection

178

program instructions

180

identifier

182

read command

184

identifier

186

terminal

188

screen

190

camera

Claims (12)

Electronic transaction method using an ID token (106) that is assigned to a user (102), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, wherein access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reading device of a user computer system (100), with the following Steps: - Establishment of a first session (201) between an application program (112) and a service computer system (150) via a network (116), - Reception of a transaction request (158) via the first session by the service computer system from the application program (112), - generation of a request (166) by the service computer system based on the receipt of the transaction request, the request from the service computer system sig ned and the request contains an attribute specification that consists of the ID token for carrying out the transaction contains attributes to be read, transaction data for specifying the transaction, an identifier (180) of the request, a URL of an ID provider computer system and a URL of the service computer system, - transmission of a website (160) and the request via the first session from the service computer system to the user computer system, the website having an input field (162) for entering additional information (168) for carrying out the transaction, - the website is displayed by the application program and the additional information is entered by the user in the input field, - setting up a second session (202) between the application program (112) and the ID provider computer system via the network using the URL of the ID provider computer system, the second session being set up with a secure transport layer, - Forwarding of the request and the additional information from the application program to the ID provider computer system via the second session, - due to the receipt of the request, generation of a session ID for a third session (203) by the ID provider computer system and storage of the request and the additional information by the ID provider computer system, - sending a Message from the ID provider computer system to the application program (112) with the session ID of the third session and a logical address via the second session, - establishment of the third session between a program (113) of the user computer system and the ID Provider computer system via the secure transport layer of the second session, wherein the program can be different from the application program (112), - transmission of at least one certificate (144) of the ID provider computer system to the program (113), the certificate specifying includes reading rights of the ID provider computer system to read one or more of the attributes stored in the ID token, the transmission of the certificate ikats takes place via the third session, - the program (113) checks whether the reading rights specified in the certificate are sufficient to allow read access by the ID provider computer system to the attribute(s) to be read according to the attribute specification, and only if the reading rights are sufficient: a) establishment of a local connection (176) between the reader of the user computer system and the ID token, b) authentication of the user to the ID token, with a session key being agreed upon, c) establishment a fourth session (204) between the ID token and the ID provider computer system via the local connection and the third session with end-to-end encryption using the session key, d) mutual authentication of the ID token and the ID provider computer system via the fourth session, e) reading of the attribute or attributes according to the attribute specification by the ID provider computer system via the fourth session from the ID token. - Generation of a response (174), which contains the attribute or attributes read out and at least the identifier (180) of the request, and which is signed by the ID provider computer system, - Storage of the response for retrieval using the logical address, - Reading the response from the ID provider computer system by the user computer system by retrieving the response using a read command from the logical address via the network, - forwarding the response by the user computer system via the first session to the service computer system, - Allocation of the response to the request using the identifier contained in the response by the service computer system, - implementation of the transaction using the response by the ID provider computer system, the method comprising the following additional steps: - display an optically readable pattern on a screen (188) of a terminal (186), information being encoded in the optically readable pattern , which contains at least one URL of the service computer system and a payment amount, - detection of the pattern using an optical sensor (190) of the user computer system and decoding of the pattern, - calling up the URL of the service computer system, which was recorded via the pattern, to set up the first session, the payment amount being transmitted with the transaction request (158) to the service computer system via the first session, the terminal being an automat, the user entering a request into the automat, whereupon the Automat displays the pattern, and wherein the service computer system signals the automat to carry out the transaction, whereupon the automat fulfills the request entered by the user. procedure after claim 1 , wherein the application program is an Internet browser, and the additional program is a plug-in of the Internet browser, the plug-in being registered in a registry of an operating system of the user computer system with a plug-in identifier (184). , the message from the ID provider computer system to the Internet browser containing the plug- in identifier so that the plugin will be launched upon receipt of the message. procedure after claim 1 , wherein the program is another application program that can be started by the Internet browser by calling a local URL, the local URL includes a fixed port number according to the TCP protocol, the local URL together with the website is transmitted from the service computer system to the user computer system in order to cause the further application program to be started using the local URL through the Internet browser. procedure after claim 1 , 2 or 3 , the additional information being payment information for the user. procedure after claim 4 , wherein the additional information is encrypted by the user computer system using the public key of the service computer system and only the encrypted additional information is forwarded to the ID provider computer system via the second session, the encrypted additional information being included in the response and the encrypted additional information is decrypted after receipt of the response by the service computer system using the private key of the service computer system. Method according to one of the preceding claims, wherein the request contains payment information from the service computer system and the additional information contains payment information from the user, and the transaction data of the request contain a payment amount, the payment being initiated by the ID provider computer system, and the response does not contain the user's payment information. Method according to any of the preceding Claims 1 until 6 , the request containing payment information from the service computer system and the additional information containing payment information from the user, and the transaction data of the request containing a payment amount, with the payment being initiated by the service computer system, and the response containing the public key of the service computer system contains encrypted payment information of the user. Method according to one of the preceding claims, wherein the pattern is a one-dimensional, two-dimensional, high-capacity color barcode, maxicode, QR code or data matrix code or a chronological sequence of a plurality of such codes. Method according to one of the preceding claims, wherein the ID token is a document of value or security. Method according to one of the preceding claims, wherein the response also contains the additional information. procedure after claim 10 , wherein the additional information includes an OTP and the service computer system (150) checks the validity of the OTP, the transaction is only carried out if the OTP is valid. Computer system having a terminal for displaying an optically detectable pattern, an optical sensor connected to the user computer system, a service computer system (150), a user computer system (100), an ID provider computer system (136) and an ID token (106) associated with a user (102), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, with access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reading device of a user computer system (100), wherein the service computer system, the user computer system, the ID provider computer system and the ID token are designed to carry out the following steps: Establish a first session between an application program and a service computer ersystem via a network, - receipt of a transaction request via the first session by the service computer system from the application program, - generation of a request by the service computer system based on the receipt of the transaction request, the request being signed by the service computer system and the request an attribute specification, which contains attributes to be read from the ID token for carrying out the transaction, transaction data for specifying the transaction, an identifier of the request, a URL of an ID provider computer system and a URL of the service computer system, - transmission of a website and the request via the first session from the service computer system to the user computer system, the website having an input field for entering additional information for carrying out the transaction, - Display of the website by the application program and entry of the additional information by the user in the input field, - Establishment of a second session between the application program and the ID provider computer system via the network using the URL of the ID provider computer system, the second session is set up with a secure transport layer, - forwarding of the request and the additional information from the application program to the ID provider computer system via the second session, - based on receipt of the request, generation of a session ID for a third session by the ID provider - Computer system and storage of the request and the additional information by the ID provider computer system - Sending a message from the ID provider computer system to the application program with the session ID of the third session and a logical address via the second session - Structure the third session between a program of the user computer system and the ID provider the computer system via the secure transport layer of the second session, in which case the program can be different from the application program, - transmission of at least one certificate from the ID provider computer system to the program, in which case the certificate indicates reading rights of the ID provider computer system for includes reading one or more of the attributes stored in the ID token, with the certificate being transmitted via the third session, - checking by the program whether the reading rights specified in the certificate are sufficient to allow read access by the ID provider allow the computer system to access the attribute(s) to be read according to the attribute specification, and only if the reading rights are sufficient: a) establishment of a local connection between the reader of the user computer system and the ID token, b) authentication of the user to the ID Token, with a session key being agreed, c) establishment of a fourth session between the ID token and the ID provider computer system via the local connection and the third session with end-to-end encryption using the session key, d) mutual authentication of the ID token and the ID provider computer system via the fourth session, e) reading out the attribute or attributes according to the attribute specification by the ID provider computer system via the fourth session from the ID token. - Generation of a response, which contains the read attribute or attributes, the ID of the request, and which is signed by the ID provider computer system, - Storage of the response for retrieval using the logical address, - Reading the response from the ID provider computer system by the user computer system by retrieving the response using a read command from the logical address via the network, - the response is forwarded by the user computer system via the first session to the service computer system, - the response is assigned to the request Using the identifier that is contained in the response by the service computer system, - carrying out the transaction using the response by the ID provider computer system, the user computer system being designed to use the optical sensor (190) to detect the optically detectable Capture patterns from the display in order to then generate the transaction request with the transaction data and via the first S message to the URL of the service computer system, the service computer system sending a confirmation signal to the terminal after the transaction has been carried out, the terminal being an automat, in particular an ATM or a vending machine.

Images