NL-P-04P Part 1 requirements

This page lists every requirement of NL-P-04P Part 1 (PID Issuance & Lifecycle Management Requirements, Part 1, version RC1.0) as published on 6 November 2026. The PDF is authoritative: each requirement links to the page it is on. You can also read the full text or search all requirements.

126 entries: 126 requirements. Obligation: 112 mandatory, 14 conditional.

Legal basis of the document: eIDAS, CIR 2015/1502, CIR 2024/2977, CIR 2024/2981.

Referenced in the document but not defined in it: ISS-4.3-11, ISS-4.3-13, ISS-4.7-05, ISS-4.7-13, ISS-4.4-01, REP-5.1-05, REP-5.1-08, REP-5.1-11, REP-5.1-03, REP-5.1-10, ISS-4.6-02, ISS-4.2-04, ISS-4.5-05, ISS-4.7-01, ISS-4.7-04, REP-5.4-02, REP-5.1-02, ISS-4.1-02, ISS-4.1-03, REN-6.1-05, ISS-4.5-01, REP-5.2-14, ISS-4.5-02, ISS-4.5-03, ISS-4.5-04, ISS-4.2-05, ISS-4.5-06, ISS-4.5-07, ISS-4.5-08, ISS-4.6-01, ISS-4.6-04, ISS-4.6-05, REN-6.1-01, ISS-4.1-01, REP-5.1-01, REN-6.1-02, REN-6.5-04, ISS-4.7-03, REN-6.2-01, ISS-4.3-12, REN-6.4-01, REN-6.4-04, REN-6.4-05, REN-6.4-06, REN-6.4-07, REN-6.4-09, REN-6.4-10, REN-6.5-01, REN-6.5-02, REN-6.5-03, REN-6.3-01, ISS-4.4-03, REN-6.3-02, REN-6.5-07, REN-6.1-04, REN-6.5-06, REN-6.3-03, REP-5.1-07, REP-5.1-09, REN-6.1-03, ISS-4.7-11, ISS-4.7-12, ISS-4.7-14, ISS-4.7-10, ISS-4.7-15, REN-6.4-02, REP-5.4-03, REP-5.1-06, REN-6.1-06, ISS-4.3-14.

5.1 Pre-Issuance Requirements and Eligibility

Read section 5.1 in the full text

ISS-5.1-01

The PID Provider shall not issue a PID to a Wallet Unit that already holds an active Logical PID issued by that PID Provider.

Requirement · obligation: mandatory · PDF page 15

ISS-5.1-02

The PID Provider shall cancel a PID that has been generated but not issued within the maximum retention period defined in its documented issuance procedures, together with the personal data associated with that PID.

Requirement · obligation: mandatory · PDF page 15

ISS-5.1-03

[CONDITIONAL] Where a PID is generated in advance of issuance, the PID Provider shall re-verify, immediately before issuance, that no ground preventing issuance has arisen since the PID was generated, including loss of eligibility, a change in the attributes held by the authoritative population register, decease, a fraud signal, or the identity document having been reported lost or stolen.

Requirement · obligation: conditional · PDF page 16

ISS-5.1-04

The PID Provider shall not issue a PID to a Wallet Unit of a Wallet Provider while an active Logical PID issued by that PID Provider in the name of the same person is held in another Wallet Unit of that same Wallet Provider, unless the Technical PIDs of that Logical PID have been revoked in accordance with ISS-5.1-05.

Requirement · obligation: mandatory · PDF page 16

How a CAB verifies this: A CAB verifies this requirement by reviewing the documented issuance flow and the PID Provider's administration, for instance by inspecting the rule that compares the Wallet Provider of the requesting Wallet Unit with the Wallet Providers recorded for the person's active Logical PIDs, and by examining past issuance records for the absence of two active Logical PIDs of one person at one Wallet Provider.

Referenced by: ISS-5.1-05

ISS-5.1-05

