Eisen Identificatie op Afstand niet van toepassing

NOTE 1: A physical or digital identity document as defined in the present document will usually represent a natural person only. Identity documents that evidence that a natural person represents a legal person can be envisaged but cannot be assumed to be generally available.

EXAMPLE 1: Information on the applicable data protection rules, notably GDPR if the identity proofing process is carried out under the legislation of an EU Member State.

EXAMPLE 2: The identity proofing process can require the use of a specific type of device (e.g. a smartphone) with the installation of specific software (e.g. an app).

Eis is onderdeel van het Normenkader Betrouwbaarheidsniveaus, paragraaf 2.2.2.

8.2 Attribute and evidence collection
8.2.1 General requirements

NOTE 4: Identification of use cases can be by reference to clause 9 of the present document.

NOTE 5: While the list of evidence that can be trusted is required to be comprehensive, a specific identity proofing context can place restrictions on the selection of evidence applicable to the identity proofing context.

EXAMPLE: A passport can have a lifetime of 10 years, and an eID or signing certificate can have a lifetime of 2-5 years, meaning the identity attributes obtained from this evidence can have changed since the
evidence was issued. Some evidence issuers can apply revocation and re-issuing if information
changes.

NOTE 6: If the information conveyed from an evidence does not fulfil the information freshness requirements of the identity proofing context, the situation can be compensated by the use of supplementary evidence.

NOTE 1: There can be cases where the name attributes collected need to match the name provided by an evidence, which is not necessarily the current name when a name change occurred after the evidence was issued.

NOTE 2: Requirements for the presence of naming attributes can depend on the identity proofing context. In some contexts, a full name (all family names and first names) can be required, while in other contexts full name is not needed. In rare cases, a person can have only one name, classified as either first name or family name.

NOTE 3: Depending on the identity proofing context, unique identification can be in the form of a single attribute such as a national identity number, or as one or more additional attributes that together with the name provide unique identification.

NOTE 4: ETSI EN 319 412-2 [i.9] specifies X.509 certificate profile for natural persons. In addition to the name of the subject, a country attribute with undefined semantics is mandatory, and usually a serialNumber attribute is required to guarantee a unique identity. While values for the country and the serialNumber attributes can be part of the attributes collected, these values can also be generated and added by the certification authority.

NOTE 5: Although the outcome of the identity proofing can be a pseudonym identity, identity proofing conforming to the present document requires identification of the real identity of the person as determined by applicable identity documents, official registers or other authoritative sources.

NOTE: Depending on the identity proofing context, attribute collection for a legal person may vary from basic company information to an extensive record of information about the legal person, including information such as beneficial owners and personnel in key roles.

EXAMPLE 1: Attributes can be collected from business registers, commercial information providers, documents and attestations, or by manual input in the course of the identity proofing process.

NOTE 1: Most eID solutions today represent a natural person, although eID means for a legal person or a natural person representing a legal person is possible.

EXAMPLE 1: The documentation can list named eIDs or eID schemes or describe the necessary characteristics of eIDs or eID schemes by referring to a required LoA as defined by an assurance level
framework.

EXAMPLE 2: Acceptance for an identity proofing context can require that certain identity attributes are asserted by the eID means.

EXAMPLE 3: The identity proofing context can state that only eIDs notified according to the eIDAS
Regulation [i.1] Article 9 can be used.

NOTE 2: eIDAS LoAs are specified by CIR (EU) 2015/1502 [i.3]. The identity proofing context can require
conformance to specifically the eIDAS LoA framework and can also require that eIDs are notified
according to the eIDAS Regulation [i.1] Article 9.

EXAMPLE 4: The eID can conform to a national assurance level framework of an EU Member State or an
assurance level framework of a non-EU state; in both cases, the assurance level framework can be aligned with the eIDAS LoAs.

NOTE 3: The comparable assurance to an eIDAS LoA level can be assessed by an independent, accredited
conformity assessment body.

NOTE 4: The identity proofing context can place further requirements on the issuing of the eID, e.g. to avoid a long chain of eID renewals where the presence (physical or remote) of the eID subject is a long time in the past, or to avoid a long chain of eIDs that are all issued based on another eID.

NOTE 1: A digital signature can be applied by a natural person (electronic signature as defined by eIDAS), a legal person (electronic seal as defined by eIDAS), or a natural person representing a legal person, depending on the information included in the certificate and the semantics of this information.

NOTE 2: The conditions can be stated in the form of a signature policy; see ETSI TS 119 172-1 [i.13].

