METHOD FOR THE SECURE IDENTIFICATION OF A PERSON BY A VERIFICATION AUTHORITY

Description

[0001] The invention relates to a method for secure, privacy-protecting remote identification of a person using an identification card by an external identification provider, and in this context relates in particular to a method for the secure identification of a person with an identification card by a verification authority vis-à-vis a service provider.

[0002] Traditional centralized identification solutions follow a classic service provider / identification provider concept, in which a central authority confirms a person's identity and forwards the corresponding proof to the service provider. However, with such centralized identification solutions, tracking of online activities cannot be ruled out, as a history of identifications can be created for each individual.

[0003] Decentralized, certificate-based identification solutions lack such a central authority; however, service providers must then additionally verify the validity and status of the certificate. Cross-provider tracking is possible because the certificate serial numbers are intended to be unique. Furthermore, service providers may receive personal data from the certificate that is irrelevant to their business, which contradicts data minimization principles.

[0004] The German eID solution, based on Extended Access Control (EAC), enables decentralized identification of individuals without transmitting unsolicited data to the service provider and without allowing cross-provider tracking. However, a weakness of this approach lies in the fact that all relevant communication and security protocols must be implemented by the service provider. These protocols are highly complex and therefore difficult to use. Furthermore, the identification process is prone to errors, and there is a risk that important checks will be omitted.

[0005] Document US 2008 / 235513 A1 discloses a method whereby a trust provider uses established relationships with a client device and server of an e-commerce merchant or service provider to ensure the identity of each to the other.

[0006] For these reasons, specialized identification providers are often used to handle all the technical aspects of the identification process. However, this can also be problematic, as the eID system lacks technical measures to prevent these providers from storing personal data and combining datasets from multiple service providers. Because of the lack of such technical measures, requirements for the organization of the identification process must be defined. If these requirements are set too high, there is a risk that only a few providers will qualify as identification providers. This can lead to the system becoming almost centralized with only a few potential attack vectors, and the original objectives can no longer be guaranteed.Another disadvantage is that if no external identification provider is used, the service provider has no proof that an identification has taken place, so that it can be subsequently denied.

[0007] Based on this, the invention aims to enable the secure delegation of certain tasks within the context of identifying a person. In particular, it aims to provide a method that allows the secure involvement of external providers for carrying out secure, privacy-protecting remote identification of individuals using existing software components and systems.

[0008] This problem is solved by the features of the independent claims. Further developments of the invention are the subject of the dependent claims.

[0009] The invention provides a method for the secure identification of a person with an identification card by a verification authority vis-à-vis a service provider. The method provides that a secure, unilaterally authenticated communication connection is established between the identification card and the service provider, and that a secure, mutually authenticated communication connection is established between the service provider and the verification authority.

[0010] In this process, communication between the identification card and the verification authority is conducted exclusively via the service provider acting as a proxy. The service provider intercepts all messages exchanged between the identification card and the verification authority and forwards them with its own identifier, thus establishing a logical communication channel between the identification card and the verification authority.

[0011] A first, authenticated key agreement for encrypted communication between the verification authority and the identification card is established via the logical communication channel. The verification authority then uses this first key material to encrypt and verify the validity of the identification card via the same logical communication channel.

[0012] Furthermore, a second, authenticated key agreement is established between the service provider and the identification card for the encryption and authentication of required identification data and / or the results of card operations. The required identification data is then encrypted by the identification card using the second key material, and the encrypted data is then transmitted to the verification authority via the logical communication channel using the first key material.

[0013] The verification authority then transmits the identification data, encrypted with the second key material, to the service provider and confirms that the identification data contained in the transmission originates from an identification card whose validity has been successfully verified by the verification authority. The service provider then decrypts the identification data transmitted by the verification authority using the second key material.

[0014] After completing the procedure, the service provider has the necessary identification data of the individual to provide the service, without the verification authority having access to any of the individual's personal data during the verification process. Due to the established logical communication channel between the identification card and the verification authority, the latter does not see any data from the identification card that could be misused for uniquely identifying an individual ("fingerprinting"). The identification data required by the service is only available to the verification authority in a form encrypted with the second key material and cannot be decrypted by the verification authority, as the second key material is based on a key agreement between the identification card and the service provider.

[0015] Since encryption in the context of the present invention is almost always carried out together with authentication, the term "encrypted" usually also includes authentication.