The PID Provider shall revoke the Technical PIDs referred to in ISS-5.1-04 only after all other conditions for issuing the further PID have been met, including the confirmation required by ISS-5.4-04 where that requirement applies.

Requirement · obligation: mandatory · PDF page 17

How a CAB verifies this: A CAB verifies this requirement by reviewing the issuance flow and its state handling, for instance by examining the point at which revocation of the older Logical PID is triggered and by inspecting records of abandoned issuance attempts that show the older Logical PID remained active.

Referenced by: ISS-5.1-04

5.2 Wallet Unit Verification

Read section 5.2 in the full text

ISS-5.2-01

The PID Provider shall verify, before issuing a PID, that the Wallet Unit presents a Wallet Instance Attestation that is valid, has not expired, and has not been revoked.

Requirement · obligation: mandatory · PDF page 17

ISS-5.2-02

The PID Provider shall verify, before issuing a PID, that the issuer of the Wallet Instance Attestation is present in the applicable trusted list.

Requirement · obligation: mandatory · PDF page 17

ISS-5.2-03

The PID Provider shall not issue a PID unless the Wallet Unit has provided the Wallet Trust Evidence required to establish that its cryptographic device satisfies the conditions for Assurance Level High.

Requirement · obligation: mandatory · PDF page 18

ISS-5.2-04

The PID Provider shall not bind a PID to a public key unless it has verified proof of possession of the corresponding private key as specified in CRED-REQ-PROC-4.6.2.1-0 of [5].

Requirement · obligation: mandatory · PDF page 18

ISS-5.2-05

The PID Provider shall verify, using the key provenance attestation provided during issuance, that the PID binding key pair is generated and held in a cryptographic device certified at a level appropriate for Assurance Level High.

Requirement · obligation: mandatory · PDF page 18

ISS-5.2-06

The PID Provider shall not rely on trusted-list data whose current validity cannot be confirmed when validating the Wallet Unit.

Requirement · obligation: mandatory · PDF page 19

5.3.1 General Requirements

Read section 5.3.1 in the full text

ISS-5.3-01

The PID Provider shall verify that the unique identifier established for the subject during identity proofing corresponds to the identity that was authenticated in the same identity-proofing session.

Requirement · obligation: mandatory · PDF page 19

ISS-5.3-02

The PID Provider shall not introduce, into the PID or into the data it generates during issuance, any identifier or reused value - other than the PID attributes themselves - that would enable a third party to correlate separate Technical PIDs or issuance events independently of the attributes disclosed under the User's control from PID representations.

Requirement · obligation: mandatory · PDF page 19

5.3.2 Identity Proofing Using a Digital Identity Document

Read section 5.3.2 in the full text

ISS-5.3-03

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall verify, during identity proofing, that the presented identity document chip is genuine and has not been cloned, using the chip's active authentication mechanism or an equivalent anti-cloning mechanism.

Requirement · obligation: conditional · PDF page 20

ISS-5.3-04

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall accept the identity document only if validation of the issuer signature on the chip data against the country signing public key infrastructure returns a complete, fully-passed result.

Requirement · obligation: conditional · PDF page 20

ISS-5.3-05

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall establish that the identity document chip is read live during the identity-proofing session.

Requirement · obligation: conditional · PDF page 20

ISS-5.3-06

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall not accept a previously captured or stored chip readout in place of a live read of the identity document.

Requirement · obligation: conditional · PDF page 21

ISS-5.3-07

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document and a status service for that identity document is available, the PID Provider shall check the status of the presented identity document before completing identity proofing.

Requirement · obligation: conditional · PDF page 21

ISS-5.3-08

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall not complete identity proofing where the status check, or any other information available to it, indicates that the identity document is reported lost, stolen, or revoked.

Requirement · obligation: conditional · PDF page 21

ISS-5.3-09

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall complete identity proofing only after the chip of the identity document has confirmed successful verification of the document PIN.

Requirement · obligation: conditional · PDF page 21

ISS-5.3-10

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall protect the exchange in which the identity document is electronically authenticated against interception and modification by a party interposed between the identity document and the PID Provider.

