QEAAPuB-EAAEAASD-JWT VCmdoc

Attestation Rulebook for attestations of type Certificate of Residence (CoR)

Category: QEAA, PuB-EAA or non-qualified EAA, as stated in attestation_legal_category

This rulebook is derived from the generic WE BUILD attestation rulebook template, version 1.0 with 11 chapters and profiles the Certificate of Residence (CoR) attestation guideline for bank account onboarding of natural persons within the WE BUILD Large-Scale Pilot (LSP).

This is a working document that holds no legal value and does not reflect any common agreement or position of the co-legislators or of the WE BUILD consortium. It presents a state-of-play of ongoing work and should not be considered final.

Authors:

• [Uwe Pfizenmaier, IDnow]

Previous Authors:

• [Uwe Pfizenmaier, IDnow (all versions)]

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: [uwe.pfizenmaier@idnow.io]

1 Introduction

1.1 Document scope and purpose

This rulebook defines functional, semantic, and technical requirements for a Certificate of Residence (CoR) attestation used in the onboarding of a natural person as a retail banking customer. The attestation is designed for issuance into, and presentation from, a European Digital Identity Wallet (EUDI Wallet) within the WE BUILD Large-Scale Pilot (LSP).

What the attestation expresses: The CoR attestation provides structured, verifiable evidence of a natural person's usual place of residence (or, where no fixed residential address exists with legitimate residence in the Union, the postal address at which the person can be reached), bound to their identity.

Issuers, holders, and relying parties: - Issuers: Public administrations authorised by Member State national governance frameworks as authentic sources for residential address data (e.g. population registers, civil registries, tax authorities, municipal address registers). - Holders: Natural persons who are customers or prospective customers of obliged entities. - Relying parties: Obliged entities (credit and financial institutions and other entities subject to EU anti-money laundering and counter-terrorist-financing rules) performing Customer Due Diligence (CDD).

Primary use cases: 1. Remote or semi-remote opening of a payment or current account for a natural person, where the obliged entity relies on PID and CoR attestations presented from the EUDI Wallet to satisfy identification and residential address verification requirements under AMLR. 2. Periodic review and information update processes (e.g. "KYC refresh").

Source material: This rulebook builds on and profiles the generic Certificate of Residence (CoR) attestation guideline developed in earlier large-scale pilots. Where not explicitly amended or extended here, the provisions of that generic CoR guideline remain applicable. Attribute proofing requirements are based on ETSI TS 119 461 v2.1.1 clauses 8.2.6/8.3.6 (trusted register), 8.2.7/8.3.7 (proof of access), and 8.2.8/8.3.8 (documents and attestations).

Relationship to AMLR: This profile tailors the attribute set, integrity rules, and usage context to the specific requirements of bank account onboarding for a natural person under Regulation (EU) 2024/1620 (AMLR).

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], to indicate requirements, recommendations and options.

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF and in the generic CoR attestation guideline. In addition, "obliged entity" is used in the meaning of [AMLR] to denote credit and financial institutions and other entities subject to EU anti-money laundering and counter-terrorist-financing rules.

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

This rulebook addresses compliance with the High-Level Requirements of [Topic 12] of Annex 2 of the ARF, as summarised in the table below (derived from the compliance annex of the source CoR attestation guideline).

2.2 Regulatory basis

The CoR attestation may be issued as a QEAA, a PuB-EAA or a non-qualified EAA (section 3.1). The paragraph for the category stated in attestation_legal_category applies.

QEAA

This attestation includes the data required by Annex V of Regulation (EU) 2024/1183, points a, b, c, e and h, satisfying EW-DM-12-014, EW-DM-12-016, EW-DM-12-019, EW-DM-12-021 and EW-DM-12-023 respectively. It is issued by a qualified trust service provider.

PuB-EAA

This attestation includes the data required by Annex VII of Regulation (EU) 2024/1183, points a, b, c, e and h, satisfying EW-DM-12-014, EW-DM-12-017, EW-DM-12-019, EW-DM-12-021 and EW-DM-12-023 respectively. It is issued by or on behalf of a public sector body responsible for an authentic source.

Non-qualified EAA

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

This chapter defines all attributes and metadata that a CoR attestation MAY contain, in an encoding-independent manner. Each attribute is classified as mandatory, optional, or conditional. Definitions align with the generic CoR guideline and the AMLR minimum information requirements.

