diff --git a/docs/annexes/annex-1/annex-1-definitions.md b/docs/annexes/annex-1/annex-1-definitions.md index ae14e2c..2fea984 100644 --- a/docs/annexes/annex-1/annex-1-definitions.md +++ b/docs/annexes/annex-1/annex-1-definitions.md @@ -112,4 +112,4 @@ from the eIDAS Regulation or the amendment proposal:** [^1]: , - Article 32, section 1 (c) + Article 32, Section 1 (c) diff --git a/docs/annexes/annex-2/annex-2-high-level-requirements.md b/docs/annexes/annex-2/annex-2-high-level-requirements.md index 7974fc0..24023c8 100644 --- a/docs/annexes/annex-2/annex-2-high-level-requirements.md +++ b/docs/annexes/annex-2/annex-2-high-level-requirements.md @@ -31,7 +31,7 @@ but, for instance, by an external standard or specification. The word ### A.2.2 Structure and order of presentation of the HLRs -Topics presented in [section A.2.3](##a23-high-level-requirements) are ordered by a Topic number. +Topics presented in [Section A.2.3](##a23-high-level-requirements) are ordered by a Topic number. Each Topic includes a short description, followed by the High-Level Requirements (HLRs), identified by a unique identifier. The identifier @@ -338,7 +338,7 @@ WSCA. | **Index** | **Requirement** | |-----------|--------------| -| WTE_28 | A WSCA SHALL be able to verify the authentication factors of a User, in accordance with the requirements in [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) section 2.2.1. | +| WTE_28 | A WSCA SHALL be able to verify the authentication factors of a User, in accordance with the requirements in [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) Section 2.2.1. | | WTE_29 | A WSCA SHALL be able to generate a new key pair on request of the Wallet Instance. | | WTE_30 | A WSCA SHALL be able to prove possession of the private key corresponding to a public key on request of a Wallet Instance, for example by signing a challenge with that private key. | | WTE_31 | A WSCA SHALL register each newly generated key pair as either a WTE key or an attestation key, depending on information provided by the Wallet Instance in the key generation request. The internal registry used by the WSCA for this purpose SHALL be protected against modification by external parties. | @@ -368,7 +368,7 @@ A - Generic HLRs | ISSU_02 | Wallet Providers SHALL ensure that their Wallet Solution supports the attestation formats specified in: with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. | | ISSU_03 | Wallet Providers SHALL ensure that their Wallet Solution supports the presentation protocols specified in: with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. | | ISSU_04 | The OpenID4VCI protocol specified in [OpenID4VCI] SHALL enable PID Providers and Attestation Provider to issue to a Wallet Instance a batch of multiple PIDs or attestations that are simultaneously valid and contain the same attributes. | -| ISSU_05 | A Wallet Instance SHALL support a process to activate a newly issued PID or attestation, in accordance with [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) section 2.2.2. The goal of the activation process is to verify that the PID or attestation was delivered into the Wallet Instance and WSCA of the User to whom it belongs. The Wallet Instance SHALL NOT allow a User to use a non-activated PID or attestation. | +| ISSU_05 | A Wallet Instance SHALL support a process to activate a newly issued PID or attestation, in accordance with [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) Section 2.2.2. The goal of the activation process is to verify that the PID or attestation was delivered into the Wallet Instance and WSCA of the User to whom it belongs. The Wallet Instance SHALL NOT allow a User to use a non-activated PID or attestation. | | ISSU_06 | After a Wallet Instance receives a PID or an attestation from a PID Provider or Attestation Provider, it SHALL verify that the PID or attestation it received matches the request. | | ISSU_07 | After a Wallet Instance receives a PID from a PID Provider, it SHALL validate the signature or seal of the PID using a trust anchor provided in a PID Provider Trusted List made available in accordance with [[Topic 31](#a2331-topic-31---pid-provider-wallet-provider-attestation-provider-and-access-certificate-authority-notification-and-publication)]. | | ISSU_08 | After a Wallet Instance receives a QEAA from a QEAA Provider, it SHALL validate the qualified signature or seal of the QEAA in accordance with Art.32 of the eIDAS Regulation. For the verification, the Wallet Instance SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with [Art. 22](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) of the eIDAS Regulation. | @@ -469,7 +469,7 @@ C. Requirements regarding attestation namespaces | **Index** | **Requirement specification** | | -----| --------| -| ARB_6 | The body responsible for an Attestation Rulebook SHALL define all attributes that an attestation of that type may contain within one or more attribute namespace(s). An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that namespace have an identifier that is unique within the scopeof the EUDI Wallet ecosystem.| +| ARB_6 | The body responsible for an Attestation Rulebook SHALL define all attributes that an attestation of that type may contain within one or more attribute namespace(s). An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that namespace have an identifier that is unique within the scope of the EUDI Wallet ecosystem.| | ARB_7 | When determining the attributes to be included in a new attestation type, the party responsible for the applicable Attestation Rulebook SHOULD consider referring to attributes that have been defined already in a namespace included in the catalogue as specified in [Topic 25](#a2325-topic-25---unified-definition-and-controlled-vocabulary-for-attestation-attributes) + [26](#a2326-topic-26---attestations-catalogue), rather than unnecessarily re-defining all attributes within a new namespace. | | ARB_8 | The body responsible for an Attestation Rulebook SHOULD, when specifying a new attestation namespace, take into consideration existing conventions for attribute identifier values and attribute syntaxes. These conventions MAY depend on the format of the attestation, i.e., CBOR for ISO/IEC 18013-5 compliant attestations or JSON for \[SD-JWT VC\]-compliant attestations. | | ARB_9 | The body responsible for an Attestation Rulebook SHOULD ensure that the value of the namespace identifier uses the general format \[Reverse Domain Name\].\[Domain Specific Extension\].\[Version\], where the Domain Name SHOULD be controlled by the responsible body. | @@ -731,7 +731,7 @@ See [Topic 10](#a2310-topic-10---issuing-a-pid-or-attestation-to-the-eudi-wallet In this use case, the User is utilizing the Wallet Instance for identification purposes in proximity scenarios. The User is concerned -about sharing personal data in proximity, while ithe User\'s objectives +about sharing personal data in proximity, while the User\'s objectives include identifying themselves to services requiring user identification and maintaining control over their personal data sharing.  @@ -829,7 +829,7 @@ entity to receive an access certificate that Wallet Instances can use to authenticate them This Topic specifies high-level requirements related to the registration -of the abovementioned entities.  +of the above mentioned entities.  *HLRs* @@ -1039,8 +1039,8 @@ A. Generic requirements for notification | **Index** | **Requirement specification** | |-----------|-----------------| -| GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, and Relying Party Access Certificate Authorities by Member States to the Commission.


Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in sections D and F below, respectively. | -| GenNot_02 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider or Relying Party Access Certificate Authorities to the Commission.


Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in section H, TLPub_01. | +| GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, and Relying Party Access Certificate Authorities by Member States to the Commission.


Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in Sections D and F below, respectively. | +| GenNot_02 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider or Relying Party Access Certificate Authorities to the Commission.


Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in Section H, TLPub_01. | | GenNot_03 | The common system mentioned in GenNot_01 SHALL enable:

  1. A secure notification channel between MS & COM for all notifications.
  2. A notification, verification, and publication process and associated validation steps (with follow-up and monitoring) at the Commission side.
  3. Collected data to be processed, consolidated, signed/sealed and published in both a machine-processable Trusted List and in a human-readable format, manually and/or automatically using e.g. a web service and/or API.