Requirement · obligation: conditional · PDF page 22

ISS-5.3-11

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall record the number of failed PACE or PINverification attempts that occurred, within the same identity-proofing session, before a successful attempt.

Requirement · obligation: conditional · PDF page 22

ISS-5.3-12

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall flag, for investigation, an identity-proofing session in which the number of failed PACE or PIN-verification attempts before a successful attempt exceeds a defined threshold.

Requirement · obligation: conditional · PDF page 22

ISS-5.3-13

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall record the identity document's chip identifier together with the national identification number established during each identity-proofing session.

Requirement · obligation: conditional · PDF page 23

ISS-5.3-14

[CONDITIONAL] If the PID Provider performs the identity proofing based on a digital identity document, the PID Provider shall flag, for investigation, an identity document chip identifier that has been recorded together with more than one distinct national identification number.

Requirement · obligation: conditional · PDF page 23

5.4 PID Issuance Request and Authorisation

Read section 5.4 in the full text

ISS-5.4-01

The PID Provider shall reject an issuance request that does not contain a valid, unused freshness value bound to the authenticated wallet session.

Requirement · obligation: mandatory · PDF page 24

ISS-5.4-02

The PID Provider shall not authorise issuance unless every required precondition has been successfully completed, comprising Wallet Unit trust verification, user identity verification, and the eligibility check.

Requirement · obligation: mandatory · PDF page 24

ISS-5.4-03

The PID Provider shall log an issuance request rejected for failing a freshness or replay check, together with the reason for rejection.

Requirement · obligation: mandatory · PDF page 24

ISS-5.4-04

[CONDITIONAL] Where one or more contact methods are registered for a person, the PID Provider shall not authorise the issuance of a PID in that person's name to a Wallet Unit that does not yet hold a Logical PID of that person unless the person has entered in the issuance flow the one-time code that the PID Provider has sent through a registered contact method.

Requirement · obligation: conditional · PDF page 24

How a CAB verifies this: A CAB verifies this requirement by reviewing the issuance flow and the authorisation logic, for instance by examining that issuance to a new Wallet Unit is not authorised without a matching code from a registered contact method, and by inspecting records of past issuances for the presence of the code confirmation.

Referenced by: ISS-5.1-05, ISS-5.4-05, ISS-5.4-06

ISS-5.4-05

The PID Provider shall ensure that every message that carries a one-time code under ISS-5.4-04 names the Wallet Provider of the Wallet Unit concerned, states that a new Wallet Unit is being set up in the person's name, warns the person never to share the code with anyone, and contains no link, QR code, or telephone number to call.

Requirement · obligation: mandatory · PDF page 25

How a CAB verifies this: A CAB verifies this requirement by reviewing the templates of the messages and the configuration that fills them, for instance by inspecting a sample of messages sent in the past, and by confirming that each contains the three required statements and no link, QR code or telephone number.

ISS-5.4-06

The PID Provider shall invalidate a one-time code issued under ISS-5.4-04 or ISS-5.7-21 after its first successful use, after the end of a defined validity period, and after a defined number of failed entry attempts.

Requirement · obligation: mandatory · PDF page 25

How a CAB verifies this: A CAB verifies this requirement by reviewing the design and configuration of the code service, for instance by inspecting the validity period and attempt limit that are set, and by examining records of issued codes that show invalidation after use, expiry or failed attempts.

5.5 PID Generation and Signing

Read section 5.5 in the full text

ISS-5.5-01

The PID Provider shall not generate a PID unless a complete and current set of the required attributes has been obtained from the authoritative population register.

Requirement · obligation: mandatory · PDF page 26

ISS-5.5-02

The PID Provider shall populate each mandatory PID attribute in accordance with the applicable national value convention, including the defined fall-back values where an attribute value is not available.

Requirement · obligation: mandatory · PDF page 26

ISS-5.5-03 — The PID Provider shall not fetch, process, or store any optional attribute that has been excluded at national level.

