Typo fixes 2025-03-11 (#429)

joelposti · web-flow · commit daf923b98c82 · 2025-03-19T11:48:23.000+01:00
* Removed extraneous ‘as a’.

* Removed extraneous ‘follows’.

* Added missing asterisks.

* Replaced equal sign with a dash.

* Fixed erroneous CIR 2024/2977 reference.

* Added missing ‘is’.

* Replaced link to ‘6.3.2 PID Provider or Attestation Provider registration and notification’ with link to ‘6.4.2 Relying Party registration’. The text surrounding the link talks about relying party registration.
diff --git a/docs/annexes/annex-3/annex-3.01-pid-rulebook.md b/docs/annexes/annex-3/annex-3.01-pid-rulebook.md
@@ -14,7 +14,7 @@ and is part of the Architecture Reference Framework (ARF) v1.5.0. It specifies
 how the mandatory and optional person identification data for the natural
 person, as defined in Tables 1 and 2 in the Annex of the Commission Implementing
 Regulation on PID and EAA [CIR 2024/2977], as well as the metadata specified in
-Table 5 of that CIR, will be encoded as a within the EUDI Wallet ecosystem.
+Table 5 of that CIR, will be encoded within the EUDI Wallet ecosystem.
 Additionally, this document specifies further optional PID attributes that are
 not included in the CIR.
 
@@ -71,8 +71,8 @@ ecosystem, regardless of the encoding used.
 | **Index** | **Requirement specification** |
 |-----------|--------------|
 | PID_01 | A PID Provider SHALL issue any PID in both the format specified in ISO/IEC 18013-5 [ISO/IEC 18013-5] and the format specified in [SD-JWT VC]. *Note: CIR 2024/2977 mentions the W3C Verifiable Credentials Data Model v1.1 [W3C VCDM v1.1] instead of [SD-JWT VC]. However, W3C VCDM is not a complete specification of an attestation format. In particular, it does not specify a specific proof method to be used. Without additional specification, it is therefore impossible to implement a PID based on [W3C VCDM v1.1]. This Rulebook considers [SD-JWT VC] to essentially be such an additional specification.* |
-| PID_02 | PID Providers SHALL use the attestation type “eu.europa.ec.eudi.pid.1” for both ISO/IEC 18013-5-compliant and SD-JWT VC-compliant PIDs. *Notes: - This identifier follows uses the general format [Reverse Domain].[Domain Specific Extension]. Since the European Commission controls the domain ec.europa.eu, this attestation type identifier will not collide with any attestation type identifiers defined by other organisations in other Attestation Rulebooks. - The Commission may use the version number “1” in this identifier to distinguish between the first version of the PID, defined in this document, and any future version, which will then have an incremented version number.* |
-| PID_03 | A PID Provider SHALL ensure that all of the mandatory attributes listed in [Section 3.2](#32-mandatory-attributes-specified-in-cir-20242977) are present in any PID it issues to a Wallet Unit. *Notes: = When requesting PID attributes from a Wallet Unit, a Relying Party is not necessarily required to request all mandatory attributes.- A User is allowed to refuse to present a mandatory attribute, if it is requested by a Relying Party. |
+| PID_02 | PID Providers SHALL use the attestation type “eu.europa.ec.eudi.pid.1” for both ISO/IEC 18013-5-compliant and SD-JWT VC-compliant PIDs. *Notes: - This identifier uses the general format [Reverse Domain].[Domain Specific Extension]. Since the European Commission controls the domain ec.europa.eu, this attestation type identifier will not collide with any attestation type identifiers defined by other organisations in other Attestation Rulebooks. - The Commission may use the version number “1” in this identifier to distinguish between the first version of the PID, defined in this document, and any future version, which will then have an incremented version number.* |
+| PID_03 | A PID Provider SHALL ensure that all of the mandatory attributes listed in [Section 3.2](#32-mandatory-attributes-specified-in-cir-20242977) are present in any PID it issues to a Wallet Unit. *Notes: - When requesting PID attributes from a Wallet Unit, a Relying Party is not necessarily required to request all mandatory attributes. - A User is allowed to refuse to present a mandatory attribute, if it is requested by a Relying Party.* |
 
 ## 3 PID attributes and metadata
 
@@ -170,11 +170,11 @@ ecosystem that are compliant with [ISO/IEC 18013-5].
 | PID_ISO_01 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL use the value “eu.europa.ec.eudi.pid.1” for the identifier of the namespace for the PID attributes specified in [Section 4.2](#42-encoding-of-pid-attributes-and-metadata). *Notes: - The version number “1” allows for future extension(s) or change(s) of the ISO/IEC 18013-5-compliant PID attributes. - This namespace has the same value as the attestation type specified in requirement PID_02. This is allowed according to ISO/IEC 18013-5.* |
 | PID_ISO_02 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider MAY include attributes that are not defined in this document. If so, these attributes SHALL be defined within a domestic PID namespace as meant in requirement ARB_10 in Annex 2. The PID Provider SHALL generate the identifier for this domestic PID namespace by appending the applicable ISO 3166-1 alpha-2 country code or the ISO 3166-2 region code, separated by a period, to the PID namespace specified in PID_ISO_01, excluding the version number. The PID Provider MAY include a version number in the domestic PID namespace identifier. *Note: For example, the identifier of the first domestic PID namespace for Germany could be “eu.europa.ec.eudi.pid.de.1”.* |
 | PID_ISO_03 | A PID Provider that defines a domestic namespace SHALL publish the namespace, including all attribute identifiers, their definition, presence and encoding format, in an Attestation Rulebook complying with all applicable requirements in Annex 2 [Topic 12]. |
-| PID_ISO_04 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL include both the attributes and the metadata specified in CIR 2024/799 in the PID as (issuer-signed or device-signed) data elements. *Note: This implies that technically speaking, there is no difference between these attributes and metadata.* |
+| PID_ISO_04 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL include both the attributes and the metadata specified in CIR 2024/2977 in the PID as (issuer-signed or device-signed) data elements. *Note: This implies that technically speaking, there is no difference between these attributes and metadata.* |
 | PID_ISO_05 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL encode each attribute or metadata in the PID as specified in the third column of the tables in [Section 4.2.1](#421-overview). |
 | PID_ISO_06 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL encode each attribute or metadata in the PID in Concise Binary Object Representation (CBOR) according to [RFC 8949]. |
 | PID_ISO_07 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that each PID contains at most one attribute with the same attribute identifier. |
-| PID_ISO_08 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that the value of all attributes and metadata in the PID is valid at the value of the timestamp in the validFrom element in the MSO, see [ISO/IEC 18013-5] clause 9.1.2.4. *Note: The value of the age_over_18, age_over_NN, or age_in_years attributes, if present, changes whenever the User to whom the person identification data relates has a relevant birthday. The value of many other attributes will also change over time. |
+| PID_ISO_08 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that the value of all attributes and metadata in the PID is valid at the value of the timestamp in the validFrom element in the MSO, see [ISO/IEC 18013-5] clause 9.1.2.4. *Note: The value of the age_over_18, age_over_NN, or age_in_years attributes, if present, changes whenever the User to whom the person identification data relates has a relevant birthday. The value of many other attributes will also change over time.* |
 | PID_ISO_09 | When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that the issuance_date attribute, if present, is not later than the validFrom element in the MSO, see [ISO/IEC 18013-5] clause 9.1.2.4. |
 
 ### 4.2 Encoding of PID attributes and metadata
diff --git a/docs/annexes/annex-3/annex-3.02-mDL-rulebook.md b/docs/annexes/annex-3/annex-3.02-mDL-rulebook.md
@@ -13,7 +13,7 @@ final.*
 
 ## 1 Introduction
 
-This document is the mobile driving licence (mDL) Rulebook. It part of ARF
+This document is the mobile driving licence (mDL) Rulebook. It is part of ARF
 v1.5.0. It contains requirements specific to mDL attestations with the EUDI
 Wallet ecosystem.
 
diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md
@@ -2904,7 +2904,7 @@ 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)
+[Section 6.4.2](##642-relying-party-registration)
 and obtained a Relying Party Instance access certificate.
 
 B) The Wallet Unit obtained the trust anchor of the Relying Party Instance
