From a4358fb28487b835fc9bf42ad2a9e6cbca2c01ef Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 14:57:40 +0200 Subject: [PATCH 01/16] Replaced EUDIW with EUDI Wallet. --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index dcdac44..2597eda 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1110,7 +1110,7 @@ app or application the user is installing) is genuine, authentic and does not contain any malware or other threats. 2. The User SHALL be able to trust that the PID Provider will issue the PID into an instance of a EUDI Wallet Solution. -3. The User SHALL trust the EUDIW solution. This means that the User +3. The User SHALL trust the EUDI Wallet solution. This means that the User trusts the App store and the App publisher. The next sections discuss these trust relationships. From badd7d46e5812bd0d2eb055abe601e945c6f0e34 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 14:58:10 +0200 Subject: [PATCH 02/16] =?UTF-8?q?Replaced=20=E2=80=98App=20store=E2=80=99?= =?UTF-8?q?=20and=20=E2=80=98App=20publisher=E2=80=99=20with=20lowercased?= =?UTF-8?q?=20=E2=80=98app=20store=E2=80=99=20and=20=E2=80=98app=20publish?= =?UTF-8?q?er=E2=80=99=20because=20they=20are=20not=20defined=20terms.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index 2597eda..dcd3a8c 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1111,7 +1111,7 @@ not contain any malware or other threats. 2. The User SHALL be able to trust that the PID Provider will issue the PID into an instance of a EUDI Wallet Solution. 3. The User SHALL trust the EUDI Wallet solution. This means that the User -trusts the App store and the App publisher. +trusts the app store and the app publisher. The next sections discuss these trust relationships. From 90c3c37455c228bae2e691905eb39949d6bdf36a Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 15:01:32 +0200 Subject: [PATCH 03/16] =?UTF-8?q?Capitalised=20=E2=80=98attestation?= =?UTF-8?q?=E2=80=99=20in=20=E2=80=98EUDI=20Wallet=20Instance=20Attestatio?= =?UTF-8?q?n=E2=80=99=20because=20it=20should=20be=20a=20defined=20term.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/annexes/annex-06-pid-rulebook.md | 6 +++--- docs/arf.md | 16 ++++++++-------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/annexes/annex-06-pid-rulebook.md b/docs/annexes/annex-06-pid-rulebook.md index 4f0cdb4..772628c 100644 --- a/docs/annexes/annex-06-pid-rulebook.md +++ b/docs/annexes/annex-06-pid-rulebook.md @@ -27,8 +27,8 @@ This PID Rule Book contains the following topics: also describes how Member States can specify any possible national attributes. Two encodings for these attributes are specified, one compliant with \[ISO18013-5\], the other compliant with \[SD-JWT\]. -* Chapter 3 specifies the Wallet Instance attestation schema, which - describes the same information for the Wallet Instance attestation +* Chapter 3 specifies the Wallet Instance Attestation schema, which + describes the same information for the Wallet Instance Attestation signed by the Wallet Provider for each Wallet Instance. This information will be moved to another document in the future. * Chapter 4 specifies details about the trust infrastructure necessary @@ -501,7 +501,7 @@ Instance. At the discretion of the PID Provider, domestic data elements (see section 2.2.2) MAY be released in either a VP Token or an ID Token. -## 3 Wallet Instance attestation attribute schema +## 3 Wallet Instance Attestation attribute schema > NOTE: the information in this chapter does not pertain to the PID > directly. It will be included in a separate Wallet Attestation > Rulebook, to be detailed in a future version of ARF. diff --git a/docs/arf.md b/docs/arf.md index dcd3a8c..7b072db 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -827,7 +827,7 @@ Instance, which may involve: * The EUDI Wallet Provider updating the EUDI Wallet Instance, * The EUDI Wallet Provider revoking the EUDI Wallet Instance, possibly at the User's request. Revocation of the Wallet Instance MAY be - accomplished by revoking the Wallet Instance attestation (refer to + accomplished by revoking the Wallet Instance Attestation (refer to section 6.3.4.2), * The User uninstalling the EUDI Wallet Instance. @@ -1145,20 +1145,20 @@ purposes: * The EUDI Wallet Provider issues a EUDI Wallet Instance Attestation to the EUDI Wallet Instance. This attestation contains data about the EUDI Wallet Provider, the EUDI Wallet Solution, the EUDI Wallet Instance, - the device and the WSCD. The EUDI Wallet Instance attestation has the + the device and the WSCD. The EUDI Wallet Instance Attestation has the same technical format and content as other attestations. This implies that the attestation will contain a Wallet Instance public key. The EUDI Wallet Instance key pair is generated by the EUDI Wallet Instance during activation, using the WSCD present in, or connected to, the - User's device. The EUDI Wallet Instance attestation also contains + User's device. The EUDI Wallet Instance Attestation also contains information that allows a Provider or Relying Party to verify that the EUDI Wallet Provider did not revoke the EUDI Wallet Instance - attestation, and hence the EUDI Wallet Instance itself. + Attestation, and hence the EUDI Wallet Instance itself. * The EUDI Wallet Provider locally associates the EUDI Wallet Instance with a particular User, including on-device or backend-based User authentication methods that will be used by the EUDI Wallet Instance to authenticate the User towards the EUDI Wallet Provider only. The User - details SHALL NOT be included in the EUDI Wallet Instance attestation. + details SHALL NOT be included in the EUDI Wallet Instance Attestation. * The EUDI Wallet Provider sets up a User account. This User account is needed if the User wants to interact with the EUDI Wallet Provider without using their EUDI Wallet Instance. An example of this is a @@ -1177,7 +1177,7 @@ purposes: the User, the User's device, and the EUDI Wallet Instance (if any), SHALL be stored and used only in the EUDI Wallet Provider back office. The EUDI Wallet Provider SHALL NOT put this information in - the EUDI Wallet Instance attestation. + the EUDI Wallet Instance Attestation. For successful EUDI Wallet Instance activation, the following trust relations need to exist: @@ -1326,7 +1326,7 @@ current version of this document: * A Relying Party is assumed to trust the attestation Provider to have verified the technical properties of the EUDI Wallet Instance and the User's device and WSCD (as documented in the Wallet Instance - attestation) at the time it issued the attestation. Consequently, the + Attestation) at the time it issued the attestation. Consequently, the Relying Party does not verify these technical properties during the attestation release process. To elaborate: A Relying Party typically has a list of attestations that it accepts for a certain use case. For @@ -1514,7 +1514,7 @@ Throughout its lifetime, an attestation needs to be managed by the Provider. This means that for the purposes of this Trust Model, attestation management has similarities to the part of EUDI Wallet Instance management that involves the EUDI Wallet Provider as the -Provider of a EUDI Wallet Instance attestation, which was already +Provider of a EUDI Wallet Instance Attestation, which was already discussed in section 6.2.3. #### 6.3.4 Attestation revocation From 255bf0361c0e985e5db58172328741365fd1a452 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 15:04:05 +0200 Subject: [PATCH 04/16] Removed redundant apostrophe. --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index 7b072db..116029d 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1125,7 +1125,7 @@ To be done. ##### 6.2.2.1 Required trust relationships[^15] -After its' installation, a new EUDI Wallet Instance will need to be +After its installation, a new EUDI Wallet Instance will need to be activated by the Wallet Provider. Activation has at least the following purposes: From 6556b330f4f5b7afb6c32db498e0cc681ce4bb1d Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 15:15:46 +0200 Subject: [PATCH 05/16] =?UTF-8?q?Settled=20inconsistent=20use=20of=20?= =?UTF-8?q?=E2=80=98a=20EUDI=20Wallet=E2=80=99=20and=20=E2=80=98an=20EUDI?= =?UTF-8?q?=20Wallet=E2=80=99=20in=20favour=20of=20the=20latter=20because?= =?UTF-8?q?=20that=20was=20more=20prevalent=20ortography=20in=20the=20docu?= =?UTF-8?q?ments.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/annexes/annex-07-mdl-rulebook.md | 2 +- docs/annexes/annex-08-design-guide.md | 2 +- docs/arf.md | 34 +++++++++++++-------------- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/annexes/annex-07-mdl-rulebook.md b/docs/annexes/annex-07-mdl-rulebook.md index b48edd5..a578361 100644 --- a/docs/annexes/annex-07-mdl-rulebook.md +++ b/docs/annexes/annex-07-mdl-rulebook.md @@ -54,7 +54,7 @@ However, mobile driving licenses are legally specified in the proposed EC Regulation 2023\_127 (4^th^ Driving License Regulation). This Regulation specifies that mDLs shall comply with the ISO/IEC 18013-5 standard. It does not mention any other standards, in particular not -\[SD JWT\]. Consequently, mDLs issued to a EUDI Wallet instance shall +\[SD JWT\]. Consequently, mDLs issued to an EUDI Wallet instance shall not be implemented as \[SD JWT\]-compliant document. This document therefore specified only an ISO/IEC 18013-5 compliant encoding. diff --git a/docs/annexes/annex-08-design-guide.md b/docs/annexes/annex-08-design-guide.md index 3122cc0..6fbf387 100644 --- a/docs/annexes/annex-08-design-guide.md +++ b/docs/annexes/annex-08-design-guide.md @@ -599,7 +599,7 @@ boundaries of this document are set to common principles that shall be applicable to all national implementations. These shall be considered as recommendations to ensure a similar user experience across the different national implementations. By taking a collaborative approach and -continuously improving upon this document, the aim is to create a EUDI +continuously improving upon this document, the aim is to create an EUDI Wallet Design Guide that assists in the national implementations, while at the same time meets the user expectations. We encourage stakeholders to review this EUDI Wallet Design Guide document thoroughly and kindly diff --git a/docs/arf.md b/docs/arf.md index 116029d..b44c83c 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -656,7 +656,7 @@ bodies designated by Member States[^12]. QTSPs SHALL be audited regularly by Conformity Assessment Bodies (CABs). CABs are accredited by a national accreditation body according to Regulation 765/2008 as responsible for carrying out assessments on which Member States will have to rely before -issuing a EUDI Wallet or providing the qualified status to a Trust +issuing an EUDI Wallet or providing the qualified status to a Trust Service Provider. The standards and schemes used by CABs to fulfil their tasks to certify EUDI Wallets are specified further in the Toolbox process. @@ -739,8 +739,8 @@ ARF.* Figure 2 below distinguishes the concepts of EUDI Wallet Solution and EUDI Wallet Instance. An EUDI Wallet Solution is the entire product -and/or service provided by a EUDI Wallet Provider. A EUDI Wallet -Instance is a personal instance of a EUDI Wallet Solution that belongs +and/or service provided by an EUDI Wallet Provider. An EUDI Wallet +Instance is a personal instance of an EUDI Wallet Solution that belongs to and is controlled by a User. ![Figure 2: Simplified EUDI Wallet Object Model](media/image2.png) @@ -749,7 +749,7 @@ to and is controlled by a User. *Figure 2: Simplified EUDI Wallet Object Model* This definition is not prescriptive of form factor, hence depending on -the implementation a EUDI Wallet Instance may consist of a single mobile +the implementation an EUDI Wallet Instance may consist of a single mobile app, or a set of local and remote components available to a specific User. @@ -760,7 +760,7 @@ the scope of this description we refer subsequently only to PID. The text of this section applied to PID applies mutatis mutandis to (Q)EAA. PID in the context of the EUDI Wallet begins its lifecycle when being -issued to a EUDI Wallet Instance. Please note that this means that the +issued to an EUDI Wallet Instance. Please note that this means that the management of attributes in the Authentic Source (adhering to national structures and attribute definitions) is outside of the scope of the ARF. @@ -788,7 +788,7 @@ name change), the PID Provider SHALL always issue a new PID. An EUDI Wallet Solution has a state of its own, as defined by Article 10a of the Regulation. The state of the Solution affects the state of all EUDI Wallet Instances of that EUDI Wallet Solution. The -**Candidate** state is the first state of a EUDI Wallet Solution. This +**Candidate** state is the first state of an EUDI Wallet Solution. This means it is fully implemented and the EUDI Wallet Provider requests the solution to be certified as EUDI Wallet. @@ -1028,7 +1028,7 @@ as annexes to this document. ## 6 Trust Model ### 6.1 Overview and scope -The Trust Model describes, for all interactions in the lifecycle of a +The Trust Model describes, for all interactions in the lifecycle of an EUDI Wallet Instance and an attestation, which trust relationships SHALL exist between the interacting parties to enable these interactions. @@ -1097,7 +1097,7 @@ authorization of other parties in the ecosystem, parties SHALL also be able to trust that the communication with such parties is confidential. Measures to ensure this are not explicitly discussed in this document. -### 6.2 Trust throughout a EUDI Wallet Instance lifecycle +### 6.2 Trust throughout an EUDI Wallet Instance lifecycle #### 6.2.1 Wallet Instance installation @@ -1109,7 +1109,7 @@ the following trust relationships SHALL exist: app or application the user is installing) is genuine, authentic and does not contain any malware or other threats. 2. The User SHALL be able to trust that the PID Provider will issue the -PID into an instance of a EUDI Wallet Solution. +PID into an instance of an EUDI Wallet Solution. 3. The User SHALL trust the EUDI Wallet solution. This means that the User trusts the app store and the app publisher. @@ -1142,7 +1142,7 @@ purposes: technologies supported by the device and the characteristics of the WSCD used by the device to securely store cryptographic keys and data associated with the EUDI Wallet Instance and the attestations. -* The EUDI Wallet Provider issues a EUDI Wallet Instance Attestation to +* The EUDI Wallet Provider issues an EUDI Wallet Instance Attestation to the EUDI Wallet Instance. This attestation contains data about the EUDI Wallet Provider, the EUDI Wallet Solution, the EUDI Wallet Instance, the device and the WSCD. The EUDI Wallet Instance Attestation has the @@ -1162,7 +1162,7 @@ purposes: * The EUDI Wallet Provider sets up a User account. This User account is needed if the User wants to interact with the EUDI Wallet Provider without using their EUDI Wallet Instance. An example of this is a - request to revoke a EUDI Wallet Instance in case the User's device is + request to revoke an EUDI Wallet Instance in case the User's device is lost or stolen. EUDI Wallet Providers MAY also offer other instance-related services through this User account. Please note the following: @@ -1202,7 +1202,7 @@ To be done. ##### 6.2.3.1 Required trust relationships Starting from EUDI Wallet Instance activation and throughout its -lifetime, a EUDI Wallet Instance SHALL be managed by the EUDI Wallet +lifetime, an EUDI Wallet Instance SHALL be managed by the EUDI Wallet Provider. Management actions could be initiated by the following entities. @@ -1235,11 +1235,11 @@ For this, the following trust relations need to exist: The next sections discuss these trust relationships. ##### 6.2.3.2 EUDI Wallet Instance trust in the Wallet Provider -Section 6.2.2.2. describes how a EUDI Wallet Instance can trust a Wallet +Section 6.2.2.2. describes how an EUDI Wallet Instance can trust a Wallet Provider. ##### 6.2.3.3 EUDI Wallet provider trust in the EUDI Wallet Instance -Section 6.2.3.3. describes how a EUDI Wallet Provider can trust a Wallet +Section 6.2.3.3. describes how an EUDI Wallet Provider can trust a Wallet Instance. ##### 6.2.3.4 User trust in the EUDI Wallet Provider @@ -1448,7 +1448,7 @@ The Relying Party SHALL be able to trust that an attestation it receives was not The Relying Party can trust that this is the case if the EUDI Wallet Instance signs some contextual information with the private key of the attestation. This information SHALL include a random number generated by the Relying Party. To verify this signature, the Relying Party needs to receive the public key of the attestation, which SHALL be signed (directly or indirectly) by the Provider of the attestation. By signing the public key, the Provider certifies that the public key indeed belongs to the attestation. The Relying Party SHALL additionally verify that the Wallet Instance is in possession of the corresponding private key; the Relying Party does so by verifying the signature over the random number generated by the Relying Party. -Note that a EUDI Wallet Instance can contain multiple attestations, originating from multiple Providers. For each attestation, the EUDI Wallet Instance has access to an attestation private key, which is stored in the WSCD in (or connected to) the User's device. As discussed in section 6.2.2, the EUDI Wallet Instance also contains a EUDI Wallet Instance private key. Depending on the attestation requested by the 6.3.2.4, the EUDI Wallet Instance SHALL use the correct private key for signing the random number generated by the Relying Party. +Note that an EUDI Wallet Instance can contain multiple attestations, originating from multiple Providers. For each attestation, the EUDI Wallet Instance has access to an attestation private key, which is stored in the WSCD in (or connected to) the User's device. As discussed in section 6.2.2, the EUDI Wallet Instance also contains an EUDI Wallet Instance private key. Depending on the attestation requested by the 6.3.2.4, the EUDI Wallet Instance SHALL use the correct private key for signing the random number generated by the Relying Party. \[ISO/IEC 18013-5\] specifies a mechanism for this, called mdoc authentication. The EUDI Wallet Instance signs contextual information (called the SessionTranscript), which includes a nonce from the Relying Party, namely its ephemeral public key for session encryption. The standard specifies which algorithms can be used for signing and how the attestation public key is incorporated in the MSO. @@ -1514,7 +1514,7 @@ Throughout its lifetime, an attestation needs to be managed by the Provider. This means that for the purposes of this Trust Model, attestation management has similarities to the part of EUDI Wallet Instance management that involves the EUDI Wallet Provider as the -Provider of a EUDI Wallet Instance Attestation, which was already +Provider of an EUDI Wallet Instance Attestation, which was already discussed in section 6.2.3. #### 6.3.4 Attestation revocation @@ -2484,7 +2484,7 @@ decision to release an attribute to the Relying Party requesting it. Under no circumstances User approval to releasing data from their EUDI Wallet Instance SHOULD be construed as lawful grounds for the processing of personal data by the Relying Party or any other party. Relying Party -or any party requesting or processing personal data from a EUDI Wallet +or any party requesting or processing personal data from an EUDI Wallet Instance SHALL ensure that they have grounds for lawful processing that data, according to Article 6 of the GDPR. From 7670403949d9003f70b33d74ec207ff89444fb20 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 15:27:02 +0200 Subject: [PATCH 06/16] =?UTF-8?q?Capitalised=20=E2=80=98instance=E2=80=99?= =?UTF-8?q?=20in=20=E2=80=98Wallet=20Instance=E2=80=99=20because=20it=20is?= =?UTF-8?q?=20a=20defined=20term.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/annexes/annex-07-mdl-rulebook.md | 2 +- docs/arf.md | 6 +++--- docs/media/image7.svg | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/annexes/annex-07-mdl-rulebook.md b/docs/annexes/annex-07-mdl-rulebook.md index a578361..ffd2cfd 100644 --- a/docs/annexes/annex-07-mdl-rulebook.md +++ b/docs/annexes/annex-07-mdl-rulebook.md @@ -54,7 +54,7 @@ However, mobile driving licenses are legally specified in the proposed EC Regulation 2023\_127 (4^th^ Driving License Regulation). This Regulation specifies that mDLs shall comply with the ISO/IEC 18013-5 standard. It does not mention any other standards, in particular not -\[SD JWT\]. Consequently, mDLs issued to an EUDI Wallet instance shall +\[SD JWT\]. Consequently, mDLs issued to an EUDI Wallet Instance shall not be implemented as \[SD JWT\]-compliant document. This document therefore specified only an ISO/IEC 18013-5 compliant encoding. diff --git a/docs/arf.md b/docs/arf.md index b44c83c..4f10d82 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -485,10 +485,10 @@ detailed in the following sections. 14. *National Accreditation Bodies* #### 4.1.1 Users of EUDI Wallets -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 or EAA about themselves, including to prove their identity. Users can create Qualified Electronic Signatures and Seals -(QES) using an EUDI Wallet instance. +(QES) using an EUDI Wallet Instance. Who can be a User of an EUDI Wallet depends on national law. The use of an EUDI Wallet by citizens is not mandatory under the legislative @@ -1317,7 +1317,7 @@ current version of this document: trusted by Relying Parties are those that are signed by a trusted attestation Provider. The only potential exception may be a pseudonym for the User. If the value of a pseudonym attribute is assigned by the - User or generated by the Wallet instance, it MAY be signed by the EUDI + User or generated by the Wallet Instance, it MAY be signed by the EUDI Wallet Instance rather than the Provider. If so, a Relying Party using such a pseudonym SHALL accept the associated risks or mitigate it in an out-of-band manner. These risks may include the possibility of fake diff --git a/docs/media/image7.svg b/docs/media/image7.svg index 6be8e19..6210b4e 100644 --- a/docs/media/image7.svg +++ b/docs/media/image7.svg @@ -60,4 +60,4 @@ font-style: italic; font-weight: 700; } -* {-webkit-font-smoothing: auto; -moz-osx-font-smoothing: auto;}@media print { svg { width: 100%; height: 100%; } }OpenID4VCIW3C VCJSON-LD + LD-ProofsISO/IEC 18013-5:2021CBOR + MSOType 2 configurationW3C VCJSON+JWT(SD-JWT)W3C VCJSON + JWT(SD-JWT)ISO/IEC 18013-5:2021CBOR + MSO Type 1 ConfigurationThe Wallet Solution MUST support both formatsData models & formatsCryptographic keys management system MUST store keys in one of these places:Secure Element / Trusted Execution EnvironmentExternal device ( Smart Cards )Remote backend ( HSM )Attestation exchange protocolIssuance protocolsEUDI Wallet instanceother optional protocolsRelying partyRemote flowOpenID4VPSIOPv2Proximity flowISO/IEC 18013-5Issuerother optional protocols \ No newline at end of file +* {-webkit-font-smoothing: auto; -moz-osx-font-smoothing: auto;}@media print { svg { width: 100%; height: 100%; } }OpenID4VCIW3C VCJSON-LD + LD-ProofsISO/IEC 18013-5:2021CBOR + MSOType 2 configurationW3C VCJSON+JWT(SD-JWT)W3C VCJSON + JWT(SD-JWT)ISO/IEC 18013-5:2021CBOR + MSO Type 1 ConfigurationThe Wallet Solution MUST support both formatsData models & formatsCryptographic keys management system MUST store keys in one of these places:Secure Element / Trusted Execution EnvironmentExternal device ( Smart Cards )Remote backend ( HSM )Attestation exchange protocolIssuance protocolsEUDI Wallet Instanceother optional protocolsRelying partyRemote flowOpenID4VPSIOPv2Proximity flowISO/IEC 18013-5Issuerother optional protocols From 13dc141830cf1a2123688f8f710589fc95d7d896 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 15:43:41 +0200 Subject: [PATCH 07/16] =?UTF-8?q?Capitalised=20certain=20instances=20of=20?= =?UTF-8?q?the=20words=20=E2=80=98provider=E2=80=99=20and=20=E2=80=98provi?= =?UTF-8?q?ders=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index 4f10d82..dab02ad 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -209,7 +209,7 @@ down in Annex V. - eIDAS Regulation amendment proposal -Qualified Electronic Attestations of Attributes (QEAA) provider* +Qualified Electronic Attestations of Attributes (QEAA) Provider*