The PID Provider shall not fetch, process, or store any optional attribute that has been excluded at national level.

Requirement · obligation: mandatory · PDF page 26

ISS-5.5-04 — The PID Provider shall bind the PID to the dedicated PID binding public key provided for that PID and to no other key.

The PID Provider shall bind the PID to the dedicated PID binding public key provided for that PID and to no other key.

Requirement · obligation: mandatory · PDF page 26

ISS-5.5-05

The PID Provider shall sign the PID using a signing key whose certificate chains to a trust anchor published in the applicable trusted list.

Requirement · obligation: mandatory · PDF page 27

ISS-5.5-06 — The PID Provider shall use the PID signing key only within the authorised issuance process.

The PID Provider shall use the PID signing key only within the authorised issuance process.

Requirement · obligation: mandatory · PDF page 27

ISS-5.5-07

The PID Provider shall set the validity period of the PID so that it does not exceed the maximum PID lifetime defined by national policy.

Requirement · obligation: mandatory · PDF page 27

ISS-5.5-08

The PID Provider shall set the validity period of the PID so that it does not extend beyond the validity of the Wallet Unit to which the PID is issued.

Requirement · obligation: mandatory · PDF page 28

5.6 Secure PID Delivery

Read section 5.6 in the full text

ISS-5.6-01

The PID Provider shall not release a PID to the Wallet Unit before authentication of the Wallet Unit and of the holder has completed successfully.

Requirement · obligation: mandatory · PDF page 28

ISS-5.6-02 — The PID Provider shall deliver the PID to the Wallet Unit using the issuance protocol specified in [5].

The PID Provider shall deliver the PID to the Wallet Unit using the issuance protocol specified in [5].

Requirement · obligation: mandatory · PDF page 28

ISS-5.6-03

The PID Provider shall record the outcome of each issuance, including any refusal of the issued PID by the Wallet Unit and any case where the Wallet Unit does not respond.

Requirement · obligation: mandatory · PDF page 28

ISS-5.6-04

The PID Provider shall classify a PID that has left its systems as issued, regardless of whether the Wallet Unit confirms its acceptance.

Requirement · obligation: mandatory · PDF page 29

ISS-5.6-05

The PID Provider shall revoke a PID that it has classified as issued where the Wallet Unit reports that the PID was not accepted.

Requirement · obligation: mandatory · PDF page 29

5.7 Post-Issuance Status Service Registration

Read section 5.7 in the full text

ISS-5.7-01

The PID Provider shall register each issued PID, including its identifier, its validity end date, and its status, in the PID Provider's administration and status service.

Requirement · obligation: mandatory · PDF page 29

ISS-5.7-02 — The PID Provider shall record, for each issued PID, the Wallet Unit to which that PID was issued.

The PID Provider shall record, for each issued PID, the Wallet Unit to which that PID was issued.

Requirement · obligation: mandatory · PDF page 29

ISS-5.7-03

The PID Provider shall record the withdrawal of a PID that has already been delivered to a Wallet Unit as a revocation with a corresponding entry in the status service.

Requirement · obligation: mandatory · PDF page 30

ISS-5.7-04

The PID Provider shall record each issuance event in a tamper-evident log with sufficient detail to support conformity assessment and incident investigation.

Requirement · obligation: mandatory · PDF page 30

ISS-5.7-05

The PID Provider shall notify the person identified in the PID, through a channel independent of the Wallet Unit, when a PID is issued in that person's name.

Requirement · obligation: mandatory · PDF page 30

Referenced by: ISS-5.7-17

ISS-5.7-05A

The PID Provider shall notify the person in whose name a PID was requested, through a channel independent of the Wallet Unit, when a request to issue a PID in that person's name does not result in issuance because identity proofing or another eligibility check failed, inviting that person to raise an alarm if they did not make the request.

Requirement · obligation: mandatory · PDF page 30

ISS-5.7-06

The PID Provider shall notify the identified person, through a channel independent of the Wallet Unit, when more than one Logical PID issued by that PID Provider is active in that person's name.

