DE102013022433B3 - Electronic transaction process and computer system - Google Patents

Abstract

Electronic transaction method using an ID token (106) 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), - receipt 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 on the basis of the receipt of the transaction request, the request being signed by the service computer system rt and the request an attribute specification, the attributes to be read from the ID token for the execution of the transaction, 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 includes - 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, - Display of the website by the application program and input of the additional information by the user in the input field, - Establishment of 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 ormation from the application program to the ID provider computer system via the second session, - on the basis of 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 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 over 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, whereby the program can be different from the application program (112), transmission of at least one certificate (144) from the ID provider computer system to the Program (113), wherein the certificate is an indication of reading rights of the ID provider computer system to read one or more of the stored in the ID token rten attributes, the certificate being transmitted via the third session, - check by the program (113) as to whether the reading rights specified in the certificate are sufficient to permit read access by the ID provider computer system to the one or more according to the attribute specification to allow attributes to be read, 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 is agreed, 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 or attributes according to the attribute specification by the ID provider computer system stem via the fourth session from the ID token. Generation of a response (174) which contains the attribute or attributes read and at least the identifier (180) of the request, and which is signed by the ID provider computer system, - storage 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 through the user computer system via the first session to the service computer system, - assignment of the response to the request with the aid of the identifier contained in the response by the service computer system, - execution of the transaction with the aid of the response by the ID provider computer system, wherein the method comprises the following further steps: - Display of an optically readable pattern on a screen (188) of a terminal (186), wherein in the optically lesb aren pattern, information is encoded which contains at least a 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 with the transaction request (158) being transmitted to the service computer system via the first session, the terminal being a mobile telecommunications device with a charge recording function, the Telecommunication device displays the pattern with a payment amount recorded by the charge recording function, the service computer system signaling the execution of the transaction to the telecommunication device via a cellular network.

Description

The present patent application is a divisional application to the parent application 10 2013 212 627.1.

description

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

Various transaction methods are known for electronic commerce, that is to say so-called eCommerce. This includes the usual payment methods such as a paper transfer or cash on delivery as well as electronic payment methods such as credit card payment, payment via online banking, collection / billing systems, factory systems, electronic direct debit, prepaid procedures, payment by telephone bill as well Cell phone payment systems. Such payment methods are sometimes also used for eGovernment 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.