(Qualified) Trust Service Provider issuing (Q)EAA. Note: there may be multiple (Q)EAA Providers. @@ -417,7 +417,7 @@ ePrescriptions, etc. #### Educational credentials and professional qualifications Providing documents for qualification recognition procedures can be costly and time-consuming for end Users, Relying Parties such as companies -and employers, and (Q)EAA providers such as education and training +and employers, and (Q)EAA Providers such as education and training providers or other academic institutions. For example, digital diploma attestations could be presented cross-border in a verifiable, trusted, and consumable format to another education or training institution or a @@ -543,11 +543,11 @@ verified in a trustworthy manner. Such roles are: - EUDI Wallet Providers - Person Identification Data Providers -- Qualified Electronic Attestation of Attributes (QEAA) providers -- Qualified certificate for electronic signature/seal (QC) providers +- Qualified Electronic Attestation of Attributes (QEAA) Providers +- Qualified certificate for electronic signature/seal (QC) Providers - Relying Parties -- Non-qualified Electronic Attestation of Attributes (EAA) providers -- Non-qualified certificate for electronic signature/seal providers +- Non-qualified Electronic Attestation of Attributes (EAA) Providers +- Non-qualified certificate for electronic signature/seal Providers - Providers of other Trust Services - Catalogues of attributes and schemes for the attestations of attribute providers @@ -586,7 +586,7 @@ although they may also rely on qualified Electronic Attestation of Attributes Providers. For EAA to be used, TSPs offer Users a way to request and obtain EAA, meaning they need to technically comply with EUDI Wallet interface specifications. Depending on the domain rules, EAA -providers may provide validity information about EAA, without having an +Providers may provide validity information about EAA, without having an ability to receive any information about the use of the EAA. The terms and conditions of issuing EAAs and related services are subject to sectoral rules. @@ -1238,7 +1238,7 @@ The next sections discuss these trust relationships. Section 6.2.2.2. describes how an EUDI Wallet Instance can trust a Wallet Provider. -##### 6.2.3.3 EUDI Wallet provider trust in the EUDI Wallet Instance +##### 6.2.3.3 EUDI Wallet Provider trust in the EUDI Wallet Instance Section 6.2.3.3. describes how an EUDI Wallet Provider can trust a Wallet Instance. @@ -1264,7 +1264,7 @@ Wallet Instance, the following trust relationships SHALL exist: be able to determine the value of the attributes that the Provider will attest to. For instance, a PID Provider SHALL ensure it provides the correct family name and date of birth to the Wallet Instance. - Please note that the method by which the provider performs user + Please note that the method by which the Provider performs user identification and authentication is out of scope of this document. 3. The Provider SHALL be able to trust the EUDI Wallet Provider. 4. The Provider SHALL be able to trust the EUDI Wallet Instance. This @@ -1414,7 +1414,7 @@ This means that a Relying Party can determine itself which Providers they want to recognize, except if there is a legal requirement that the attestations of certain Providers SHALL be accepted. That is generally the case for PID Providers and QEAA Providers. However, this does not -mean that the above process is not necessary for these providers. +mean that the above process is not necessary for these Providers. ##### 6.3.2.3 Relying Party trusts the authenticity of the attestation @@ -2076,7 +2076,7 @@ manufacturer, and version)