Requirement · obligation: mandatory · PDF page 31

Referenced by: ISS-5.7-08, ISS-5.7-09, ISS-5.7-17, ISS-5.7-18

ISS-5.7-07

The PID Provider shall offer the person the opportunity to register one or more contact methods that are capable of delivering a notification to the person without delay.

Requirement · obligation: mandatory · PDF page 31

Referenced by: ISS-5.7-20

ISS-5.7-08

The PID Provider shall ensure that the notification referred to in ISS-5.7-06 states explicitly that the activation of a further Wallet Unit that the person did not perform or authorise or that was done on request of someone else, may result in financial loss or identity theft to that person.

Requirement · obligation: mandatory · PDF page 31

ISS-5.7-09

The PID Provider shall include, in the notification referred to in ISS-5.7-06, a means for the person to revoke the newly issued PID through a low-threshold procedure.

Requirement · obligation: mandatory · PDF page 32

Referenced by: ISS-5.7-10

ISS-5.7-10

The PID Provider shall require the use of its standard revocation procedure to revoke any PID, other than the newly issued PID referred to in ISS-5.7-09, that is active in that person's name.

Requirement · obligation: mandatory · PDF page 32

Referenced by: ISS-5.7-18

ISS-5.7-11

The PID Provider shall record, for each national identification number, the number of Wallet Units to which a PID for that national identification number is currently issued and within its Administrative Validity Period, and the timestamps of each issuance and renewal request relating to that national identification number.

Requirement · obligation: mandatory · PDF page 32

ISS-5.7-12

The PID Provider shall flag, for investigation, a national identification number whose active-Logical-PID count or issuance-or-renewal-request rate exceeds a defined threshold.

Requirement · obligation: mandatory · PDF page 33

ISS-5.7-13

The PID Provider shall record, where available to it, the network origin or locality indicator of each issuance or renewal request.

Requirement · obligation: mandatory · PDF page 33

Referenced by: ISS-5.7-25, ISS-5.7-26

ISS-5.7-14

The PID Provider shall flag, for investigation, two issuance or renewal requests relating to the same national identification number whose recorded network origin or locality indicators are inconsistent with the time elapsed between them.

Requirement · obligation: mandatory · PDF page 33

ISS-5.7-15

The PID Provider shall subject each case that this specification requires to be flagged for investigation to a defined investigation and response procedure.

Requirement · obligation: mandatory · PDF page 34

ISS-5.7-16

The PID Provider shall record, for each issued PID, the Wallet Provider that provided the Wallet Unit to which the PID was issued and the date of issuance.

Requirement · obligation: mandatory · PDF page 34

How a CAB verifies this: A CAB verifies this requirement by reviewing the data model of the administration and by examining a sample of PID records for the presence of the Wallet Provider and the issuance date.

Referenced by: ISS-5.7-17

ISS-5.7-17

The PID Provider shall state, in each notification referred to in ISS-5.7-05 and ISS-5.7-06, the Wallet Provider and the date of issuance recorded under ISS-5.7-16 for the Wallet Unit concerned.

Requirement · obligation: mandatory · PDF page 34

How a CAB verifies this: A CAB verifies this requirement by reviewing the notification templates and by examining a sample of sent notifications for the presence of the Wallet Provider and the date.

ISS-5.7-18

The PID Provider shall list, in the notification referred to in ISS-5.7-06, every Wallet Unit in which an active Logical PID is held in the person's name, stating for each the Wallet Provider and the date of issuance, and invite the person to revoke any Wallet Unit that is suspicious or no longer in use through the standard revocation procedure referred to in ISS-5.7-10.

Requirement · obligation: mandatory · PDF page 35

How a CAB verifies this: A CAB verifies this requirement by reviewing the notification templates and the logic that builds the list, and by examining a sample of notifications sent where more than one Logical PID was active.

ISS-5.7-19

The PID Provider shall not disclose to a Wallet Unit, or offer through a Wallet Unit a means to revoke, any other Wallet Unit in which a PID is held in the name of the same person.