A technical guideline on a server to simplify electronic proof of identity in web applications is known from the prior art (BSI TR-03130, Technical Guideline eID Server, Federal Office for Information Security, Ver. 1.6, April 20, 2012), a technical guideline on an API framework to provide 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) as well as an information processing device with optical data reader, server, and a method for electronic commerce ( US 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" here is a financial transaction, such as the payment of a payment amount by making a transfer, direct debit or debiting a credit card, an order process for ordering and delivering a physical good or data as well as other logistical, commercial and / or understood financial transactions.

A “session” is understood here as a temporary communication connection, that is to say a so-called communication session, which according to the OSI layer model can relate to the transport layer or the application layer. In particular, a session can be an http session or an https session, in the latter case the transport layer is protected by symmetrical 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, identity cards, visas and driver's licenses, vehicle documents, vehicle documents, company ID cards, health cards or other ID documents as well as chip cards, means of payment, in particular bank notes , Bank cards and credit cards, waybills or other credentials, such as an entry 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 this is cryptographically linked to a hardware token, that is to say, for example, to a so-called secure element.

In particular, such a soft token cryptographically linked to a secure element can 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 out at least one attribute from the ID token of a user. The ID provider computer system is preferably in one so-called trust centers operated in order to create the highest possible level of security.

A “service computer system” is understood here to mean a computer system which has a network interface for connection 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 that provides an eCommerce or eGovernment application, in particular an online shop or an agency server.

A “user computer system” is understood here to mean a computer system to which the user has access. This may be, for example, a personal computer (PC), a tablet PC or a mobile device, in particular a smart phone 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 connection to the network, and the 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, March 25, 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. On the basis of the receipt of the request by 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.

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 that is used to assign a public key of an asymmetric cryptosystem to an identity, such as a person or a 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 which 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 read access. These attributes can be personal attributes of the user, such as his name, place of residence and age. These attributes can be used in their combination as user identification in order to access the payment information of the registered user. Alternatively or in addition, a pseudonym of the user, which is at least temporarily stored by the ID token, can also be used as a user identifier.

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

According to embodiments of the invention, a first session is first established between the Internet browser of the user computer system and the service computer system via the Internet, the first session being 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 goods via the service computer system and would like to pay for these ordered goods, for which purpose the user enters the corresponding transaction request in the Internet browser, which is transmitted to the service computer system over 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 designed as a SAML request. The request, for example the SAML request, contains an attribute specification which is derived from the ID token for carrying out the transaction attributes to be read out specified. These can be attributes that identify the user who is assigned to the ID token and / or that specify payment information, such as an account connection or credit card information, and / or attributes that relate to the ID token itself, such as its period of validity, date of issue and / or the issuing organization or authority.

In particular, the attribute specification can contain the date of birth of the user if, for example, the age of majority of the user 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, that is, for example, a payment amount and account information, in particular the account details of the service computer system on which the payment is to be made. The request also contains 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 based on the request from the ID provider computer system is to be generated.

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.

On the basis of 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 a so-called app. The request is transmitted together with the website, but it 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 passed on 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, on the basis of the receipt of the request via the second session, the ID provider computer system generates an identifier for a third session that has yet to be established, i.e. a so-called session ID. The ID provider computer system stores the request as well as 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 about 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 called up.

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 for the Internet browser or an application program that differs from the Internet browser.

The ID provider computer system then transmits to the program that information about the third session that is required for reading the attribute or attributes from the ID token. This information contains at least one certificate of the ID provider computer system, which contains an indication of reading rights of the ID provider computer system for reading 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 Smart-Cards.
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 attribute or attributes to be read in accordance with the attribute specification of the request. If the reading rights of the ID provider computer system are sufficient, the following additional 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 reader. 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 reader. Tokens with USB, BlueTooth or microSD cards are also possible here, as well as virtual smart cards.
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 recording of a biometric feature of the user. A session key is agreed upon when authenticating the user with the ID token. In particular, a session key can be agreed with the aid of a Diffie-Hellman protocol.
3. c) A fourth session is then set up on the application layer, namely between a program of the ID token and the ID provider computer system, this fourth session running over the local connection and the third session and an additional one on the application layer End-to-end encryption is carried out using the session key agreed in step b.
4. d) Mutual authentication of the ID token and the ID provider computer system then takes place via the fourth session, for example with the aid of a challenge-response protocol.
5. e) The attribute or attributes in accordance with the attribute specification that the ID provider computer system received with the request are now read from the ID token by the ID provider computer system via the fourth session. This requires the successful authentication of the user in step b as well as the successful mutual authentication of the ID token and the ID provider computer system in step d) and is encrypted via the fourth session, so that a maximum of 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 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 here via the identifier of the request, which is also included 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 with the aid of the logical address, for example the URL, and forwards the response to the service computer system via the first session. With the help of the identifier of the response, this is assigned to the request and thus to the requested transaction and then the transaction is carried out by the service computer system, that is, for example, 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, in the program of the user computer system to a browser plug-in Internet browser, wherein the web browser is a standard browser program, such as Microsoft Internet Explorer ^®, Safari ^®, Google Chrome ™ or Firefox ^® can act. Alternatively, the program of the user 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 an account connection of the user from which the payment amount specified in the request is to be debited or withdrawn.

The so-called clearing, that is, the checking of the customer's creditworthiness, and the initiation of 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 Knowledge of the user's payment information, that is to say in particular of his account details, must be acquired.