| | GenNot_04 | As regard to GenNot_03, point b), the Commission SHALL verify whether the notified data is complete and meets the technical specifications, while the Member States SHALL be responsible for the correctness of the notified information. | | GenNot_05 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the withdrawal of a PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority. These operating procedures SHALL include unambiguous conditions for withdrawal. As an outcome of the withdrawal procedure, the status of the withdrawn PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority in the Trusted List SHALL be changed to Invalid. | @@ -1050,7 +1050,7 @@ B. Requirements for the notification of PID Providers | **Index** | **Requirement specification** | |-----------|-----------------| | PPNot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about PID Providers. | -| PPNot_02 | The common set of information to be notified about a PID Provider SHALL include:
  1. Identification data:
    1. MS/Country of establishment,
    2. Name as registered in an official record,
    3. Where applicable:
      1. A business registration number from an official record,
      2. Identification data from that official record.
  2. PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider,
  3. PID Provider Access CA trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Instances at the service supply point(s) listed per point 4) below.
  4. Service supply point(s), i.e., the URL(s) at which a Wallet Instance can start the process of requesting and obtaining a PID.

Notes:

| +| PPNot_02 | The common set of information to be notified about a PID Provider SHALL include:
  1. Identification data:
    1. MS/Country of establishment,
    2. Name as registered in an official record,
    3. Where applicable:
      1. A business registration number from an official record,
      2. Identification data from that official record.
  2. PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider,
  3. PID Provider Access CA trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Instances at the service supply point(s) listed per point 4) below.
  4. Service supply point(s), i.e., the URL(s) at which a Wallet Instance can start the process of requesting and obtaining a PID.

Notes:

| | PPNot_03 | PID Providers SHALL ensure that all PIDs they issue can be authenticated using the PID Provider trust anchors notified to the Commission. | | PPNot_04 | PID Providers SHALL ensure that their PID Provider access certificates can be authenticated using the PID Provider Access CA trust anchors notified to the Commission.