Requirements applicable to CoR as a QEAA (where applicable): - An indication that the attestation has been issued as a QEAA SHALL be included (ARB_11, Annex V point a of [European Digital Identity Regulation]). - Attributes or metadata representing issuer identity and country SHALL be included (ARB_13, Annex V point b). - Attributes representing subject identity SHALL be included (ARB_16, Annex V point c). - Validity period metadata SHALL be included (ARB_18, Annex V point e). - Trust anchor location SHALL be indicated (ARB_20, Annex V point h).

Requirements applicable to CoR as a PuB-EAA or non-qualified EAA follow the corresponding provisions of Annex VII and ARB_12–ARB_21 of [Topic 12] respectively, and SHALL be fulfilled where the CoR attestation is issued under the relevant legal category.

3.1 Introduction

The CoR attestation is designed to support AML/CFT CDD obligations. It is used together with a PID attestation: the PID identifies and verifies the natural person customer, while the CoR verifies the customer's residential address and attributes needed for risk assessment.

The CoR attestation may be issued as a QEAA, PuB-EAA, or non-qualified EAA, depending on the issuing authority and Member State governance framework. This rulebook therefore defines the attribute attestation_legal_category (Section 4.1), which SHALL have the value "QEAA", "PuB-EAA", or "non-qualified-EAA" as appropriate.

The attestation namespace and type identifier is: eu.europa.ec.eudi.cor.1.

The attribute set is structured in two groups: 1. General (identity-linking) attributes, enabling identification of the natural person, aligned with PID attributes (Section 3.2 and 3.3). 2. Residential address attributes, enabling proof of the natural person's usual place of residence (Section 3.2).

All tstr attributes SHALL have a maximum length of 150 characters. The authorised character set for CoR attestations SHALL be Latin Alphabet No. 1 as specified in ISO/IEC 8859-1. Except where an attribute is explicitly defined as an array (e.g. nationality) or a structured object (e.g. birth_place) in alignment with the ARF PID data model, multiple values per claim are not allowed.

3.2 Mandatory attributes

3.3 Optional attributes

Removed in v0.3, personal_administrative_number and tax_identification_number: These attributes were removed from the CoR attribute set. The CoR attestation is mandatorily cryptographically bound to a PID attestation on the same Wallet Unit (see § 7.1, cryptographically_bound_to, § 3.4), and § 9.1 now requires relying parties to always request and verify the PID together with the CoR. The PID is the authoritative, ARF-defined carrier of the User's national identification/administrative number and tax identifier where such attributes are relevant; duplicating them in the CoR would create redundant, potentially inconsistent copies of identity data that is already available, verified, and bound via the PID. Where a relying party's use case requires this information, it SHALL obtain it from the presented PID rather than from the CoR.

3.4 Conditional attributes

The following attribute is conditional: it SHALL be present when the CoR attestation is device-bound and cryptographically linked to another attestation on the same Wallet Unit (see § 7.1 and ARB_28 of [Topic 12]).

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1]. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires the legal category attribute, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

No conditional metadata are defined for this attestation type at this time.

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

The CoR attestation SHALL be issued in SD-JWT VC-compliant format in conformance with the SD-JWT VCs profile specified in [HAIP] (ARB_01b of [Topic 12]). Selective Disclosure SHALL be used (see Section 9).

Verifiable Credential Type (vct): eu.europa.ec.eudi.cor.1

General encoding rules: - JSON attributes SHALL be encoded as specified in [RFC 8259]. - full-date values SHALL conform to [RFC 3339] full-date format. - All string attributes SHALL have a maximum length of 150 characters. - resident_address encoding (SD-JWT VC): In SD-JWT VC, resident_address is encoded as a nested JSON object with Recursive Disclosures, enabling individual address sub-claims (resident_street, resident_house_number, resident_postal_code, resident_city, resident_state, resident_country) to be selectively disclosed independently. This differs from the mdoc encoding where resident_address is a flat tstr (see § 5.2). Issuers SHALL ensure consistency between the nested sub-claims and the flat resident_address value per IR-03.

IANA-registered / well-known claims:

Private claim names specific to CoR attestation type:

Example, JWT Claim Set (issuer payload):