Requirement · obligation: mandatory · PDF page 35

How a CAB verifies this: A CAB verifies this requirement by reviewing the interface descriptions of the issuance protocol and by inspecting the responses sent to a Wallet Unit, for instance to confirm that they contain no data about other Wallet Units of the person.

ISS-5.7-20

The PID Provider shall, at the first issuance of a PID in a person's name, collect from the person both a mobile telephone number that is able to receive text messages and an e-mail address, and register them as contact methods under ISS-5.7-07 unless the person explicitly declines.

Requirement · obligation: mandatory · PDF page 35

How a CAB verifies this: A CAB verifies this requirement by reviewing the first-issuance flow and by examining the records of a sample of first issuances for the registered contact methods or the recorded refusal.

ISS-5.7-21

The PID Provider shall register a contact method only after the person has entered a one-time code that the PID Provider has sent to that contact method.

Requirement · obligation: mandatory · PDF page 36

How a CAB verifies this: A CAB verifies this requirement by reviewing the registration flow and by examining records of registered contact methods for the verification event.

Referenced by: ISS-5.4-06

ISS-5.7-22

The PID Provider shall replace a registered contact method only after the person has entered a one-time code that the PID Provider has sent to the contact method that is being replaced, except where ISS-5.7-24 applies.

Requirement · obligation: mandatory · PDF page 36

How a CAB verifies this: A CAB verifies this requirement by reviewing the contact-change flow and by examining records of past changes for the code confirmation.

ISS-5.7-23

The PID Provider shall notify every contact method registered before a change, through that contact method, when a registered contact method has been replaced.

Requirement · obligation: mandatory · PDF page 36

How a CAB verifies this: A CAB verifies this requirement by reviewing the contact-change flow and by examining a sample of changes for the notification to the previous contact methods.

ISS-5.7-24

The PID Provider shall, where the person has no access to a contact method that is to be replaced, replace it only after identity proofing in accordance with clause 4.3, at the same assurance level as required for initial issuance, has been completed for that person.

Requirement · obligation: mandatory · PDF page 37

How a CAB verifies this: A CAB verifies this requirement by reviewing the replacement route and by examining records of such replacements for the identity proofing event.

Referenced by: ISS-5.7-22

ISS-5.7-25

The PID Provider shall flag, for investigation, a network origin indicator recorded under ISS-5.7-13 that is linked to issuance or renewal requests for more than a defined number of distinct national identification numbers within a defined period.

Requirement · obligation: mandatory · PDF page 37

How a CAB verifies this: A CAB verifies this requirement by reviewing the detection rules and their configuration and by examining records of past flags and of the investigations that followed.

ISS-5.7-26

The PID Provider shall limit the retention of the network origin indicators recorded under ISS-5.7-13 to a period determined as part of its risk assessment.

Requirement · obligation: mandatory · PDF page 37

How a CAB verifies this: A CAB verifies this requirement by reviewing the risk assessment and the retention configuration, and by examining that records older than the retention period are absent.

ISS-5.7-27

The PID Provider shall use the network origin indicators recorded under ISS5.7-13 for no purpose other than the detection of fraud.

Requirement · obligation: mandatory · PDF page 38

How a CAB verifies this: A CAB verifies this requirement by reviewing the access rules and the documented purposes of the records, and by examining access logs.

6.1 Replenishment Triggers and Threshold

Read section 6.1 in the full text

REP-6.1-01 — ISS-4.4-01 applies in this context as well.

ISS-4.4-01 applies in this context as well.

Requirement · obligation: mandatory · PDF page 39

REP-6.1-02

The PID Provider shall not replenish Technical PIDs to a Wallet Unit for which the Administrative Validity Period has ended.

Requirement · obligation: mandatory · PDF page 39

REP-6.1-03

The PID Provider shall verify, before issuing replenished Technical PIDs, that the attribute values of the Logical PID remain current.