Note: \[[Topic 6](#a236-topic-6---relying-party-authentication-and-user-approval)\] describes how access certificates will be used. | | PPNot_05 | PID Provider trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled PID Provider Trusted List which is sealed by the Commission. | diff --git a/docs/annexes/annex-3/annex-3.01-pid-rulebook.md b/docs/annexes/annex-3/annex-3.01-pid-rulebook.md index f1cd764..1e9ed0f 100644 --- a/docs/annexes/annex-3/annex-3.01-pid-rulebook.md +++ b/docs/annexes/annex-3/annex-3.01-pid-rulebook.md @@ -91,7 +91,7 @@ version of the ISO-compliant PID attribute (defined in this document) and any future version. Similarly, PID Providers SHALL use the value "eu.europa.ec.eudi.pid.1" -for the namespace of the first version of the PID attributes specified in section [2.3](#23-pid-attributes). This namespace clearly indicates that any attributes defined +for the namespace of the first version of the PID attributes specified in Section [2.3](#23-pid-attributes). This namespace clearly indicates that any attributes defined within it are Person Identification Data specified in the context of the EUDI Wallet. Again, the version number "1" allows for future extension(s) or change(s) of the PID attributes defined in the next @@ -101,8 +101,8 @@ Note that the attestation type and namespace have the same value. This is allowed according to ISO/IEC 18013-5. PID Providers SHALL use this attestation type and namespace for the -ISO/IEC 18013-5 compliant attribute encoding specified in [section 2.4.2](#242-isoiec-18013-5-compliant-encoding) -and for the SD-JWT-compliant encoding in [section 2.4.3](#243-sd-jwt-compliant-encoding). +ISO/IEC 18013-5 compliant attribute encoding specified in [Section 2.4.2](#242-isoiec-18013-5-compliant-encoding) +and for the SD-JWT-compliant encoding in [Section 2.4.3](#243-sd-jwt-compliant-encoding). #### 2.2.2 Domestic PID namespaces for national attributes @@ -123,7 +123,7 @@ EXAMPLE: The first domestic PID namespace for Germany could be "eu.europa.ec.eudi.pid.de.1". PID Providers SHALL use the same domestic namespace for both ISO/IEC -18013-5-compliant PIDs and SD-JWT-compliant PIDs, see section 2.4. +18013-5-compliant PIDs and SD-JWT-compliant PIDs, see Section 2.4. A PID Provider that defines a domestic namespace SHALL publish the namespace, including all attribute identifiers, their definition, @@ -134,7 +134,7 @@ applicable requirements in \[[Topic 12](../annex-2/annex-2-high-level-requiremen #### 2.3.1 Introduction -PID attributes are defined in Table 1 in [section 2.3.2](#232-overview). +PID attributes are defined in Table 1 in [Section 2.3.2](#232-overview). Table 1 contains the following information: @@ -173,7 +173,7 @@ Table 1 contains the following information: - This document specifies full-date as full-date = #6.1004(tstr), where tag 1004 is specified in \[[RFC 8943](https://datatracker.ietf.org/doc/html/rfc8943)\]. - - In accordance with \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\], section 3.4.1, a tdate + - In accordance with \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\], Section 3.4.1, a tdate attribute shall contain a date-time string as specified in \[[RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)\]. In accordance with \[[RFC 8943](https://datatracker.ietf.org/doc/html/rfc8943)\], a full-date attribute shall contain a full-date string as specified in \[[RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)\]. @@ -212,7 +212,7 @@ Table 1 contains the following information: | resident_street | The name of the street where the PID User currently resides. | O* | tstr | | resident_house_number | The house number where the PID User currently resides, including any affix or suffix. | O* | tstr | | gender | PID User's gender, using a value as defined in ISO/IEC 5218. | O* | uint | -| nationality | Alpha-2 country code as specified in ISO 3166-1, representing the nationality of the PID User. | O* | See section 2.3.6 | +| nationality | Alpha-2 country code as specified in ISO 3166-1, representing the nationality of the PID User. | O* | See Section 2.3.6 | | issuance_date | Date (and possibly time) when the PID was issued. | M | tdate or full-date | | expiry_date | Date (and possibly time) when the PID will expire. | M | tdate or full-date | | issuing_authority | Name of the administrative authority that has issued this PID instance, or the ISO 3166 Alpha-2 country code of the respective Member State if there is no separate authority authorized to issue PIDs. | M | tstr | @@ -224,7 +224,7 @@ Table 1 contains the following information: **Table 1 PID attributes** Note: For the attributes for which the presence is indicated as O\*, see -[section 2.3.7](#237-minimum-number-of-optional-attributes). +[Section 2.3.7](#237-minimum-number-of-optional-attributes). #### 2.3.3 Date of birth-related attributes @@ -243,7 +243,7 @@ birth of the PID User: Having multiple attributes instead of only one allows having different levels of granularity for requests and responses, and thus allows PID -Providers and Relying Parties to practice data minimization. For +Providers and Relying Parties to practice data minimisation. For example, in some use cases, a Relying Party only needs to establish that the PID User is not a minor. In that case, requesting age_over_18 suffices. Releasing more specific information, such as the PID User's @@ -320,7 +320,7 @@ multi-valued attribute, because a citizen can have more than one nationality. However, their document defines an attribute nationality taking as its value a single Alpha-2 country code. This implies that any additional nationality of the PID User must be added by the respective -Member State as a domestic attribute, see [section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes). +Member State as a domestic attribute, see [Section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes). #### 2.3.7 Minimum number of optional attributes @@ -390,7 +390,7 @@ SD-JWT-compliant encoding in JSON. If attributes specified in Table 1 are encoded with CBOR, they SHALL be encoded as specified in \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\]. -The CDDL representation types used in Table 1 are specified in [section 2.3.1](#231-introduction-introduction-1). +The CDDL representation types used in Table 1 are specified in [Section 2.3.1](#231-introduction-introduction-1). Rules to encode CDDL representation types with CBOR are specified in \[RFC 8610\] and \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\]. @@ -428,7 +428,7 @@ Attributes in Table 1 SHALL be released only as Issuer Signed Items, as specified in \[ISO/IEC 18013-5\]. This means that these attributes SHALL be signed by the PID Provider, not by the Wallet Instance. -At the discretion of the PID Provider, domestic attributes (see [section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes)) MAY be signed either by the PID Provider or by the Wallet +At the discretion of the PID Provider, domestic attributes (see [Section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes)) MAY be signed either by the PID Provider or by the Wallet Instance. All attributes in Table 1 SHALL be made selectively disclosable. @@ -440,8 +440,8 @@ All attributes in Table 1 SHALL be made selectively disclosable. If attributes are encoded with JSON, they SHALL be encoded as specified in \[RFC 8259\]. -The CDDL representation types used in Table 1 are specified in [section 2.3.1](#231-introduction-introduction-1). Rules to encode CDDL representation types with JSON are specified -in \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\] section 6.1. +The CDDL representation types used in Table 1 are specified in [Section 2.3.1](#231-introduction-introduction-1). Rules to encode CDDL representation types with JSON are specified +in \[[RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949)\] Section 6.1. Given the CDDL representation types used in the current version of this document, the following rules are relevant: - A CDDL uint (i.e., an unsigned integer) becomes a JSON number. @@ -486,7 +486,7 @@ PID attributes in Table 1 SHALL be released only in a VP Token, as specified in \[OpenID4VP\]. This means that these attributes SHALL be signed by the PID Provider, not by the Wallet Instance. -At the discretion of the PID Provider, domestic attributes (see [section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes)) MAY be released in either a VP Token or an ID Token. +At the discretion of the PID Provider, domestic attributes (see [Section 2.2.2](#222-domestic-pid-namespaces-for-national-attributes)) MAY be released in either a VP Token or an ID Token. All attributes in Table 1 SHALL be made selectively disclosable. @@ -538,7 +538,7 @@ have their own arc 'next' to this one, if necessary.* - *id-eudi-iso-pid OBJECT IDENTIFIER ::= {id-eudi-iso 0}
- - arc for PID attributes within ISO-compliant EUDI Wallets.* -- *id-eudi-iso-pid-kp OBJECT IDENTIFIER ::= {id- eudi-iso-pid 1}
- - arc for extended key purposes within certificates used for PID +- *id-eudi-iso-pid-kp OBJECT IDENTIFIER ::= {id-eudi-iso-pid 1}
- - arc for extended key purposes within certificates used for PID attributes within ISO-compliant EUDI Wallets* - *id-eudi-iso-pid-kp-DS OBJECT IDENTIFIER ::= {id-eudi-iso-pid-kp 2}
- - arc for document signer certificates, used by PID Providers* diff --git a/docs/arf.md b/docs/arf.md index d409836..1fa6e7a 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -39,7 +39,7 @@ specifications, standards and procedures that the Commission shall develop for the purpose of implementing the [eIDAS Regulation](https://eur-lex.europa.eu/eli/reg/2024/1183/oj), and which are related to the following topics: -- EUDIW Core functionalities ([art. 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1)) +- EUDIW core functionalities ([art. 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1)) - EUDIW relying parties ([art. 5b](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1776-1-1)) @@ -112,7 +112,7 @@ the reference implementation. The LSPs are expected to provide feedback on the ARF as they develop and interact with Relying Party services, Qualified or non-qualified Electronic Attestations of Attributes (Q)EAA Providers, Person -Identification Data (PID) Providers, Qualified and non-qualified Trust +Identification Data (PID) Providers, Qualified and non-Qualified Trust Service Providers and Users in meaningful interactions under the proposed use cases. @@ -165,16 +165,16 @@ The eIDAS Expert Group has described service blueprints for the following use cases: - Identification and authentication to access online services, see - [section 2.1](#21-identification-and-authentication-to-access-online-services) + [Section 2.1](#21-identification-and-authentication-to-access-online-services) -- Qualified Electronic Signature, see [section 2.2](#22-qualified-electronic-signature) +- Qualified Electronic Signature, see [Section 2.2](#22-qualified-electronic-signature) -- Mobile Driving Licence, see [section 2.3](#23-mobile-driving-licence) +- Mobile Driving Licence, see [Section 2.3](#23-mobile-driving-licence) -- Pseudonyms, see [section 2.4](#24-pseudonyms). +- Pseudonyms, see [Section 2.4](#24-pseudonyms). - Several other use cases that will be detailed in subsequent versions - of this document, see [section 2.5](#25-other-use-cases). + of this document, see [Section 2.5](#25-other-use-cases). ### 2.1 Identification and authentication to access online services @@ -197,7 +197,7 @@ This scenario covers the complete lifecycle of the EUDI Wallet from the User\'s perspective. It spans from acquiring a valid Wallet Instance to the process of identifying and authenticating themselves for an online service. The focus here is on a practical remote same-device flow (as -detailed in [section 4.2.2](#422-attestation-presentation-flows) and [4.2.3](#423-mobile-apps-and-web-browsers)). In this context, a User utilises a +detailed in [Section 4.2.2](#422-attestation-presentation-flows) and [4.2.3](#423-mobile-apps-and-web-browsers)). In this context, a User utilises a single device for both securing their session and accessing the service, ensuring a streamlined and secure experience. @@ -276,7 +276,7 @@ parties. The EUDI Wallet Solutions can facilitate complying with strong customer authentication requirements, using the strong User Authentication -capabilities described in [section 2.1](#21-identification-and-authentication-to-access-online-services). In line with the Commission's +capabilities described in [Section 2.1](#21-identification-and-authentication-to-access-online-services). In line with the Commission's Retail Payments Strategy \[RPS\], the use case would be developed in close coordination with Member States' advisory groups on retail payments and the finance industry. @@ -334,9 +334,9 @@ Figure 1: Overview of the EUDI Wallet roles ### 3.1 Users of EUDI Wallet -Users of EUDI Wallets use the EUDI Wallet instance to receive, store and +Users of EUDI Wallets use the EUDI Wallet Instance to receive, store and present PID, QEAA, PuB-EAA, or EAA about themselves, including to prove -their identity. EUDI Wallet instance Users can also create Qualified +their identity. EUDI Wallet Instance Users can also create Qualified Electronic Signatures and Seals (QES) and utilise wallet-to-wallet interactions. @@ -414,7 +414,7 @@ ecosystem, Trusted Lists exist for the following entities: - PuB-EAA Providers. -These Trusted Lists are described in more detail in [section 6.2.2](#622-wallet-provider-registration-and-notification), [6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) +These Trusted Lists are described in more detail in [Section 6.2.2](#622-wallet-provider-registration-and-notification), [6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) and [6.4.2](#642-relying-party-registration), as well as in \[Topic 31\]. Trusted Lists primarily contain the trust anchors of the relevant entities. A trust anchor is a combination of a public key and the identifier of the associated entity @@ -501,7 +501,7 @@ technical interoperability between them and this will enhance competition and create better QTSP services. Besides Qualified Electronic Signatures and Seals, also Non-Qualified -Electronic Signatures or Seal providers can exist. However, +Electronic Signatures or Seal Providers can exist. However, Non-Qualified Electronic Signature/ Seal Providers are out of scope of the ARF. @@ -509,11 +509,11 @@ the ARF. Authentic Sources are the public or private repositories or systems recognised or required by law containing attributes about natural and/ -or legal persons. The Authentic Sources in scope of article 45e are sources for, e.g. attributes on address, +or legal persons. The Authentic Sources in scope of Article 45e are sources for, e.g. attributes on address, age, gender, civil status, family composition, nationality, education and training qualifications titles and licences, professional qualifications titles and licences, public permits and licences, -financial and company data. Authentic Sources in scope of article 45e are +financial and company data. Authentic Sources in scope of Article 45e are required to provide interfaces to QEAA Providers to verify the authenticity of the above attributes, either directly or via designated intermediaries recognised at national level. Authentic Sources may also @@ -951,7 +951,7 @@ Figure 4: State-chart of Wallet Instance An EUDI Wallet Instance lifecycle begins when the User installs a component part of a valid EUDI Wallet Solution to their User device (see -[section 6.2](#62-trust-throughout-a-wallet-solution-lifecycle); the Wallet Instance status is **installed**. Once an EUDI +[Section 6.2](#62-trust-throughout-a-wallet-solution-lifecycle); the Wallet Instance status is **installed**. Once an EUDI Wallet Instance establishes communication with other components that are part of the Wallet Solution, is activated, and is issued a Wallet Trust Evidence (WTE) and a Wallet Instance Attestation (WIA) by an EUDI Wallet @@ -989,7 +989,7 @@ Notes on Wallet Instance: - The security provided by the Wallet Instance is relying on the Wallet Secure Cryptographic Device and its Wallet Secure - Cryptographic Application. In the architecture overview ([section + Cryptographic Application. In the architecture overview ([Section 6.1](#61-overview), figure 6) it is explained that multiple solutions are available for implementation, such as Remote Wallet Secure Cryptographic Device, Local External Wallet Secure Cryptographic Device, Local @@ -1148,7 +1148,7 @@ Attestation Rulebooks are defined by different organisations: ### 5.4 Catalogues -Section 2 in [article 45e](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e3883-1-1) of the regulation, sets up the direct legal +Section 2 in [Article 45e](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e3883-1-1) of the regulation, sets up the direct legal basis for the Commission to \"**where necessary, establish specifications and procedures** for the catalogue of attributes and schemes for the attestation of attributes and verification procedures @@ -1286,7 +1286,7 @@ Access CA**. [Section 6.4](#64-trust-throughout-a-relying-party-lifecycle) descr the lifecycle of a Relying Party, namely registration, and possibly de-registration. -Finally, [section 6.6](#66-trust-throughout-a-pid-or-an-attestation-lifecycle) describes interactions in the lifecycle of a PID or +Finally, [Section 6.6](#66-trust-throughout-a-pid-or-an-attestation-lifecycle) describes interactions in the lifecycle of a PID or an attestation, namely issuance, presentation to a Relying Party or to another Wallet Instance, management, and deletion. @@ -1393,11 +1393,11 @@ will need to be used. 1. The Wallet Provider responsible for the Wallet Solution is registered by a Registrar. As a result, the Wallet Solution enters - the Valid state. This is discussed in [section 6.2.2](#622-wallet-provider-registration-and-notification). + the Valid state. This is discussed in [Section 6.2.2](#622-wallet-provider-registration-and-notification). 2. Under specific conditions, a Registrar may decide to suspend or withdraw a registered Wallet Provider. This implies that the Wallet - Provider is de-registered. This is discussed in [section 6.2.3](#623-wallet-provider-suspension-or-withdrawal). + Provider is de-registered. This is discussed in [Section 6.2.3](#623-wallet-provider-suspension-or-withdrawal). #### 6.2.2 Wallet Provider registration and notification @@ -1416,11 +1416,11 @@ List. During issuance of a PID or an attestation, the PID Provider or the Attestation Provider can use these trust anchors to verify the authenticity of a Wallet Trust Evidence signed by the Wallet Provider, so they can be sure they are dealing with an authentic Wallet Instance -from a trusted Wallet Provider. See [section 6.6.3.2](#6632-wallet-instance-authenticates-the-relying-party-instance) and \[Topic 9\]. +from a trusted Wallet Provider. See [Section 6.6.3.2](#6632-wallet-instance-authenticates-the-relying-party-instance) and \[Topic 9\]. Similarly, when the Wallet Instance presents a PID or an attestation to a Relying Party, the Relying Party can use the Wallet Provider trust anchors to verify the authenticity of a Wallet Instance Attestation -signed by the Wallet Provider; see [section 6.6.3.10](#66310-relying-party-authenticates-the-wallet-instance-and-the-wallet-provider) and \[Topic 38\]. +signed by the Wallet Provider; see [Section 6.6.3.10](#66310-relying-party-authenticates-the-wallet-instance-and-the-wallet-provider) and \[Topic 38\]. More details on the Wallet Provider notification process can be found in \[Topic 31\]. @@ -1442,11 +1442,11 @@ with any Wallet Instance provided by that Wallet Provider. [Section 4.4.4](#444-person-identification-data-pid) presented the lifecycle of a PID Provider: 1. A PID Provider or an Attestation Provider is registered by a - Registrar. This is discussed in [section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification). + Registrar. This is discussed in [Section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification). 2. Under specific conditions, a Registrar may decide to suspend or withdraw a registered PID Provider or Attestation Provider. This is - discussed in [section 6.3.3](#633-pid-provider-or-attestation-provider-suspension-or-withdrawal). + discussed in [Section 6.3.3](#633-pid-provider-or-attestation-provider-suspension-or-withdrawal). #### 6.3.2 PID Provider or Attestation Provider registration and notification @@ -1477,7 +1477,7 @@ Access Certificate Authority (CA) issues one or more access certificates to the PID Provider or to the Attestation Provider. A PID Provider or an Attestation Provider needs such a certificate to authenticate itself towards a Wallet Instance when issuing a PID or an attestation to it, as -described in [section 6.6.2.2](#6622-wallet-instance-authenticates-the-pid-provider-or-attestation-provider). A PID Provider access certificate +described in [Section 6.6.2.2](#6622-wallet-instance-authenticates-the-pid-provider-or-attestation-provider). A PID Provider access certificate indicates that its subject is a PID Provider. Similarly, an Attestation Provider access certificate indicates that its subject is a QEEA Provider, a PuB-EAA Provider or a (non-qualified) EAA Provider. @@ -1565,10 +1565,10 @@ The lifecycle of a Relying Party is described in this paragraph: 1. A Relying Party is registered by a Registrar in the Member State where it resides. Relying Party registration and the Relying Party - Access CA Trusted List are discussed in [section 6.4.2](#642-relying-party-registration). + Access CA Trusted List are discussed in [Section 6.4.2](#642-relying-party-registration). 2. Under specific conditions, a Registrar may decide to de-register a - registered Relying Party. This is discussed in [section 6.4.3](#643-relying-party-de-registration). + registered Relying Party. This is discussed in [Section 6.4.3](#643-relying-party-de-registration). #### 6.4.2 Relying Party registration @@ -1582,7 +1582,7 @@ As a result of successful registration, a Relying Party Access Certificate Authority (CA) issues one or more access certificates to the Relying Party. A Relying Party Instance needs such a certificate to authenticate itself towards Wallet Instances when requesting the -presentation of attributes, as described in [section 6.6.3.2](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance). +presentation of attributes, as described in [Section 6.6.3.2](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance). Subsequently, each Registrar creates a Relying Party Access CA Trusted List containing the trust anchor(s) of all associated Relying Party @@ -1615,21 +1615,21 @@ with Wallet Instances. Section 4.4.3 above presented the lifecycle of a Wallet Instance: 1. A Wallet instance is installed on a device by a User. The required - trust relationships for installation are discussed in [section 6.5.2](#652-wallet-instance-installation) + trust relationships for installation are discussed in [Section 6.5.2](#652-wallet-instance-installation) below. 2. Next, the Wallet Instance is activated by the Wallet Provider and becomes operational. The goals and required trust relationships for - activation are discussed in [section 6.5.3](#653-wallet-instance-activation). + activation are discussed in [Section 6.5.3](#653-wallet-instance-activation). 3. Once in the **Operational** or **Valid** state, the Wallet Instance is managed by the User and the Wallet Provider. This management includes at least revoking the Wallet Instance when necessary. This - is discussed in [section 6.5.4](#654-wallet-instance-management). Management will also include regular + is discussed in [Section 6.5.4](#654-wallet-instance-management). Management will also include regular updates of the Wallet Instance to ensure its continued security and functionality. However, this is not further defined in this chapter. -4. The User may de-install the Wallet Instance; see [section 6.5.5](#655-wallet-instance-de-installation). +4. The User may de-install the Wallet Instance; see [Section 6.5.5](#655-wallet-instance-de-installation). #### 6.5.2 Wallet Instance installation @@ -1717,7 +1717,7 @@ purposes: is fit to receive a PID or an attestation from the Provider. - Moreover, the WTE contains a WTE public key. During the issuance - of a PID or an attestation (see [section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance)), a PID Provider + of a PID or an attestation (see [Section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance)), a PID Provider or Attestation Provider can use this public key to verify that the Wallet Instance is in possession of the corresponding private key. Moreover, at that time, the Wallet Instance will @@ -1741,7 +1741,7 @@ purposes: 4. The Wallet Instance requests the User to set up a User authentication mechanism. User authentication is necessary when (or before) the Wallet Instance asks the User for approval to present - some attributes to a Relying Party, see [section 6.6.3.4](#6634-wallet-instance-obtains-user-approval-for-presenting-attributes). User + some attributes to a Relying Party, see [Section 6.6.3.4](#6634-wallet-instance-obtains-user-approval-for-presenting-attributes). User authentication can be done by the Wallet Instance itself or by the WSCD. The latter is required before the WSCD performs any operations with cryptographic keys belonging to the Wallet Instance or to a PID @@ -1824,7 +1824,7 @@ established: indeed the User that was associated with the Wallet Instance during activation. For this, the Wallet Provider uses the authentication methods established in the User's account during activation, see - [section 6.5.3](#653-wallet-instance-activation). + [Section 6.5.3](#653-wallet-instance-activation). 3. The EUDI Wallet Instance authenticates the EUDI Wallet Provider, meaning that the EUDI Wallet Instance is sure that it is dealing @@ -1866,20 +1866,20 @@ Wallet Instance: 1. Using their Wallet Instance, the User requests the issuance of a PID or an attestation from a PID Provider or an Attestation Provider. The required trust relationships for issuance are discussed in - [section 6.6.2](#662-pid-or-attestation-issuance) below. + [Section 6.6.2](#662-pid-or-attestation-issuance) below. 2. Once the attestation is issued into the Wallet Instance, the User can then present attributes from this attestation to a Relying Party Instance, according to the User\'s decision and depending on successful authentication of the Relying Party. The required trust relationships for presenting PIDs and attestations, including User - approval and Relying Party authentication, are discussed in [section + approval and Relying Party authentication, are discussed in [Section 6.6.3](#663-pid-or-attestation-presentation-to-relying-party). 3. Instead of presenting attributes to a Relying Party, a User can also present them to another User, meaning the Wallet Instance is interacting with another Wallet Instance. This is briefly discussed - in [section 6.6.4](#664-pid-or-attestation-presentation-to-another-wallet-instance). + in [Section 6.6.4](#664-pid-or-attestation-presentation-to-another-wallet-instance). 4. The PID Provider or the Attestation Provider respectively, remains responsible for managing the attestation over its lifetime. @@ -1887,9 +1887,9 @@ Wallet Instance: attestation. The Provider can also remove or revoke the PID or the attestation, possibly based on a request of the User. The required trust relationships for managing PIDs and attestations are discussed - in [section 6.6.5](#665-pid-or-attestation-management). + in [Section 6.6.5](#665-pid-or-attestation-management). -5. Finally, [section 6.6.6](#666-pid-or-attestation-deletion) discusses the scenario that a User decides to +5. Finally, [Section 6.6.6](#666-pid-or-attestation-deletion) discusses the scenario that a User decides to delete the PID or an attestation from their Wallet Instance. #### 6.6.2 PID or attestation issuance @@ -1902,10 +1902,10 @@ issue the PID or an attestation to their Wallet Instance. The following trust relationships are established during issuance: 1. The Wallet Instance authenticates the PID Provider or Attestation - Provider using the certificate referred to in [section 6.3](#63-trust-throughout-a-pid-provider-or-an-attestation-provider-lifecycle). This ensures that + Provider using the certificate referred to in [Section 6.3](#63-trust-throughout-a-pid-provider-or-an-attestation-provider-lifecycle). This ensures that the User can trust that the PID or attestation they are about to receive, is issued by an authenticated PID Provider or - Attestation Provider respectively. See [section 6.6.2.2](#6622-wallet-instance-authenticates-the-pid-provider-or-attestation-provider) below + Attestation Provider respectively. See [Section 6.6.2.2](#6622-wallet-instance-authenticates-the-pid-provider-or-attestation-provider) below describing how this will be done. 2. The PID Provider or Attestation Provider authenticates the User, @@ -1920,15 +1920,15 @@ trust relationships are established during issuance: Provider. 3. The PID Provider or Attestation Provider authenticates and validates - the Wallet Instance, see [section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance) below. + the Wallet Instance, see [Section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance) below. 4. The PID Provider or Attestation Provider verifies that the Wallet Provider did not revoke or suspend the Wallet Instance. This is - described in [section 6.6.2.4](#6624-pid-provider-or-attestation-provider-verifies-that-wallet-instance-is-not-suspended-or-revoked). + described in [Section 6.6.2.4](#6624-pid-provider-or-attestation-provider-verifies-that-wallet-instance-is-not-suspended-or-revoked). 5. Finally, after the PID or attestation is issued to the Wallet Instance, the User may have to activate it before they can use it; - see [section 6.6.2.5](#6625-user-activates-the-pid-or-attestation). + see [Section 6.6.2.5](#6625-user-activates-the-pid-or-attestation). More detailed requirements for the issuance process of PIDs and attestations, for instance regarding the issuance protocol, are included @@ -1939,14 +1939,14 @@ in \[Topic 10\] and \[Topic 23\]. As shown in figure 6, a Wallet Instance downloads the PID Provider Access CA Trusted List(s) and Attestation Provider Access CA Trusted List(s) it needs from the relevant Registrar(s), possibly after having -located them via the Commission common trust infrastructure. See [section +located them via the Commission common trust infrastructure. See [Section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) for more information on these Trusted Lists. Notes: - The Wallet Instance downloads the PID Provider or Attestation Provider **Access CA** Trusted Lists, not the PID Provider or - Attestation Provider Trusted Lists. See [section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) for the + Attestation Provider Trusted Lists. See [Section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) for the difference between these lists. The Wallet Instance needs the Access CA Trusted Lists to authenticate the PID Provider or Attestation Provider. The Wallet Instance does not need to verify the @@ -2090,13 +2090,13 @@ established: optionally have embedded a disclosure policy in the PID or attestation. If such a policy is present for the requested PID or attestation, the Wallet Instance evaluates the disclosure policy and - informs the User about the outcome of this evaluation. See [section + informs the User about the outcome of this evaluation. See [Section 6.6.3.3](#6633-wallet-instance-evaluates-disclosure-policy-embedded-in-attestation-if-present). 3. The User approves or rejects the presentation of the requested attributes, or some of them, for selective disclosure, possibly based on the outcome of the evaluation of the embedded disclosure - policy. User approval is described in [section 6.6.3.4](#6634-wallet-instance-obtains-user-approval-for-presenting-attributes). + policy. User approval is described in [Section 6.6.3.4](#6634-wallet-instance-obtains-user-approval-for-presenting-attributes). Subsequently, after the Wallet Instance presents the selected attributes from the PID or attestation to the Relying Party Instance by sending a @@ -2107,38 +2107,38 @@ following trust relationships are established: of the PID or attestation. This ensures that the Relying Party can trust that the PID or attestation it receives is issued by an authentic Provider and has not been changed. This is described in - [section 6.6.3.5](#6635-relying-party-instance-verifies-the-authenticity-of-the-pid-or-attestation). + [Section 6.6.3.5](#6635-relying-party-instance-verifies-the-authenticity-of-the-pid-or-attestation). 5. The Relying Party verifies that the PID Provider or Attestation Provider did not revoke or suspend the PID or attestation. This is - described in [section 6.6.3.6](#6636-relying-party-verifies-that-the-pid-or-attestation-is-not-revoked). + described in [Section 6.6.3.6](#6636-relying-party-verifies-that-the-pid-or-attestation-is-not-revoked). 6. The Relying Party verifies that the PID Provider or Attestation Provider issued this attestation to the same Wallet Instance that provided it to the Relying Party. In other words, it checks that the attestation was not copied or replayed. This is generally called - device binding, and it is discussed in [section 6.6.3.7](#6637-relying-party-verifies-device-binding) + device binding, and it is discussed in [Section 6.6.3.7](#6637-relying-party-verifies-device-binding) 7. In some use cases, the Relying Party verifies that the person presenting the attestation is the User, meaning the subject of the PID or attestation. This is called User binding. **I**n other use cases, the Relying Party trusts that Wallet Instance and the WSCD - have done this. User binding is discussed in [section 6.6.3.8](#6638-relying-party-verifies-or-trusts-user-binding). + have done this. User binding is discussed in [Section 6.6.3.8](#6638-relying-party-verifies-or-trusts-user-binding). 8. The Relying Party can request attributes from two or more attestations in the same interaction. This is called a **combined presentation of attributes**. If so, the Relying Party verifies that these attestations belong to the same User. This is discussed in - [section 6.6.3.9](#6639-relying-party-verifies-combined-presentation-of-attributes). + [Section 6.6.3.9](#6639-relying-party-verifies-combined-presentation-of-attributes). Either before or after validating the PID or attestation per steps 4 - 8, 9. The Relying Party Instance authenticates the Wallet Instance and the - Wallet Provider; see [section 6.6.3.10](#66310-relying-party-authenticates-the-wallet-instance-and-the-wallet-provider). + Wallet Provider; see [Section 6.6.3.10](#66310-relying-party-authenticates-the-wallet-instance-and-the-wallet-provider). 10. The Relying Party Instance verifies that the Wallet Provider did not - suspend or revoke the Wallet Instance, see [section 6.6.3.11](#66311-relying-party-verifies-that-wallet-instance-is-not-suspended-or-revoked). + suspend or revoke the Wallet Instance, see [Section 6.6.3.11](#66311-relying-party-verifies-that-wallet-instance-is-not-suspended-or-revoked). Finally, after the interaction is over, @@ -2147,7 +2147,7 @@ Finally, after the interaction is over, information logged by the Wallet Instance. Similarly, the Wallet Instance enables the User to request a Relying Party to immediately erase personal data obtained from the Wallet Instance. This is - discussed in [section 6.6.3.12](#66312-wallet-instance-enables-the-user-to-report-suspicious-requests-by-a-relying-party-and-to-request-a-relying-party-to-erase-personal-data). + discussed in [Section 6.6.3.12](#66312-wallet-instance-enables-the-user-to-report-suspicious-requests-by-a-relying-party-and-to-request-a-relying-party-to-erase-personal-data). ##### 6.6.3.2 Wallet Instance authenticates the Relying Party Instance @@ -2177,7 +2177,7 @@ Relying Party authentication process can begin. Note that these actions are not carried out for every presentation, but only once (excluding possible updates). -A) The Relying Party registered itself as described in [section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) +A) The Relying Party registered itself as described in [Section 6.3.2](#632-pid-provider-or-attestation-provider-registration-and-notification) and obtained a Relying Party Instance access certificate. B) The Wallet Instance obtained the trust anchor of the Relying Party @@ -2275,10 +2275,10 @@ proximity flow and remote flow, and including:  A prerequisite for requesting User approval is that the Wallet Instance is sure that the person using the Wallet Instance is in fact the User. -Therefore, the WSCD authenticates the User prior to or during requesting +Therefore, the WSCA authenticates the User prior to or during requesting User approval, on request of the Wallet Instance. To do so, the Wallet Instance uses the User authentication mechanisms set up during Wallet -Instance activation, see [section 6.5.3](#653-wallet-instance-activation). More detailed requirements +Instance activation, see [Section 6.5.3](#653-wallet-instance-activation). More detailed requirements regarding User approval can be found in \[Topic 6\]. ##### 6.6.3.5 Relying Party Instance verifies the authenticity of the PID or attestation @@ -2323,7 +2323,7 @@ Attestation Provider, regardless of the User device it is installed on. In other words, the Relying Party trusts the PID Provider or Attestation Provider to have verified, during PID or attestation issuance, that the User device is fit to receive a PID or attestation, -as described in [section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance). The Relying Party therefore does not +as described in [Section 6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-eudi-wallet-instance). The Relying Party therefore does not assess the technical properties of the User device and WSCD during the attestation presentation process. If the Relying Party were to make its own independent assessment of the security of the User device, there is @@ -2404,7 +2404,7 @@ are not legally allowed to use. The mechanism(s) available for User binding depend on the presentation flow type (proximity or remote, supervised or unsupervised, see also -[section 4.2.3](#423-mobile-apps-and-web-browsers)), and on the attributes issued to the User by the PID +[Section 4.2.3](#423-mobile-apps-and-web-browsers)), and on the attributes issued to the User by the PID Provider or Attestation Provider. In the first place, the Relying Party can always decide to trust the @@ -2418,7 +2418,7 @@ User before allowing the User to present the attributes. Note that: WSCD used by the Wallet Instance. - Using this method implies that Relying Parties also trust device - binding, as described in section [6.5.3](#653-wallet-instance-activation). The Relying Party Instance + binding, as described in Section [6.5.3](#653-wallet-instance-activation). The Relying Party Instance in fact first verifies that the PID or attestation is bound to a WSCD trusted by the PID Provider or Attestation Provider, and then trusts that the Wallet Instance and the WSCD have properly @@ -2474,7 +2474,7 @@ Wallet Instance. When requesting attributes from a Wallet Instance, a Relying Party Instance: - ensures it obtains the WIA from the Wallet Instance. The technical - way this will be done is yet to be determined, see [section 6.5.3](#653-wallet-instance-activation). + way this will be done is yet to be determined, see [Section 6.5.3](#653-wallet-instance-activation). - verifies the signature over the WIA using the Wallet Provider trust anchor obtained from the Wallet Provider Trusted List. @@ -2678,7 +2678,7 @@ neutral. Guidance on certification will allow for various proposed architecture models (including components, security functions, threats, mitigations), evaluation of their individual components (design, implementation, and effectiveness), and related risks as reflected -through a common risk registry defined by the RA (see also [section 7.4](#74-risk-based-approach-and-risk-registry)). +through a common risk registry defined by the RA (see also [Section 7.4](#74-risk-based-approach-and-risk-registry)). The IA will refer to standards, and where available, relevant European CSA schemes must be used. Currently, only the EUCC scheme for the @@ -2706,7 +2706,7 @@ First, the RA aims to identify initial security and privacy threats of assets which must be protected against the identified threats (critical, non-critical). The risks will provide input to a common risk registry, listing the minimum set of risks that should be addressed by -Member States' implementations (see also [section 7.4](#74-risk-based-approach-and-risk-registry)). This common risk registry will serve as input to the +Member States' implementations (see also [Section 7.4](#74-risk-based-approach-and-risk-registry)). This common risk registry will serve as input to the IA, and later on to the detailed definition of privacy and security requirements to mitigate identified threats, at the relevant Level of Assurance. diff --git a/docs/index.md b/docs/index.md index a6065b7..f3f42fc 100644 --- a/docs/index.md +++ b/docs/index.md @@ -19,7 +19,7 @@ in eIDAS by improving the effectiveness of the framework and extending its benefits to the private sector. Member States will offer citizens and businesses digital wallets that will be able to link various aspects of their national digital identities. These may be -provided by public authorities or the private sector, if they are recognized by +provided by public authorities or the private sector, if they are recognised by the Member States. The EU Digital Identity Wallet will be: @@ -52,7 +52,7 @@ and private sector parties. This repository contains the "[Architecture and Reference Framework](./arf.md)" (hereinafter the [ARF](./arf.md)). -The current **authoritative version** is tagged as [realease/tag in this +The current **authoritative version** is tagged as [release/tag in this repository](https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework/releases). ## Contributing