[0016] In a preferred embodiment, the method employs Extended Access Control (EAC) protocols, in particular Chip Authentication, Terminal Authentication, and / or PACE (Password Authenticated Connection Establishment). The method can thus rely on formally verified protocols with secure cryptographic primitives. An existing EAC infrastructure can be retained as a basic framework; the existing software components simply need to be supplemented with the extended functionalities described in this application.

[0017] The use of the aforementioned EAC protocols enables privacy-protecting remote identification of the identification card holder. As previously explained, the verification authority has no access to the personal data of the person being identified. It only sees the raw data transmitted by the identification card, but no metadata added later that is irrelevant to the EAC protocols, such as the IP address of the device to which the identification card is connected, or other characteristics that the verification authority could misuse for fingerprinting.

[0018] In an advantageous procedure, a terminal authentication is performed with the verification instance to carry out the first key agreement, and if the terminal authentication is successful, a chip authentication is performed with the verification instance.

[0019] To execute the second key agreement, if the procedure is advantageous, terminal authentication is performed with the service provider, and if terminal authentication is successful, chip authentication is performed with the service provider.

[0020] In a further development of the procedure, it is envisaged that the service provider and the identification card each temporarily store verification data for the identification that has taken place, that the identification card transmits its verification data to the service provider, and that the service provider, in order to authenticate the exchange, checks the verification data transmitted by the identification card against the verification data it already possesses. If a match is found, the identification process can be considered successfully completed.

[0021] The aforementioned supporting documentation advantageously includes an authorization certificate from the service provider, a static public key of the identification card, an ephemeral public key of the service provider, and / or the contents of the transmitted identification data. In particular, the supporting documentation may contain all of the aforementioned information.

[0022] In an advantageous further development of the invention, it is provided that the verification authority checks the status of the identification card by means of Restricted Identification.

[0023] An eID card is advantageous for identification. The identification card can be integrated into a terminal device, such as a laptop or smartphone, for example, within a secure element. Alternatively, the identification card can be a standalone system, such as a chip card, which is connected to a terminal device via a reader. In both cases, local client software on the terminal device guides the user through the identification process and handles the communication with the identification card.

[0024] In a properly conducted procedure, the service provider possesses an authorization certificate issued by the issuer of the identification card, which specifies the identification data that the service provider can read. The service provider transmits this authorization certificate to the identification card at the beginning of the procedure to obtain the individual's consent for identification.

[0025] Furthermore, in an advantageous procedure, the verification authority possesses an authorization certificate issued by the issuer of the identification card, which prevents the reading of personal data. This authorization certificate is transmitted to the identification card at the beginning of the procedure, in particular by the service provider together with its authorization certificate, in order to obtain the person's consent to identification involving the verification authority.

[0026] In the described process, assuming that several thousand cards possess the same static chip authentication key, the identification card, by design, leaves no unique characteristics that could be traced back to a person or a small group of people until the identification data is read. Since the contents of the identification data cannot be decrypted by the verification authority, the process does not allow for tracking of the identification card users, thus ensuring their anonymity to the verification authority.

[0027] Within the framework of the procedure, the service provider may, in particular, perform the following tasks: forwarding messages; generating keys for authorization certificates; signing challenges; decrypting messages (not secure messaging); performing a normal key agreement, calculating hash and MAC, and verifying single-party signatures.

[0028] Further embodiments and advantages of the invention are explained below with reference to the figures, in the representation of which a scale and proportion-accurate reproduction has been omitted in order to increase clarity.

[0029] They show: Fig. 1 schematically shows the physical and logical connections between the parties involved in a method according to the invention, and Fig. 2 in (a) to (k) schematically shows the initial state and successive partial steps of a preferred method for the secure identification of a person by a verification instance.

[0030] Figur 1 Figure 1 schematically illustrates the connections between the parties involved in a method according to the invention: an eID card 10, a service provider 12, and an identification provider 14, which is also referred to as the verification instance in this description. The eID card 10 can be accessed by an end device (not shown), such as a laptop or a smartphone. The eID card 10 can be integrated into the end device, for example, in a secure element, or it can be connected to the device as a standalone system, for example, in the form of a chip card, via a card reader. In both cases, the end device contains local client software that communicates with the card 10 and guides the user through the identification process described below.

[0031] In this procedure, a direct connection 11 or 13 exists between card 10 and service provider 12, and between service provider 12 and identification provider 14, respectively, in which the connected parties are directly addressable in a communication protocol. A protocol for encrypting data during transmission, such as TLS, is used for communication. In connection 11, only service provider 12 is authenticated; in connection 13, both service provider 12 and identification provider 14 are authenticated.