Alternatively, the user can encrypt his payment information with the public key of the service computer system, so that only the encrypted payment information of the user 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, according to which, according to the invention, is designed as a mobile telecommunications device, in particular as a so-called smart meter, for billing e.g. electricity or gas consumption, taximeter or smartphone with a billing function.

For example, the URL of the service computer system, the payment amount and the payee can be output on the smartphone of a seller in the form of an optically recorded pattern and recorded with the camera of the user computer system, which can also be designed as a smartphone. In this way, everyday payment transactions can be securely and conveniently processed.

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 in the following figures that are identical to one another or correspond to one another are each identified by the same reference symbols.

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

The protected storage area 120 of the ID token 106 is used to store a reference value that is used to authenticate a user 102 towards the ID token 106 is needed. 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 is used to authenticate the user to the ID token 106 can be used.

The protected area 122 is used to store a private key and the protected memory area 124 is used to store attributes, for example the user 102 , such as its name, place of residence, date of birth, gender and / or attributes that relate to the ID token itself, 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 that is stored in the protected storage area 122 stored private key is assigned. 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 in the electronic memory 118 of the ID token 106 be saved. 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, ie to authenticate the user 102 towards the ID token.

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

Alternatively, a biometric feature of the user is used 102 detected. For example, the ID token has 106 for this purpose a fingerprint sensor or a fingerprint sensor is connected to the user computer system 100 connected. The one from the user 102 captured biometric data are through Execution of the program instructions 130 with those in the protected memory area 120 stored biometric reference data compared. If the user agrees sufficiently 102 captured biometric data with the biometric reference data applies to the user 102 as authenticated.

The program instructions 134 are used to execute the ID tokens 106 relevant steps of a cryptographic protocol for authentication of an ID provider computer system 136 towards 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, the cryptographic protocol implements an Extended Access Control method, as specified by the International Aviation Authority (ICAO) for machine-readable travel documents (MRTD). The ID provider computer system authenticates itself through successful execution of the cryptographic protocol 136 towards the ID token and thereby has its read authorization to read the in the protected memory area 124 saved attributes. The authentication can also be mutual, ie also the ID token 106 must then contact the ID provider computer system 136 authenticate using the same or a different cryptographic protocol.

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

The ID token 106 has an interface 108 for communication with a corresponding interface 104 of a user computer system 100 (compare 2 ). The interface can be made contactless or with contacts. 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 be done through the processor 128 of the ID token 106 because the protected memory area 124 as well as the other protected memory areas 120 , 122 not directly, for example via a bus system with the interface 108 connected but only to the processor 128 , that is, access via the interface 108 directly to the protected memory area 124 is already excluded in terms of circuitry. The processor alone 128 can therefore read on the protected memory area 124 access to then, if necessary, the attributes read out via the interface 108 to spend.

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

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

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

The network can be a computer network such as the Internet. In particular, the network 116 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, for example, a certificate based on a PKI standard, such as X.509.

The ID provider computer system 136 also has at least one processor 145 for executing program instructions 146 and 148 . By Execution of the program instructions 146 become the the ID provider computer system 136 relevant steps of the cryptographic protocol carried out. Overall, the cryptographic protocol is made by executing the program instructions 134 through the processor 128 of the ID token 106 as well as by executing the program instructions 146 through the processor 145 of the ID provider computer system 136 implemented.

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

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 towards the ID token 106 the trust anchor for the authenticity of the ID token 106 the attributes read out.

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, the user can 102 online over the network 116 open an account with a bank or use other financial or banking services. The service computer system 150 can also be designed as an online department store, so that the user 102 for example can purchase a mobile phone or the like online. Furthermore, the service computer system 150 can also be designed for the delivery of digital content, for example for downloading music and / or video data.

The service computer system 150 has a network interface for this purpose 152 to connect to the network 116 . Furthermore, the service computer system 150 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 carry out transactions.