{
  "vct": "eu.europa.ec.eudi.cor.1",
  "iss": "https://ctie.etat.lu",
  "issuing_authority": "CTIE",
  "issuing_country": "LU",
  "attestation_legal_category": "QEAA",
  "iat": 1738147797,
  "exp": 1738183797,
  "nbf": 1738148097,
  "_sd_alg": "sha-256",
  "_sd": [
    "G22coLkZdH6gGqWHlgbYXp8K194YREJwpVdfxk8IBFc",
    "3CEVLuh0JiwrS_5ERgn2lYohk_g-G6Yu_VfcAQDG9xg",
    "ZeKw7C-JDLv_0S_khqhJM7GLJPM_v6MA2KLillGGmEk",
    "MMp6Y6XpR4mv3YEUZVFB969mMTTIapFk60DYih0zsmQ",
    "6y1MJKyX0LEjD1zK-VOQrDj3_VH7yNBraXmofT2okjk",
    "NE2gFqsj27enkQ4ahcHKMPtqXv2y8Q_vGf30J0N5XBg",
    "-eMdNZWQi2JluPKSE4B2ODCeIrIT46h-mq1NjOrDNN0",
    "ad0vpVyDzLaLhB8nRbqIq8iTnMqq7GfCnFnu4VMUfnA",
    "dRNEYSBhXeG-lK7VLDkvCMwmMkq4aW-LcaUOGoox2-M",
    "V9Pc6SDxByKaH9ES2ABDRUKj8jVtHfwVaZRDDb1-CTI",
    "wdxxiUyZjrS_iN8nFfRHBfoejwJN7ClfPX38JUSuFaw"
  ],
  "cnf": {
    "jwk": {
      "crv": "P-256",
      "kty": "EC",
      "x": "wUuP2OlwHefeE-Y16Wj7PHAzZ0JAQyevqWMfd5-KmKY",
      "y": "YW-b8O3Uk3NUrk9oZpAT1laPeAgiNQwDcotWiwBFQ6E"
    }
  }
}

Example, Disclosures included in the example token:

Note, claim name alignment (OPEN ISSUE): The claim identifiers used in the example above (e.g. thoroughfare, post_code, post_name, admin_unit_L1, full_address) reflect naming conventions from the source WE BUILD pilot example and do not match the normative attribute identifiers defined in Section 3 (e.g. resident_street, resident_postal_code, resident_city, resident_country, resident_address). Conforming implementations SHALL use the normative identifiers from Section 3. The WE BUILD consortium SHOULD resolve this alignment in the next revision of the generic CoR guideline and update the examples in this rulebook accordingly. Until resolved, issuers using the pilot naming convention SHOULD document the mapping explicitly in their system documentation.

Example, Full issued SD-JWT VP Token (base64url-encoded):

eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJFUzI1NiJ9.eyJfc2QiOlsiRzIyY29Ma1pkSDZnR3FXSGxnYllYcDhL
MTk0WVJFSndwVmRmeGs4SUJGYyIsIjNDRVZMdWgwSml3clNfNUVSZ24ybFlvaGtfZy1HNll1X1ZmY0FRREc5eGci
LCJaZUt3N0MtSkRMdl8wU19raHFoSk03R0xKUE1fdjZNQTJLTGlsbEdHbUVrIiwiTU1wNlk2WHBSNG12M1lFVVpW
RkI5NjltTVRUSWFwRms2MERZaWgwenNtUSIsIjZ5MU1KS3lYMExFakQxekstVk9RckRqM19WSDd5TkJyYVhtb2ZU
Mm9ramsiLCJORTJnRnFzajI3ZW5rUTRhaGNIS01QdHFYdjJ5OFFfdkdmMzBKME41WEJnIiwiLWVNZE5aV1FpMkps
dVBLU0U0QjJPRENlSXJJVDQ2aC1tcTFOak9yRE5OMCIsImFkMHZwVnlEekxhTGhCOG5SYnFJcThpVG5NcXE3R2ZD
bkZudTRWTVVmbkEiLCJkUk5FWVNCaFhlRy1sSzdWTERrdkNNd21Na3E0YVctTGNhVU9Hb294Mi1NIiwid2R4eGlV
eVpqclNfaU44bkZmUkhCZm9landKTjdDbGZQWDM4SlVTdUZhdyIsIlY5UGM2U0R4QnlLYUg5RVMyQUJEUlVLajhq
VnRIZndWYVpSRERiMS1DVEkiXSwi...
[full token as provided in source document]