[0032] Furthermore, the process provides a logical communication channel 15 between the card 10 and the identification provider 14. This channel is created by the service provider 12 intercepting messages between the card 10 and the identification provider 14 and forwarding each message with its own identifier, so that each party can reach the other via the service provider 12. A continuous exchange of messages defines an identification session. Through this approach, the identification server 14 sees only the raw data sent by the card 10, but no metadata that was added later and is irrelevant to the Extended Access Protocol, such as the IP address of the terminal device to which the card 10 is connected, or other characteristics that the identification provider 14 could misuse to uniquely identify a person.

[0033] The process of identification using a method according to the invention is now described with reference to Fig. 2 explained in more detail, whereby Fig. 2(a) the initial state and Fig. 2(b) bis 2(k) The figure shows various sub-steps in a preferred procedure. The following are labeled in the figure: Sign a function that creates a cryptographic signature over certain data using a private key, Verify a function that verifies a cryptographic signature over specific data using a public key, Comp a function that compresses a public key into a distinctive value, MAC a function that uses a symmetric key to create a message authentication code over specific data, KA a function that performs a cryptographic key agreement using a private key and a public key and returns a value, KeyGen a function that creates an asymmetric key pair, rand a function that generates a random, cryptographically secure value, KDF a function that derives one value into another, depending on a given context, H A function that creates a hash of certain data, and is called concatenation.

[0034] Communication between two parties is represented by arrows, where the direction of an arrow indicates the direction of the communication flow. "id" stands for unencrypted communication (although encryption can be implemented using another protocol, such as TLS), and ← K ENC SM K AUTH SM stands for communication that uses K ENC SM encrypted and K AUTH SM is authenticated.

[0035] Extended Access Control (EAC) protocols pertain to security mechanisms in electronic identity documents. EAC comprises various protocols that are executed in a specific sequence depending on the type of electronic identity document being read. EAC protocols include, in particular, Chip Authentication (CA) and Terminal Authentication (TA), which are executed together with Basic Access Control (BAC) or Password Authenticated Connection Establishment (PACE) and Passive Authentication (PA). These protocols and their interaction are described in more detail in the Technical Guideline BSI-TR-03110, a copy of which is incorporated into this application.

[0036] Figur 2(a) Figure 1 shows the initial state 20 at the start of the method according to the invention. The eID card 10 is personalized and contains the personal data of its holder. As part of the personalization process, a key pair for chip authentication was created, among other things. [The last sentence appears to be incomplete and requires context.] SK CARD CA the private key for chip authentication and PK CARD CA The public key for chip authentication. The public key PK CARD CA was signed by an issuer of the eID card 10 and the signature is in the elementary file EF CardSecurity saved.

[0037] Furthermore, the card has two static private keys for generating a blocking feature and a restricted ID (pseudonym) using restricted identification. SK CARD RI _ REVOCATION the private key for Restricted Identification in the context of Revocation Checking and SK CARD RI _ ID the private key for Restricted Identification in the context of Restricted ID.

[0038] Service provider 12 offers an internet-based service that requires user identity verification. The service provider possesses an authorization certificate issued by an eID card issuer, which defines the personal data generally readable by the service provider, as well as a private key whose public key is linked to the authorization certificate. Furthermore, service provider 12 possesses a public key for generating pseudonyms using Restricted Identification (Sector Public Key), which is cryptographically linked to the authorization certificate. Fig. 2(a) designated SK SP TA the private key of service provider 12 for terminal authentication, C SP TA the certificate for terminal authentication and PK SP RI ,the public key for a Restricted Identification.

[0039] Identification provider 14 offers the service of reading eID cards, such as card 10. Identification provider 14 possesses an authorization certificate issued by the eID card issuer, which prevents the reading of personal data, as well as a private key whose public key is linked to the authorization certificate. Identification provider 14 also has all the information required to verify the validity of an eID card 10, in particular a list of CSCA certificates and a list of revoked certificates. Furthermore, identification provider 14 manages, in particular renewing, authorization certificates and sector public keys for service providers 12, with the participation of the service providers. Fig. 2(a) designated SK IDP TA the private key of the identification provider 14 for terminal authentication, C IDP TA the certificate for terminal authentication and SK IDP ESIG the private key for communication with the service provider 12.

[0040] The symbol REQUESTED_DGS represents the list of data groups that must be read for a specific identification process. This list is necessarily a subset of the generally readable data groups defined in the service provider's authorization certificate. It is defined by the service provider (12) and communicated to the identification provider (14). Within this description, the data groups in this list are also sometimes referred to as "required identification data."