NOTE 3: The present document makes no assumption on the format or content of the document signed. Identity attributes are evidenced by the certificate, not by the signed document.

EXAMPLE 1: Regarding digital signature, the identity proofing context can require that a qualified electronic signature/seal, according to the eIDAS regulation, is used.

EXAMPLE 2: Regarding certificate, the list can consist of named certificate issuers or describe the necessary characteristics of the certificate, e.g. by referring to a policy level as defined by ETSI EN 319 411-1 [i.7] or ETSI EN 319 411-2 [i.8].

EXAMPLE 3: Acceptance for an identity proofing context can pose requirements for certificate content, e.g. require that certain identity attributes are present for the named subject.

NOTE 1: Availability of trusted registers can vary between countries, ranging from no availability to lookup in particular sources, e.g. national population registers or business registers, mandated by national regulation.

EXAMPLE 1: Trusted registers can be used both to validate attributes that are already collected to ensure that the attribute values are correct and up to date, and to fetch additional attributes.

NOTE: Proof of access will usually be relevant only for natural persons.

EXAMPLE 1: Proof of access to a bank account with identity information obtained from the bank.

EXAMPLE 2: Proof of access to a mobile phone with identity information obtained from the mobile operator's subscription register.

EXAMPLE 1: For a natural person, in some countries, utility bills or similar can be required as evidence of
address.

EXAMPLE 2: Attestations can be used as evidence that a legal person exists and for further information on its legal status, and as evidence that a natural person is entitled to represent the legal person.

NOTE 2: This, in particular, applies to legal persons that are not present in such business registers.

EXAMPLE 3: Information source can be public notaries, other registers than business registers, the official web site of the legal person, contacts with representatives of the legal person other than the concerned
natural person etc.

NOTE 1: Successful authentication implies that the eID means as evidence is validated, that the identity
information conveyed from the eID means is validated, and that the identity information is bound to the
applicant.

NOTE 2: The eID means can represent a natural person, a legal person, or a natural person representing a legal person.

NOTE 1: This is to avoid threats from the use of documents previously signed by the applicant.

NOTE 2: Usually, this means that the validation result is TOTAL-PASSED as defined by ETSI EN 319 102-1 [i.5].

NOTE 3: If the digital signature is valid, the information obtained from the certificate supporting the digital signature can be considered valid and bound to the applicant.

NOTE 4: The certificate can represent a natural person, a legal person, or a natural person representing a legal person.

EXAMPLE 3: By use of eID means fulfilling requirements for PSD2 (EU Payment Services Directive) SCA
(Strong Customer Authentication) [i.2].

EXAMPLE 4: A payment made by the applicant to an account associated with the identity proofing process can be part of the proof of access protocol.

NOTE 1: For a digital document, this can imply validating a digital signature on the document or attestation. The identity proofing context can pose requirements that a digital signature is required to fulfil to be accepted.

NOTE 2: For a physical document, this can be by physical signatures or seals, logos and other visual elements, and by examining the document to detect falsification and tampering.

APCER = attack presentation classification error rate
proportion of attack presentations using the same PAI species incorrectly classified as bona fide presentations in a specific scenario

Bron: ISO30107-3: Information technology — Biometric presentation attack detection — Part 3: Testing and reporting, paragraaf 3.2.1

BPCER = bona fide presentation classification error rate
proportion of bona fide presentations incorrectly classified as presentation attacks in a specific scenario

Bron: ISO30107-3: Information technology — Biometric presentation attack detection — Part 3: Testing and reporting, paragraaf 3.2.2

Dit is een kwaliteitsnorm voor gebruikersvriendelijkheid. De toetreder dient via een risicoanalyse aan te tonen dat hierop zicht wordt gehouden.

NOTE 3: No specific number is specified for FAR. Rapid technology improvement can lead to significant progress in industry best practice FAR performance even in the short term.

NOTE 4: An example of industry best practice reference can be the one-to-one face matching results reported from the NIST Face Recognition Vendor Test.

ETSI 119 461 definities:

False Acceptance Rate (FAR)
proportion of verification transactions with false biometric claims erroneously accepted

NOTE: Source ISO/IEC 19795-1 [i.17].

ETSI 119 461 definities:

False Rejection Rate (FRR)
proportion of verification transactions with true biometric claims erroneously rejected

NOTE: Source ISO/IEC 19795-1 [i.17].

De Toetreder dient via een risicoanalyse aan te tonen dat hierop zicht wordt gehouden.

8.4.5 Binding to applicant for legal person and natural person representing legal person