Requirement · obligation: mandatory · PDF page 39

REP-6.1-04

The PID Provider shall revoke the outstanding Technical PIDs of a Logical PID when a revocation condition for that Logical PID is established.

Requirement · obligation: mandatory · PDF page 40

REP-6.1-05

The PID Provider shall not continue automatic replenishment to a Wallet Unit for which it has received an indication that the Wallet Unit or its device is no longer under the legitimate user's control.

Requirement · obligation: mandatory · PDF page 40

REP-6.1-06

The PID Provider shall not treat an indication that a Wallet Unit or its device is no longer under the legitimate user's control as qualifying under REP-5.1-05 unless the reliability of that indication has been established through a defined verification procedure.

Requirement · obligation: mandatory · PDF page 40

REP-6.1-07

The PID Provider shall record the timestamp and the Technical-PID count of each batch replenishment performed for a Wallet Unit.

Requirement · obligation: mandatory · PDF page 41

REP-6.1-08

The PID Provider shall determine, as part of its risk assessment, a maximum batch size and a maximum number of outstanding Technical PIDs per Wallet Unit.

Requirement · obligation: mandatory · PDF page 41

REP-6.1-09

The PID Provider shall not exceed the maximum batch size or the maximum number of outstanding Technical PIDs per Wallet Unit, determined under REP-5.1-08, when replenishing a Wallet Unit.

Requirement · obligation: mandatory · PDF page 41

REP-6.1-10

The PID Provider shall, when it establishes that the attribute values held for a person by the Authentic Source have changed from those carried by the outstanding Technical PIDs of the Logical PID, revoke the outstanding Technical PIDs that carry the superseded values.

Requirement · obligation: mandatory · PDF page 42

REP-6.1-11

The PID Provider shall, when it establishes that the attribute values held for a person by the Authentic Source have changed from those carried by the outstanding Technical PIDs of the Logical PID, henceforth issue new Technical PIDs carrying the updated attribute values.

Requirement · obligation: mandatory · PDF page 42

6.2 Batch Request and Issuance Protocol

Read section 6.2 in the full text

REP-6.2-01 — ISS-4.6-02 applies also in the context of replenishment.

ISS-4.6-02 applies also in the context of replenishment.

Requirement · obligation: mandatory · PDF page 42

REP-6.2-02 — The PID Provider shall verify the authenticity and integrity of the refresh token presented in a replenishment request.

The PID Provider shall verify the authenticity and integrity of the refresh token presented in a replenishment request.

Requirement · obligation: mandatory · PDF page 43

REP-6.2-03

The PID Provider shall verify that the refresh token is cryptographically bound to the Wallet Unit that holds the Logical PID to be replenished.

Requirement · obligation: mandatory · PDF page 43

REP-6.2-04 — The PID Provider shall reject a replenishment request whose refresh token is expired or has been revoked.

The PID Provider shall reject a replenishment request whose refresh token is expired or has been revoked.

Requirement · obligation: mandatory · PDF page 43

REP-6.2-05 — ISS-4.2-04 applies also in the context of replenishment.

ISS-4.2-04 applies also in the context of replenishment.

Requirement · obligation: mandatory · PDF page 43

REP-6.2-06

The PID Provider shall verify, using the key provenance attestation provided for a batch of replenished Technical PIDs, that the PID binding key pair of every Technical PID in that batch is generated and held in a cryptographic device certified at a level appropriate for Assurance Level High.

Requirement · obligation: mandatory · PDF page 43

REP-6.2-07 — ISS-4.5-05 applies also in the context of replenishment.

ISS-4.5-05 applies also in the context of replenishment.

Requirement · obligation: mandatory · PDF page 44

REP-6.2-09

The PID Provider shall issue each replenished Technical PID as a credential that is distinct from every other Technical PID of the same Logical PID.

Requirement · obligation: mandatory · PDF page 44

REP-6.2-10

The PID Provider shall not release a replenished Technical PID to the Wallet Unit before verification of the refresh token and validation of the Wallet Unit have completed successfully.