[0041] With reference to Fig. 2(b) In step 22, a secure channel is first established with the PIN entry device. The procedure essentially follows section 3.2 of the BSI Technical Guideline TR-03110, Part 2, for establishing a PACE channel, from which more detailed information can be found. In short, in step 22, the holder of the eID card 10 initiates an identification process with the service provider 12. The service provider 12 first transmits its authorization certificate, the authorization certificate of its commissioned identification provider 14, as well as a list of the personal data to be read and other metadata required for identification (Certificate Description and AAD). The data from the authorization certificate, in particular the identity of the service provider 12, is displayed to the user via the local client software. If the user agrees to the identification, a connection is established between the eID card 10 and the user's terminal device.A PACE channel is established via a card reader. The user then enters their PIN.

[0042] With reference to Fig. 2(c) In step 24, terminal authentication with identification provider 14 takes place. The user's client software signals the successful establishment of a PACE channel by transmitting the elementary file. CardAccess and a PACE identifier for card 10 to service provider 12. From now on, the client software forwards messages from or to card 10 and performs conversions if necessary, should incompatible message formats be used.

[0043] Service provider 12 notifies its identification provider 14 of a new identification and forwards the received content from CardAccess further. Until further notice, the service provider 12 forwards messages between the identification provider 14 and the local client software of the user of card 10 in both directions, so that a logical channel is created between the identification provider 14 and card 10, see reference 15 in Fig. 1 .

[0044] Identification provider 14 then sends its authorization certificate and a calculated Azure Active Directory (AAD) object to card 10. This object contains, in addition to standard AAD fields, a hash of the authorization certificate of service provider 12. Because this communication is not encrypted, the client software can intercept and read the transmitted data. The client software ensures that the transmitted certificate matches the authorization certificate previously transmitted for identification provider 14. Furthermore, the client software verifies that the hash in the AAD object matches the hash of the authorization certificate previously transmitted for service provider 12, the contents of which were displayed to the user.

[0045] Subsequently, the identification provider 14 executes the classic terminal authentication protocol. In doing so, the identification provider 14 creates an ephemeral key for chip authentication and transmits a reference to the public key to card 10, requests a challenge from card 10, creates a signature using its private key on the challenge, the ephemeral public key, and the previously transmitted AAD object, and transmits the signature to card 10.

[0046] Card 10 verifies the certificate using the trust anchors of its issuer and the received signature using the certificate of the identification provider 14. If all verifications are successful, the card stores the received reference to the public key of the identification provider 14 and the data from the AAD object.

[0047] With reference to Fig. 2(d) If terminal authentication is successful in step 26, chip authentication is then performed using identification provider 14. Identification provider 14 reads the elementary file for this purpose. CardSecurity, performs passive authentication to verify the authenticity of card 10 and transmits its full ephemeral public key to card 10.

[0048] Card 10 verifies the match with the previously stored reference for the ephemeral public key of the identification provider 14, performs key agreement, derives keys for secure messaging, and calculates an authentication token using a randomly generated nonce, which the card transmits to the identification provider 14 along with the nonce. The identification provider 14 also performs key agreement, derives keys for secure messaging, and calculates an authentication token using the transmitted nonce. If the calculated authentication token matches the transmitted token, chip authentication is successful. The logical channel is then used with the derived key material. K ENC SM and K AUTH SM (also referred to in this description as "first key material") is cryptographically protected using Secure Messaging. Card 10 and the identification provider 14 initiate Secure Messaging with this key material in substeps 26-K and 26-IDP, respectively.

[0049] With reference to Fig. 2(e) In step 28, the validity of card 10 is checked via the encrypted and authenticated channel. For this purpose, the identification provider 14 sends a request to card 10. Card 10 responds positively if the date previously transmitted to the card in the AAD object is between its issue date (notBefore) and its expiry date (notAfter), and negatively otherwise.

[0050] With reference to Fig. 2(f) In step 30, terminal authentication takes place with service provider 12. For this purpose, identification provider 14 transmits the authorization certificate of service provider 12 to card 10. Card 10 verifies the certificate using the trust anchors of its issuer, calculates a hash of the certificate, and ensures that the calculated hash matches the previously stored hash. If all verifications are successful, card 10 creates a challenge and sends it to identification provider 14.