• - 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 one or more attributes of the user 102 and / or its ID token 106 check against one or more specified criteria. Only if this test is passed will the order or the order of the user be accepted 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 further assumed without loss of generality that this is an Internet browser. The user 102 gives a URL of the service computer system 150 in the Internet browser, so that thereupon a first session 201 between the Internet browser 112 and the service computer system 150 over the network 116 is being built. The user can then use one of the service computer system via the first session 201 150 Request the service offered, such as ordering a product, requesting data to be downloaded or requesting a financial transaction to be carried out. This is done by the Internet browser 112 a corresponding transaction request 158 to the service computer system 150 that signals this request.
• The service computer system thus receives a transaction request from the Internet browser via the first session 158 of the user 102 .
• - Due to the receipt of the transaction request 158 The service computer system generates via the first session 201 150 a request 166 . The request 166 contains (i) an attribute specification of the attributes to be read from the ID token for the execution of the transaction. These attributes can be personal information about the user 102 and / or data relating to the ID token 106 himself or a pseudonym of the user 102 , which is from the ID token 106 is available, act. The request also contains (ii) the transaction data for specifying the transaction, such as, for example, a payment amount for the purchase of the ordered product or the implementation of the ordered service to the service computer system 150 or to be paid to a third party, and / or other transaction data specifying the transaction to be carried out. The request also contains (iii) an identifier 180 of the request, for example a GUID, which is used for the so-called binding of the request and a response received thereupon 174 is required. The service computer system 150 have a GUID generator. The request also contains (iv) a URL of the ID provider computer system 136 and (v) a URL of the serving computer system 150 itself. The request is made by the service computer system 150 signed, namely with the aid of a private key of the service computer system 150 . With the request 166 it can be a SAML request or another request from a request-response protocol.
• - In response to the transaction request 158 then sends the service computer system 150 a website 160 via the first session 201 to the user computer system 100 , with the website 160 an input field 162 for entering additional information by the user 102 for the transaction and furthermore an input element 164 that the user 102 for example, by clicking on it, you can select if the website 160 through the internet browser 112 is played back to forward the request 166 to allow. Together with the website 160 the Request 166 via the first session 201 to the Internet browser 112 transfer.
• - Due to the reception of the website 160 and the request 166 becomes the website 160 through the internet browser 112 reproduced so that the user 102 the additional information in the input field 162 can enter. For example, the additional information is an account connection for 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 for the execution of the transaction, for which the user 102 for example a one-time password (OTP) in the input field 162 enters. This is preferably done by the user 102 additional information entered 168 with the public key of the service computer system 150 by the user computer system 100 encrypted in order to receive a corresponding cipher.
• - Then there is a second session 202 between the Internet browser 112 and the ID provider computer system 136 over the network 116 built using the URL of the ID provider computer system 136 that 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.
• - The request 166 and the additional information 168 or just that with the help of the public key of the service computer system 150 obtained cipher of the additional information 168 from the user computer system 100 to the ID provider computer system 136 forwarded.
• - On the basis of the receipt of the request 166 through the ID provider computer system 136 generates this by executing its program instructions 170 a session ID for a third session 203 still to be set up. The request 166 and the additional information 168 are 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. With the help of the logical address, the ID provider computer system 136 based on the request 166 response to be generated 174 can be retrieved. In particular, the logical address can be designed as a URL. The message 172 is via the second session 202 from the ID provider computer system 136 to the internet browser 112 Posted.
• - Based on the receipt of the message 172 becomes the third session 203 between the program 113 of the user's computer system 100 and the ID provider computer system 136 Established via the secured transport layer of the second session 202. The program is an example 113 to a browser plug-in of the internet browser 112 . Alternatively, it can be the program 113 can also be another application program. It is also possible to use the functionalities of the Internet browser 112 and those of the program 113 to be implemented in a program.
• At least the certificate is then sent via the third session 203 144 to the program 113 transfer.
• - Through the program 113 it is then checked whether the in the certificate 144 The specified read rights are sufficient for read access to the ID provider computer system 136 to the one or more according to the attribute specification contained in the request 166 is to allow attributes to be read. The following steps are only carried out if these read rights are sufficient:
  1. a) It will be a local connection 176 between the interfaces 104 and 108 built up. For example, appears on the screen of the user computer system 100 a request for the user 102 to introduce the ID token 106 into a reader of the user computer system 100 the interface 104 or to hang up the ID token 106 to a contactless interface 104 .
  2. b) The user 102 then authenticates itself to the ID token, for example by entering its PIN into the user computer system 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 as part of the authentication of the user.
  3. c) Assuming that the user is successfully authenticated, a fourth session 204 is established between the ID token 106 and the ID provider computer system 136 established over the local connection 176 and the third session 203. The fourth session 204 is protected with end-to-end encryption with the aid of the session key that was agreed when the user was authenticated in step b).
  4. d) Mutual authentication of the ID token then takes place via the fourth session 106 and the ID provider computer system 136 with the help of the respective private key, i.e. the one in the protected memory area 122 stored private key of the ID token 106 and the private key 142 of the ID provider computer system 136 . The certificates of the ID token 106 from the memory area 126 (compare 1 ) as well as the certificate 144 of the ID provider computer system 136 be exchanged over the fourth session.
  5. e) Assuming 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 then reads the ID provider computer system 136 the attribute or attributes according to the attribute specification from the ID token 106 from, the attributes through the end-to-end encryption during the transmission of the ID token 106 to the ID provider computer system 136 to be protected. To this end, the ID provider computer system sends a read command to the ID token via the fourth session 204 via the fourth session 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 should be read out. By executing the program instructions 178 is then used by the ID provider computer system 136 the response 174 , for example a SAML response, on the request 166 generated. The response 178 contains the previous session 240 from the ID token 106 read out attributes, the additional information 168 or - alternatively - not the additional information 168 , but only the cipher of the additional information 168 , as well as the identifier 180 who have favourited the service computer system 150 initially for the request 166 has forgiven. The response 174 is used by the ID provider computer system 136 with the help of the private key 142 signed and then in the store 140 saved so that the Request 166 can be called up from the logical address.