5.2 ISO/IEC 18013-5-compliant encoding

The CoR attestation MAY be issued in ISO/IEC 18013-5-compliant mdoc format where proximity presentation (without internet) is required by the deployment context. Member States and issuers SHALL determine, in accordance with ARB_02 of [Topic 12], whether proximity presentation is a required capability for their deployment of the CoR attestation.

Document type: eu.europa.ec.eudi.cor.1

General encoding rules: - tstr, uint, bstr, bool, and tdate are CDDL representation types defined in [RFC 8610]. - A tstr SHALL be encoded in UTF-8 (as specified in [RFC 8949]) and SHALL support the full Unicode range within the Latin Alphabet No. 1 (ISO/IEC 8859-1) character set constraint for CoR. - All attributes with encoding type tstr SHALL have a maximum length of 150 characters. - full-date is encoded as full-date = #6.1004(tstr), where tag 1004 is specified in [RFC 8943]. - In accordance with [RFC 8949] section 3.4.1, a tdate attribute SHALL contain a date-time string as specified in [RFC 3339]. - Fractions of seconds SHALL NOT be used; local offsets from UTC SHALL NOT be used; the time-offset SHALL be "Z". - resident_address encoding (mdoc): In ISO/IEC 18013-5-compliant mdoc, resident_address is encoded as a flat tstr containing the full address as a human-readable string. This differs from the SD-JWT VC encoding where it is a nested JSON object with Recursive Disclosures (see § 5.1). Issuers SHALL ensure that the string value in mdoc is consistent with the granular resident_* fields per IR-03.

Attribute encoding table:

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF FULL OR PARTIAL mDOC OF THE ATTESTATION]

5.3 W3C Verifiable Credentials Data Model-based encoding

The CoR attestation MAY be issued in W3C VCDM v2.0-compliant format. Note that, per ARB_01a of [Topic 12], only a non-qualified EAA can use this format.

[RULEBOOK AUTHOR TO PROVIDE HUMAN-READABLE EXAMPLE OF THE ISSUED ATTESTATION IN W3C VCDM FORMAT]

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE PROOF TYPE]

Tables analogous to those in Section 5.1 SHALL be defined, referencing documents approved by an EU standardisation body or the European Digital Identity Cooperation Group as required by ARB_04 of [Topic 12].

6 Protocols

6.1 Issuance

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI], as profiled by [HAIP].

6.2 Presentation

This attestation is presented using OpenID for Verifiable Presentations [OpenID4VP] for remote presentation. Proximity presentation uses ISO/IEC 18013-5 and requires the mdoc encoding recorded in chapter 5.

7 Issuance

7.1 Binding

The CoR attestation SHOULD be device-bound to the EUDI Wallet Unit of the holder. Where device binding is applied, the attestation SHALL be cryptographically bound to the PID attestation on the same Wallet Unit (ARB_28 of [Topic 12]). When such binding is required, the conditional attribute cryptographically_bound_to (defined in § 3.4) SHALL be present in the attestation and SHALL be set to: - "eu.europa.ec.eudi.pid.1" for ISO/IEC 18013-5 (mdoc) attestations; or - "urn:eudi:pid:1" for SD-JWT VC attestations.

Where the CoR attestation is not device-bound, the cryptographically_bound_to attribute SHALL be omitted.

7.2 Issuance Policy

General obligations on Attestation Providers are out of scope of this Rulebook. They are specified in Topic 10 of Annex 2 of the ARF, in the applicable Implementing Regulations, and in [ETSI TS 119 471]. This Rulebook states only obligations specific to this attestation type.

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

Per [Topic 7] of Annex 2 of the ARF:

In the current WE BUILD LSP deployment, revocation is out of scope. Wallet instances and CoR attestations are assumed not to be revoked during the pilot. Future deployments targeting production or cross-border use SHOULD define a revocation mechanism in conformance with one of the following methods (as applicable at the time of that deployment):

• An Attestation Status List mechanism included in a Technical Specification specified by the Commission.
• An Attestation Revocation List mechanism included in a Technical Specification specified by the Commission.