[0051] Now, service provider 12 becomes active. Identification provider 14 forwards the challenge from card 10 and the AAD object previously transmitted to card 10 via a secure channel. Service provider 12 creates an ephemeral key pair and, using its private key, a signature on the challenge, the ephemeral public key, and the received AAD object. Service provider 12 sends the created signature and the ephemeral public key to identification provider 14, which forwards the signature and a reference to service provider 12's ephemeral public key via the logical channel with card 10. Card 10 verifies the signature using service provider 12's authorization certificate.

[0052] If the signature was successfully verified, reference will be made to Fig. 2(g) In step 32, chip authentication is performed with service provider 12. For this purpose, identification provider 14 sends the complete ephemeral public key of service provider 12 to card 10. Card 10 performs key agreement, derives keys for the encryption and authentication of data groups, and calculates an authentication token using a randomly generated nonce, which card 10 transmits to identification provider 14 along with the nonce.

[0053] The identification provider 14 forwards the authentication token, the nonce, and the static public key to the service provider 12. The latter also performs key agreement, derives keys for the encryption and authentication of data groups, and calculates an authentication token using the transmitted nonce. If the calculated authentication token matches the transmitted token, chip authentication is successful.

[0054] In substeps 32-K and 32-SP respectively, card 10 and service provider 12 initialize the encryption / decryption and authentication of data groups using the derived keys. K ENC DGE and K AUTH DGE (also referred to as "second key material" in this description) and use it from initialization onwards.

[0055] Both the service provider 12 and the card 10 generate a context variable. cxt and temporarily store their state. For context, both add the authorization certificate of service provider 12, the static public key of card 10, and the ephemeral public key of service provider 12.

[0056] At the end of step 32, the service provider 12 informs the identification provider 14 which personal data should be read from the card 10.

[0057] With reference to Fig. 2(h) In step 34, the revocation status of card 10 is checked. To verify the status of card 10 using a blocklist, Restricted Identification (RI) is employed. For this purpose, the identification provider 14 sends the public key for RI (so-called sector public key) of service provider 12 to card 10. Card 10 calculates a hash of the key and verifies that the certificate of service provider 12, checked in the previous step, contains this hash. Card 10 then performs a key agreement using its static private key for RI for revocation and the received public key, and hashes the resulting shared secret. The hash is sent back to the identification provider 14. The identification provider 14 checks whether this blocking characteristic is on a blocklist specifically prepared for service provider 12 and aborts the identification process if so.

[0058] Referring to Fig. 2(j), the data groups are read in step 36. For this purpose, the identification provider 14 requests all personal data to be read from card 10, which is stored in the form of data groups. For each data group, card 10 prepares its content, encrypts it using the key for data group encryption derived in the penultimate step, and calculates a MAC (Machine Authentication Key) for the ciphertext using the key for data group authentication derived in the previous step. Card 10 also adds the data group content to the context. Finally, card 10 sends the ciphertext and the calculated MAC to the identification provider 14, as usual via the logical communication channel protected by Secure Messaging.

[0059] Optionally, identification provider 14 can initiate the generation of a Restricted ID. To do this, identification provider 14 sends the public key for RI (Sector Public Key) of service provider 12 to card 10. Card 10 calculates a hash of the key and verifies that the certificate of service provider 12, checked in the penultimate step, contains this hash. Card 10 then performs a key agreement using its static private key for RI to generate Restricted IDs and the received public key, and hashes the resulting shared secret. Similar to the procedure for data groups, the hash is encrypted, the ciphertext is authenticated, the hash is added to the context, and sent to identification provider 14 via the secure messaging channel.

[0060] Finally, with reference to Fig. 2(k) In step 38, the result is transmitted to service provider 12, and a cross-check is performed. Once identification provider 14 has received the encrypted and authenticated content of all relevant data groups, it forwards them to service provider 12, who then digitally signs this message. With this signature, identification provider 14 certifies to service provider 12 that the personal data contained in the message originates from a card 10 whose authenticity and validity it has verified.

[0061] Service provider 12 first verifies the signature of the received message. Then, for each data group, service provider 12 performs the following sub-steps: It calculates a MAC using the previously derived key for data group authentication and compares it with the MAC for the message's data group; it decrypts the ciphertext for the message's data group using the data group encryption key derived in the previous step; and it adds the decrypted data group content to the context.

[0062] Card 10 proceeds similarly if a Restricted ID has been generated.

[0063] At the end of step 38, the service provider 12 terminates the forwarding of messages between the card 10 and the identification provider 14 and sends the card 10 a command to authenticate the exchange.