• - The user computer system 100 , such as its internet browser 112 , then reads the response using the logical address 174 for example, via the second session 202 from the memory 140 .
• - The response 174 is then used by the user's computer system 100 , for example from the Internet browser 112 , via the first session 201 to the service computer system 150 forwarded. It can be provided here that the user 102 from the internet browser 112 to enter a confirmation is requested before the response 174 is forwarded to the service computer system. It can also be provided that the content of the response 174 is displayed in full or in part, in particular the attributes read out from the ID token and / or the additional information 168 so that the user 102 can convince of the correctness of this data before it is sent to the service computer system 150 forwarded to carry out the transaction.
• - The service computer system 150 arranges the received response 174 the request 166 based on the matching identifiers 180 of the request 166 and the response 174 to.
• - The service computer system 150 then checks the signature of the response 166 and reads the required attribute or attributes from the response 174 out. 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 predetermined criteria. These criteria can be, for example, the age or the creditworthiness of the user 102 act. The attribute can also be a pseudonym of the user 102 act, with the help of which the service computer system 150 then one in a database of the service computer system 150 saved attribute of the user 102 , such as reading out a delivery address. The test criterion here is whether a user is familiar with the in the response 174 Contained pseudonym on the part of the service computer system 150 is registered.
• - Returns the test of the service computer system 150 that the transaction can be carried out, the transaction is based on the transaction data and the additional information 168 carried out.

According to one embodiment of the invention, it is the program, for example 113 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, for example, a ^Windows® operating system, Android ™ or ^iOS® . In this case the message includes 172 from the ID provider computer system to the Internet browser 112 this plug-in identifier 184 so that the plug-in 113 is started based on the receipt of the message.