Where the CoR attestation has a short validity period (24 hours or less), revocation is not required.

9 Presentation

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

• Relying parties (obliged entities) SHALL request and verify a PID attestation alongside the CoR attestation (see ARB_27 of [Topic 12]). Since the CoR attestation no longer independently carries personal_administrative_number or tax_identification_number (removed in v0.3; see § 3.3 rationale), and its identity attributes are cryptographically bound to the PID (§ 7.1), the PID SHALL always be requested and verified together with the CoR to establish the natural person's full identity context. The PID is used to identify and verify the natural person customer (e.g. name, date and place of birth, and, where applicable, national identification/tax numbers); the CoR attestation verifies the residential address.
• Obliged entities remain responsible for determining whether the CoR issuer constitutes an acceptable and sufficiently reliable source for CDD, taking into account their risk-based approach and applicable supervisory expectations.
• The CoR attestation does not replace the obliged entity's responsibility to perform ongoing monitoring or to keep customer information up to date.
• Relying parties SHALL verify the attestation signature and check the validity period metadata (issuance date and, where present, expiry date).
• CoR attestation attributes SHALL be released only in a VP Token, as specified in [OpenID4VP].

9.2 Presentation modes

The CoR attestation is designed primarily for remote (online) presentation. Proximity presentation (offline) is not required by default but MAY be supported by mdoc-capable issuers where Member State governance frameworks require it.

9.3 Transactional data

This Rulebook defines no transactional data.

No transactional data requirements are defined for this attestation type at this time. [See Topic 20 of Annex 2 of the ARF for High-Level Requirements related to transactional data.]

9.4 Primary use cases

1. Bank account onboarding: Remote or semi-remote opening of a payment or current account for a natural person, where the obliged entity relies on PID and CoR attestations presented from the EUDI Wallet to satisfy AMLR CDD identification and residential address verification requirements.
2. KYC refresh: Periodic review and update of residential address information, enabled by re-issuance of the CoR attestation when the customer updates their address and obtains a newly issued attestation.

9.5 Presentation requirements

• Selective Disclosure SHALL be used for the CoR attestation (ARF section 5.3).
• SD-JWT with Recursive Disclosures SHOULD be used for the resident_address object, enabling individual address sub-claims to be selectively disclosed.

10 Trust Framework

The trust anchor is obtained as described in the branch below that corresponds to the legal category under which the attestation was issued.

PID, QEAA, PuB-EAA and attestations resolved via Trusted Lists

The trust anchor is obtained from a Trusted List, as described in section 6.6.3.6 of the ARF main document. The Provider may sign the attestation with an intermediate signing certificate, in which case the trust anchor is used to verify that certificate rather than the attestation directly.

For QEAA and PuB-EAA CoR attestations, relying parties SHALL obtain the trust anchor from the applicable EU Trusted List, in conformance with ARB_20 of [Topic 12] and the ARF. Issuers MAY use an intermediate signing certificate, with the trust anchor signing the intermediate certificate.

For non-qualified EAA CoR attestations, the location of the machine-readable trust anchor SHALL be indicated in the attestation metadata (per ARB_21 of [Topic 12]). Relying parties SHOULD use this location to retrieve and verify the trust anchor.

WE BUILD LSP context (current): In the current WE BUILD Large-Scale Pilot (LSP) deployment, a formal trusted issuer list mechanism is out of scope. Participating CoR Attestation Providers and Relying Parties are assumed to be familiar with the CoR attestation guideline and with the list of participating issuers.

Production / cross-border deployments (future): Future versions of this rulebook MUST replace the above with a concrete trust anchor mechanism aligned with: - The EU Trusted List framework established pursuant to [2015/1505]; - ARF Chapter 6.2 and [HLR] Topic 31 part H (trusted list of issuers); - The technical specifications for trust anchor distribution defined by the European Digital Identity Cooperation Group.

Signing (issuer signing attestation, verifier signing request) SHALL be implemented in conformance with [POTENTIAL D2.2] SD-JWT VC specification. Specific cryptographic algorithms and elliptic curves SHALL be determined in accordance with applicable technical specifications once finalised; holder/device binding SHALL also conform to [POTENTIAL D2.2].

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References