[0064] Since this command is not sent over the encrypted Secure Messaging channel, the card terminates the Secure Messaging channel. Furthermore, card 10 calculates a MAC address based on the cached context using the previously derived key for data group authentication and sends it back to service provider 12. The service provider also calculates a MAC address based on the cached context using the previously derived key for data group authentication and compares it to the received MAC address. If a match is found, the identification process is successfully completed. Bezugszeichenliste

[0065] 10 eID card 11 Connection card - service provider 12 Service provider 13 Connection service provider - identification provider 14 Identification provider 15 Logical communication channel 20 Initial state 22, 24, 26 Process steps 26-K, 26-IDP Substeps 28, 30, 32 Process steps 32-K, 32-SP Substeps 34, 36, 38 Process steps

Claims

1. Method for the secure identification of a person using an identification card (10) by a verification instance (14) to a service provider (12), in which - a secure, one-way authenticated communication link is established between the identification card (10) and the service provider (12), and a secure, two-way authenticated communication link is established between the service provider (12) and the verification instance (14), - the communication between the identification card (10) and the verification instance (14) is carried out exclusively via the service provider (12) as a proxy, which intercepts all messages exchanged between the identification card (10) and the verification instance (14) and forwards them with its own identifier so that a logical communication channel is created between the identification card (10) and the verification instance (14), characterized in that - a first, authenticated key agreement for encrypted communication between the verification instance (14) and the identification card (10) is implemented via the logical communication channel, - the validity of the identification card (10) is verified by the verification instance (14), encrypted using the first key material via the logical communication channel, - a second, authenticated key agreement is implemented between the service provider (12) and the identification card (10) for the encryption and authentication of required identification data and / or the results of card operations, - the required identification data is encrypted with the second key material by the identification card (10) and transmitted encrypted with the first key material via the logical communication channel to the verification instance (14), - the verification instance (14) transmits the identification data encrypted with the second key material to the service provider (12) and confirms to it that the identification data contained in the transmission originates from an identification card (10) successfully validated by the verification instance (14), and - the service provider (12) decrypts the identification data transmitted by the verification instance (14) using the second key material.

2. Method according to Claim 1, characterized in that the method uses Extended Access Control (EAC) protocols, in particular Chip Authentication, Terminal Authentication and / or PACE (Password Authenticated Connection Establishment).

3. Method according to Claim 2, characterized in that to implement the first key agreement, a terminal authentication is carried out with the verification instance (14) and, if terminal authentication is successful, a chip authentication is carried out with the verification instance (14).

4. Method according to Claim 2 or 3, characterized in that to implement the second key agreement, a terminal authentication is carried out with the service provider (12) and, if terminal authentication is successful, a chip authentication is carried out with the service provider (12).

5. Method according to at least one of Claims 1 to 4, characterized in that the service provider (12) and the identification card (10) each temporarily store documentary data for the identification that has taken place, that the identification card (10) transmits its documentary data to the service provider (12) and that the service provider (12) checks the conformity of the documentary data transmitted by the identification card (10) with the documentary data available to it in order to authenticate the exchange.

6. Method according to Claim 5, characterized in that the documentary data contains an authorization certificate of the service provider (12), a static public key of the identification card (10), an ephemeral public key of the service provider (12) and / or the contents of the transmitted identification data.

7. Method according to at least one of Claims 1 to 6, characterized in that the verification instance (14) uses Restricted Identification to check the status of the identification card (10).

8. Method according to at least one of Claims 1 to 7, characterized in that the identification card (10) is an eID card.

9. Method according to at least one of Claims 1 to 8, characterized in that the identification card (10) is integrated into a terminal device, or that the identification card (10) is designed as a stand-alone system which is connected to a terminal device via a reading device, and that in both cases, a local client software of the terminal device advantageously guides the person through the identification process and performs the communication with the identification card (10) .

10. Method according to at least one of Claims 1 to 9, characterized in that the service provider (12) has an authorization certificate issued by an issuer of the identification card (10), which specifies the identification data that can be read out by the service provider (12), and that the service provider (12) transmits said authorization certificate to the identification card (10) at the beginning of the method in order to obtain the consent of the person for identification.

11. Method according to at least one of Claims 1 to 10, characterized in that the verification instance (14) has an authorization certificate issued by an issuer of the identification card (10), which prevents the reading of personal data, and that said authorization certificate is transmitted to the identification card (10) at the beginning of the method in order to obtain the consent of the person for identification with the involvement of the verification instance (14).