Relying Party interface

-

EUDI Wallet interface to (Q)TSP, (Q)EAA providers, Member States +

EUDI Wallet interface to (Q)TSP, (Q)EAA Providers, Member States Infrastructures, National e-ID, Relying Parties, and other sources of EEAs

Communication channels (online/offline) between the EUDI Wallet and From 060d9366dc0f44b50497a5352dcaaeb70a66f70d Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Mon, 11 Mar 2024 16:22:00 +0200 Subject: [PATCH 08/16] =?UTF-8?q?Replaced=20=E2=80=98an=20Provider's?= =?UTF-8?q?=E2=80=99=20with=20=E2=80=98a=20Provider's=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index dab02ad..bf21ce6 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1381,7 +1381,7 @@ For more valuable attestations, or for attestations for which Providers and Relying Parties do not know each other, a trusted list of Providers is a better solution. This trusted list is provided by a trusted list provider, which is a central party responsible for (and capable of) -verifying that the level of security of an Providers' systems and +verifying that the level of security of a Providers' systems and processes is sufficient for the type of attestation it issues, and comparable to the level of security of other Providers for the same type of attestation. This may include requiring that a Provider documents From e53c841a3aad45c5d6c4073deaa09daf4ae1d5b3 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 14:34:40 +0200 Subject: [PATCH 09/16] =?UTF-8?q?Capitalised=20=E2=80=98solution=E2=80=99?= =?UTF-8?q?=20in=20=E2=80=98Wallet=20Solution=E2=80=99=20because=20it=20is?= =?UTF-8?q?=20a=20defined=20term.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 4 ++-- docs/media/image1.svg | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index bf21ce6..3998129 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -818,7 +818,7 @@ completely withdrawn. #### 4.2.4 EUDI Wallet Instance Lifecycle An EUDI Wallet Instance lifecycle begins when the User installs the -mobile app component of the EUDI Wallet solution provided by The EUDI +mobile app component of the EUDI Wallet Solution provided by The EUDI Wallet Provider. Once an EUDI Wallet Instance is installed and activated by the User and the EUDI Wallet Provider, it is in an **operational** state. In this state, the User manages the EUDI Wallet @@ -1110,7 +1110,7 @@ app or application the user is installing) is genuine, authentic and does not contain any malware or other threats. 2. The User SHALL be able to trust that the PID Provider will issue the PID into an instance of an EUDI Wallet Solution. -3. The User SHALL trust the EUDI Wallet solution. This means that the User +3. The User SHALL trust the EUDI Wallet Solution. This means that the User trusts the app store and the app publisher. The next sections discuss these trust relationships. diff --git a/docs/media/image1.svg b/docs/media/image1.svg index c32ff0c..f2f6f5a 100644 --- a/docs/media/image1.svg +++ b/docs/media/image1.svg @@ -60,4 +60,4 @@ font-style: italic; font-weight: 700; } -* {-webkit-font-smoothing: auto; -moz-osx-font-smoothing: auto;}@media print { svg { width: 100%; height: 100%; } }PID Provider (3)National Accreditation Body (14)Presents PID/(Q)EAAIssues PIDConformity Assessment Body (10)Supervisory Body (11)QEAA Provider (5)QES Provider (7)EAA Provider (6)EUDI Wallet InstanceUser (1)EUDI Wallet Provider (2)Relying Party (9)Offers servicesProvides Wallet solutionProvides QCIssues EAAIssues QEAA(Q)EAA Schema Provider (13)Device (OS) Manufacturer (12)Provides deviceProvides support, tools and librariesControls / activatesAuthentic Source (8)Provides qualified dataIn scope of the ARFNOT In scope of the ARFPrimary RoleGovernance Role ComponentLegendTrusted list Provider (4)RegistersRegistersProvides support \ No newline at end of file +* {-webkit-font-smoothing: auto; -moz-osx-font-smoothing: auto;}@media print { svg { width: 100%; height: 100%; } }PID Provider (3)National Accreditation Body (14)Presents PID/(Q)EAAIssues PIDConformity Assessment Body (10)Supervisory Body (11)QEAA Provider (5)QES Provider (7)EAA Provider (6)EUDI Wallet InstanceUser (1)EUDI Wallet Provider (2)Relying Party (9)Offers servicesProvides Wallet SolutionProvides QCIssues EAAIssues QEAA(Q)EAA Schema Provider (13)Device (OS) Manufacturer (12)Provides deviceProvides support, tools and librariesControls / activatesAuthentic Source (8)Provides qualified dataIn scope of the ARFNOT In scope of the ARFPrimary RoleGovernance Role ComponentLegendTrusted list Provider (4)RegistersRegistersProvides support From 9b3f01aa6d189c07f9cc16afc3f67b6c32967224 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 14:36:25 +0200 Subject: [PATCH 10/16] =?UTF-8?q?Replaced=20capitalised=20=E2=80=98The?= =?UTF-8?q?=E2=80=99=20with=20lowercased=20=E2=80=98the=E2=80=99=20in=20th?= =?UTF-8?q?e=20middle=20of=20a=20sentence.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index 3998129..4bd1573 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -818,7 +818,7 @@ completely withdrawn. #### 4.2.4 EUDI Wallet Instance Lifecycle An EUDI Wallet Instance lifecycle begins when the User installs the -mobile app component of the EUDI Wallet Solution provided by The EUDI +mobile app component of the EUDI Wallet Solution provided by the EUDI Wallet Provider. Once an EUDI Wallet Instance is installed and activated by the User and the EUDI Wallet Provider, it is in an **operational** state. In this state, the User manages the EUDI Wallet From 2e8b6c3786e6d6a2c979a6e8c6d2d8c1bc38bf33 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 14:37:00 +0200 Subject: [PATCH 11/16] Removed redundant whitespace between sentences. --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index 4bd1573..7548b7f 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -819,7 +819,7 @@ completely withdrawn. An EUDI Wallet Instance lifecycle begins when the User installs the mobile app component of the EUDI Wallet Solution provided by the EUDI -Wallet Provider. Once an EUDI Wallet Instance is installed and +Wallet Provider. Once an EUDI Wallet Instance is installed and activated by the User and the EUDI Wallet Provider, it is in an **operational** state. In this state, the User manages the EUDI Wallet Instance, which may involve: From e286b02571c32119ba10dfd3dc4ce4c051b88867 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 14:58:16 +0200 Subject: [PATCH 12/16] =?UTF-8?q?Consistent=20capitalisation=20of=20both?= =?UTF-8?q?=20words=20of=20=E2=80=98Trust=20Model=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index 7548b7f..6ffb392 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -255,7 +255,7 @@ specific types of transactions among a community of participants and bound by a common set of requirements. -Trust model* +Trust Model* Collection of rules that ensure the legitimacy of the components and the entities involved in the EUDI Wallet ecosystem. @@ -1037,7 +1037,7 @@ this version of this document also describes, on a high level, how this required trust can be established. This description includes references to existing or draft standards that define detailed security measures. -The trust model is valid for both remote and proximity use cases. +The Trust Model is valid for both remote and proximity use cases. However, technical measures taken to ensure that the requirements on trust are fulfilled may differ between these two use cases. Moreover, the authentication and authorization mechanisms will depend on the From a3b3acafe6563ad9d8619f1dcfdf19c69742aede Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 15:18:59 +0200 Subject: [PATCH 13/16] =?UTF-8?q?Consistent=20usage=20of=20British=20spell?= =?UTF-8?q?ing=20of=20=E2=80=98driving=20licence=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/annexes/annex-06-pid-rulebook.md | 2 +- docs/annexes/annex-07-mdl-rulebook.md | 8 ++++---- .../annex-09-design-guide-data-sharing-scenarios.md | 4 ++-- docs/arf.md | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/annexes/annex-06-pid-rulebook.md b/docs/annexes/annex-06-pid-rulebook.md index 772628c..4ebbdbd 100644 --- a/docs/annexes/annex-06-pid-rulebook.md +++ b/docs/annexes/annex-06-pid-rulebook.md @@ -599,7 +599,7 @@ Parties requesting PIDs[^10] These OIDs SHALL be used in certificates used for PID attributes within the ISO-compliant EUDI Wallet ecosystem, in exactly the same way as the corresponding OIDs specified in ISO/IEC 18103-5 are used within the -mobile driving license ecosystem. +mobile driving licence ecosystem. Notes: diff --git a/docs/annexes/annex-07-mdl-rulebook.md b/docs/annexes/annex-07-mdl-rulebook.md index ffd2cfd..c9877de 100644 --- a/docs/annexes/annex-07-mdl-rulebook.md +++ b/docs/annexes/annex-07-mdl-rulebook.md @@ -12,7 +12,7 @@ final.* ## Introduction -This document is the mobile driving license (mDL) Rule Book. It contains +This document is the mobile driving licence (mDL) Rule Book. It contains requirements specific to the mDL use case within the EUDI Wallet. These requirements hold in addition to the requirements in the Architecture Reference Framework (ARF), see \[ARF\]. Requirements in the ARF hold for @@ -38,7 +38,7 @@ Further topics will be added if and when they are identified. This document describes the structure, type, data element identifiers, and logical organisation of the mandatory and optional attributes of the -mobile driving license (mDL) attestation within the EUDI Wallet. It also +mobile driving licence (mDL) attestation within the EUDI Wallet. It also describes how Member States can specify any possible national attributes. @@ -50,8 +50,8 @@ Disclosure JSON Web Tokens (SD-JWT) must be used, and that consequently, data elements must be encoded in JSON. For the former, data elements must be encoded in CBOR. -However, mobile driving licenses are legally specified in the proposed -EC Regulation 2023\_127 (4^th^ Driving License Regulation). This +However, mobile driving licences are legally specified in the proposed +EC Regulation 2023\_127 (4^th^ Driving Licence Regulation). This Regulation specifies that mDLs shall comply with the ISO/IEC 18013-5 standard. It does not mention any other standards, in particular not \[SD JWT\]. Consequently, mDLs issued to an EUDI Wallet Instance shall diff --git a/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md b/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md index 6a450d2..2ece2a9 100644 --- a/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md +++ b/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md @@ -47,7 +47,7 @@ Party, the user does not necessarily have internet connectivity and the data presentation occurs using proximity protocols (NFC, Bluetooth, QR-Code, etc.). The key differentiator in the two proximity flows, is that in the supervised flow, the EUDI Wallet presents data (e.g. a -mobile driving license) to, or under the supervision of, a human acting +mobile driving licence) to, or under the supervision of, a human acting as a Relying Party (who may operate a device of their own). In the unsupervised flow, the EUDI Wallet presents verifiable attributes to a machine without human supervision. @@ -374,7 +374,7 @@ The user gets an error message indicating that they must try again later. ### 5.3 The document is considered invalid (expired/revoked) When the user presents an invalid document through the app, (e.g., a -driver\'s license to a police officer) the app displays an error message +driver\'s licence to a police officer) the app displays an error message on the user's screen, indicating that the document could not be verified because it is expired or revoked. diff --git a/docs/arf.md b/docs/arf.md index 6ffb392..5fd8b53 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1330,7 +1330,7 @@ current version of this document: Relying Party does not verify these technical properties during the attestation release process. To elaborate: A Relying Party typically has a list of attestations that it accepts for a certain use case. For - example, a Relying Party MAY accept a mobile driving license as a proof + example, a Relying Party MAY accept a mobile driving licence as a proof of identity. If so, that Relying Party SHALL accept any valid and authentic mDL, regardless of the mobile device it is installed on. If the Relying Party were to make its own independent assessment of the security @@ -1535,7 +1535,7 @@ checking. When discussing attestation revocation, it is essential to realize that in many cases there is a difference between an attestation and the -document it represents, for instance a driving license, passport, +document it represents, for instance a driving licence, passport, recurring medicine prescription, health insurance card, vehicle registration card, etc. Such a document typically has an administrative validity period of multiple years. A diploma typically even has no end of @@ -1596,7 +1596,7 @@ The only party in the EUDI Wallet ecosystem capable of revoking an attestation SHALL be the attestation Provider. This is important, because in some use cases, there are third parties that have the (legal) right to invalidate an attestation. For example, in many jurisdictions the police -are allowed to confiscate a driving license if the User is caught is a +are allowed to confiscate a driving licence if the User is caught is a serious traffic violation. Another example is an electronic prescription for medicines that is valid only once and must not be usable anymore after the User has received the medicines[^20] . A third example is when From 70bbd9109f40462d051a771283ccfe78a943e62d Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 15:21:24 +0200 Subject: [PATCH 14/16] =?UTF-8?q?Replaced=20=E2=80=98realize=E2=80=99=20wi?= =?UTF-8?q?th=20the=20British=20spelling=20=E2=80=98realise=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/arf.md b/docs/arf.md index 5fd8b53..94e706e 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1533,7 +1533,7 @@ The Relying Party uses a Relying Party Instance to interact with the User's Wallet Instance. This includes carrying out attestation revocation checking. -When discussing attestation revocation, it is essential to realize that +When discussing attestation revocation, it is essential to realise that in many cases there is a difference between an attestation and the document it represents, for instance a driving licence, passport, recurring medicine prescription, health insurance card, vehicle From f3cd931ca7260784bbde046db487b047c28f71ab Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 15:30:13 +0200 Subject: [PATCH 15/16] =?UTF-8?q?Replaced=20=E2=80=98analyze=E2=80=99=20wi?= =?UTF-8?q?th=20the=20British=20spelling=20=E2=80=98analyse=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index 94e706e..d0c5d0a 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1582,8 +1582,8 @@ of the following conditions occur: * The User notified the attestation Provider. * In case of any (suspected) breach of security. -The attestation Provider SHALL analyze whether revocation is required in -these circumstances. Also, the Provider SHALL analyze if there are more +The attestation Provider SHALL analyse whether revocation is required in +these circumstances. Also, the Provider SHALL analyse if there are more situations in which attestation revocation is required. A PID Provider or a (Q)EAA Provider MAY outsource the responsibility of From f789825213b1550ebc14de9eb70b0c89892d7b7b Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 12 Mar 2024 15:37:27 +0200 Subject: [PATCH 16/16] =?UTF-8?q?Consistent=20capitalisation=20of=20both?= =?UTF-8?q?=20words=20of=20=E2=80=98Authentic=20Source=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index d0c5d0a..1d538d3 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1604,8 +1604,8 @@ the attestation Provider and the Authentic Source for that attestation are different parties. If so, the Authentic Source contains the authoritative information about whether an attribute value must be changed, and an attestation revoked or reissued. It must be the -responsibility of attestation Providers to regularly query the authentic -source for changes and reissue or revoke the relevant attestations +responsibility of attestation Providers to regularly query the Authentic +Source for changes and reissue or revoke the relevant attestations accordingly. However, third parties that want to invalidate an attestation SHALL use