Requirement · obligation: mandatory · PDF page 44

REP-6.2-11

The PID Provider shall deliver each replenished Technical PID to the Wallet Unit over a channel that provides confidentiality, integrity, and endpoint authentication bound to the authenticated Wallet Unit.

Requirement · obligation: mandatory · PDF page 44

REP-6.2-12 — ISS-4.7-01 applies also in the context of replenishment.

ISS-4.7-01 applies also in the context of replenishment.

Requirement · obligation: mandatory · PDF page 45

REP-6.2-13 — ISS-4.7-04 applies also in the context of replenishment.

ISS-4.7-04 applies also in the context of replenishment.

Requirement · obligation: mandatory · PDF page 45

REP-6.2-14

The PID Provider shall protect any exchange with the authentic source performed during replenishment against interception and modification.

Requirement · obligation: mandatory · PDF page 45

6.4 Exhausted Credential Cleanup

Read section 6.4 in the full text

REP-6.4-01

The PID Provider shall mark a Technical PID as expired or inactive in its administration once its technical validity period has ended or the Wallet Unit has reported that it was not accepted.

Requirement · obligation: mandatory · PDF page 45

REP-6.4-02

The PID Provider shall retain the audit log entries relating to a Technical PID for the defined retention period, including after that Technical PID has been marked as inactive in the PID Provider's administration.

Requirement · obligation: mandatory · PDF page 46

REP-6.4-03 — The PID Provider shall determine the retention period referred to in REP-5.4-02 as part of its risk assessment.

The PID Provider shall determine the retention period referred to in REP-5.4-02 as part of its risk assessment.

Requirement · obligation: mandatory · PDF page 46

7.1 Renewal Triggers and Conditions

Read section 7.1 in the full text

REN-7.1-01

The PID Provider shall not perform Batch Replenishment of a Logical PID after its Administrative Validity Period has ended without Renewal.

Requirement · obligation: mandatory · PDF page 47

REN-7.1-02 — REP-5.1-02 applies also in the context of renewal.

REP-5.1-02 applies also in the context of renewal.

Requirement · obligation: mandatory · PDF page 47

REN-7.1-03 — ISS-4.1-02 applies also in the context of renewal.

ISS-4.1-02 applies also in the context of renewal.

Requirement · obligation: mandatory · PDF page 47

REN-7.1-04 — ISS-4.1-03 applies also in the context of renewal.

ISS-4.1-03 applies also in the context of renewal.

Requirement · obligation: mandatory · PDF page 47

REN-7.1-05

The PID Provider shall record the timestamp of each renewal request together with the outcome of the re-identification performed for that request.

Requirement · obligation: mandatory · PDF page 47

REN-7.1-06

The PID Provider shall flag, for investigation, a Logical PID whose renewal requests show a frequency or a pattern relative to re-identification outcomes that exceeds a defined threshold.

Requirement · obligation: mandatory · PDF page 48

7.2 Re-identification Requirements

Read section 7.2 in the full text

REN-7.2-01

The PID Provider shall verify the identity of the person to whom the Logical PID was issued, applying the identity-proofing requirements of clause 4.3 at the same assurance level required for initial issuance, before renewing that Logical PID.

Requirement · obligation: mandatory · PDF page 48

7.3 Renewal Request and Authorisation

Read section 7.3 in the full text

REN-7.3-01 — ISS-4.4-01 applies also in the context of renewal.

ISS-4.4-01 applies also in the context of renewal.

Requirement · obligation: mandatory · PDF page 48

REN-7.3-02

The PID Provider shall not authorise a renewal unless the person's identity has been verified, no ground precluding renewal is present, and the request has been shown to originate from the Wallet Unit holding the Logical PID to be renewed.

Requirement · obligation: mandatory · PDF page 48

REN-7.3-03

The PID Provider shall verify that a renewal request is bound to the Logical PID to be renewed by requiring proof of possession of the private key corresponding to the existing PID binding public key of that Logical PID.