According to another example, the program is 113 one from the internet browser 112 separate application program, such as a so-called citizen app or ID card app. This application program 113 is used by the internet browser 112 started by calling up a local URL, the local URL containing a fixed port number according to the TCP protocol. This local url comes along with the website 160 from the service computer system 150 to the user computer system 100 transferred via the first session 201 to start the application program 113 using the local URL through the internet browser 112 to effect.

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

Alternatively, however, it is also possible for the ID provider computer system to carry out the payment 136 is triggered. This can be done so that the ID provider computer system 136 the transaction data required for this via the request 166 and the additional information 168 receives and then carries out or initiates the payment. The response 174 then contains 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 to protect the confidentiality of this additional information 168 is advantageous because this additional information 168 then only have to contact the trustworthy ID provider computer system 136 be disclosed. The actual transaction, for example the delivery of the ordered product, is then carried out after receipt of the payment confirmation, which is included in the response 174 is included by the service computer system 150 caused.

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

A terminal belongs to the computer system 186 , which can be, for example, an automatic machine, in particular an automated teller machine or a vending machine. For example, the user can 102 into the terminal 186 enter an amount of money to withdraw cash from their account. On a display 188 of the machine, an optically detectable pattern is then displayed, such as a QR code that contains a URL of the service computer system 150 as well as that of the user 102 includes desired amount of money.

This optical pattern is used by the display 188 with the help of a camera 190 of the user's computer system 100 detected. The user computer system 100 then generates the transaction request 158 indicating this amount of money. The first session 201 is here with the help of the URL of the service computer system detected from the optical pattern 150 established and the transaction request 158 the desired amount of money is sent via this first session 201 to the service computer system 150 transmitted. The service computer system 150 then generates a corresponding request 166 to find the attributes and additional information required to pay out the desired amount of money 168 query.

Then either through the ID provider computer system 136 or through the service computer system 150 the debit of an account of the User 102 which of these, for example, in the additional information 168 has indicated. Due to the receipt of the response 174 and the initiation of payment is then received by the terminal 186 a signal to issue the desired amount of money, for example in the form of cash or to top up a user's cash card 102 . This can be done so that the terminal 186 directly with the service computer system 150 connected or through the network 116 .

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

In another application, the terminal 186 be a mobile telecommunications device, in particular a smartphone. If the user 102 from the owner of the terminal 186 wants to buy something, so gives the owner of the terminal 186 the corresponding purchase price in the terminal 186 one, so then on the display 188 in the form of the optically detectable pattern, in turn, this purchase price as the payment amount and the URL of the service computer system 150 is issued. When the transaction is finished, the terminal receives 186 from the service computer system 150 a signal that indicates that the payment process has taken place and the owner of the terminal 186 then gives the goods to the user 102 from. This can also be implemented in the cash register system of a supermarket, for example. Another application is a taximeter that records taxi fees or another consumption meter, such as a consumption meter for electricity or gas consumption in a household, in particular a so-called smart meter.

List of reference symbols

100

User computer system

102

Users

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 memory area

122

protected memory area

124

protected memory 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 memory 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

message

174

Response

176

local connection

178

Program instructions

180

Identifier

182

Read command

184

Identifier

186

terminal

188

Display

190

camera

Claims (12)

Electronic transaction method using an ID token (106) 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), - receipt 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 and the request is an attribute specification, the attributes to be read from the ID token for the execution of the transaction, 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 includes - 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, - Display of the website by the application program and input of the additional information by the user in the input field, - Establishment of 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 to Set information from the application program to the ID provider computer system on the second session, - on the basis of 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 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 over 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, whereby the program can be different from the application program (112), transmission of at least one certificate (144) from the ID provider computer system to the Program (113), wherein the certificate is an indication of reading rights of the ID provider computer system to read one or more of the in the ID token n contains stored attributes, the transmission of the certificate taking place via the third session, - Check by the program (113) whether the reading rights specified in the certificate are sufficient to allow read access of the ID provider computer system to the or according to the Attribute specification to allow attributes to be read, and only if the reading rights are sufficient: a) Establishing 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, whereby a Session key is agreed, 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 or attributes according to the attribute specification by the ID-Pr ovider 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 of the response from the ID provider computer system by the user computer system by calling up the response by means of 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 with the aid of the identifier contained in the response by the service computer system, implementation of the transaction with the aid of the response by the ID provider computer system, the method comprising the following further 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 a URL of the service computer system and a payment amount, Detection of the pattern with the help of 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 detected via the pattern, to set up the first session, the payment amount with the Transaction request (158) is transmitted to the service computer system, the terminal being a mobile telecommunication device with a billing function, the telecommunication device displaying the pattern with a payment amount recorded by the billing function, the service computer system carrying out the transaction signaled to the telecommunication device via a cellular network. Procedure according to Claim 1 , the application program being an Internet browser, and the further program being 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) , wherein the message from the ID provider computer system to the Internet browser contains the plug-in identifier, so that the plug-in is started on the basis of the receipt of the message. Procedure according to Claim 1 The program is another application program that can be started by the Internet browser by calling up a local URL, the local URL containing 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 according to Claim 1 , 2 or 3rd , the additional information being payment information for the user. Procedure according to Claim 4 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 after the response has been received by the service computer system, it is decrypted 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 wherein the additional information contains payment information from the user, and wherein 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 one of the preceding Claims 1 to 6th , wherein the request contains payment information of the service computer system and wherein the additional information contains payment information of the user, and wherein the transaction data of the request contain a payment amount, the payment being initiated by the service computer system, and the response with the public key 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 several such codes. Method according to one of the preceding claims, wherein the ID token is a value or security document. Method according to one of the preceding claims, wherein the response also contains the additional information. Procedure according to Claim 10 , wherein the additional information contains an OTP and the service computer system (150) checks the validity of the OTP, the transaction only being carried out if the OTP is valid. Computer system with a service computer system (150), a user computer system (100), an ID provider computer system (136) and an ID token (106) which is assigned to a user (102), the ID token being a 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 a communication interface (108) for communication with a reading device of a user computer system (100), the service computer system, the user computer system, the ID provider computer system and the ID token being designed to carry out the following steps : - Establishment of a first session between an application program and a service computer system 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 on the basis of the receipt of the transaction request, the request being signed by the service computer system and the request being an attribute specification derived from the ID token contains attributes to be read out for the execution of 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 the execution of the transaction, - display of the website by the application program and input of the additional information by the user in the input field, - establishment of a second session between en the application program 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 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, - Establishment of the third session between a program of the user computer system and the ID provider computer system via the secure transport layer of the second Session, whereby the program can be different from the application program at least one certificate of the ID provider computer system to the program, the certificate containing an indication of 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 via the third Session takes place, - Check by the program whether the reading rights specified in the certificate are sufficient to allow read access by the ID provider computer system to the attribute or attributes to be read in accordance with the attribute specification, and only if the reading rights are sufficient: a ) Establishing a local connection between the reader of the user computer system and the ID token, b) Authenticating the user against the ID token, whereby a session key is agreed, c) Establishing 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 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 that contains the attribute or attributes read out, the identifier of the request, and that 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 calling up the response by means of a read command from the logical address via the network, - Forwarding of the response by the user computer system to the service computer system via the first session, - Assignment of the response to the request Help of the identifier contained in the response by the service computer system, - Execution of the transaction using the response by the ID provider computer system, whereby the service computer system, the user computer system, the ID provider computer system and the ID tokens are designed to carry out the following further steps: - Display of an optically readable pattern on a screen (188) a terminal (186), information being encoded in the optically readable pattern which contains at least a URL of the service computer system and a payment amount, - detection of the pattern with the aid of 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 with the transaction request (158) being transmitted to the service computer system via the first session, the terminal being a mobile telecommunication device with a billing function, the telecommunication device displaying the pattern with a payment amount recorded by the billing function, the service computer system carrying out the process the transaction is signaled to the telecommunication device via a cellular network.

Images