From b29bd8912afed22135700652a53b2532e7cc7538 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Wed, 13 Mar 2024 15:30:49 +0200 Subject: [PATCH 1/5] =?UTF-8?q?Replaced=20=E2=80=98realizing=E2=80=99=20wi?= =?UTF-8?q?th=20the=20British=20spelling=20=E2=80=98realising=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 dcdac44..5a7560e 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -2248,7 +2248,7 @@ about the need to authenticate the Relying Party in each of the scenarios users of the EUDI wallets in any transaction they are involved in, from any risk of false authentication - without exceptions. -Note: This recommendation stems from realizing that strict requirements +Note: This recommendation stems from realising that strict requirements to use HSMs for all relying parties will not be practical to enforce and will limit the usage of the wallets in cases where this high-level security is not necessary. From 4fa461c6e606404d32f587c192dab17563e9e081 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Wed, 13 Mar 2024 15:34:34 +0200 Subject: [PATCH 2/5] =?UTF-8?q?Capitalised=20=E2=80=98relying=20party?= =?UTF-8?q?=E2=80=99=20and=20=E2=80=98relying=20parties=E2=80=99.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/annexes/annex-09-design-guide-data-sharing-scenarios.md | 4 ++-- docs/arf.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) 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..fd61650 100644 --- a/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md +++ b/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md @@ -32,7 +32,7 @@ In relation to the remote flows, it shall be noted that the data exchange occurs In contrast, in the 'remote cross-device' flow, the EUDI Wallet user consumes information from a Relying Party service on another device than -the EUDI Wallet device, e.g. user visits the relying party's service on +the EUDI Wallet device, e.g. user visits the Relying Party's service on their web browser on a PC and uses the EUDI Wallet app to scan a QR Code on a login page in order to get access to a service provided by the Relying Party. @@ -181,7 +181,7 @@ consent. - **Transparency and Clarity**: Transparency is key in ensuring that users are always aware of what information is being presented. The EUDI Wallet should include clear and concise explanations about the - purpose of each data request, the relying party\'s identity, and how + purpose of each data request, the Relying Party\'s identity, and how the data will be used, highlighting data storage and 'intent to store' aspects to the user. Utilising plain language and avoiding technical jargon can enhance understanding and minimise user diff --git a/docs/arf.md b/docs/arf.md index 5a7560e..a7f7b30 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -2249,7 +2249,7 @@ users of the EUDI wallets in any transaction they are involved in, from any risk of false authentication - without exceptions. Note: This recommendation stems from realising that strict requirements -to use HSMs for all relying parties will not be practical to enforce and +to use HSMs for all Relying Parties will not be practical to enforce and will limit the usage of the wallets in cases where this high-level security is not necessary. @@ -2439,7 +2439,7 @@ B.1.2 of \[ISO/IEC18013-5\], with the following exceptions: To be done. ### 7.6 Relying Party authorization -There is a risk that relying parties may over-ask, i.e., ask a Wallet +There is a risk that Relying Parties may over-ask, i.e., ask a Wallet instance for more attributes than the Relying Party reasonably needs for its use case. This is obviously a risk for the privacy of the user, and this risk must be mitigated. At least three approaches can in principle From 5869ab9813640fffcafd38cecd4baa0e197e9780 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Wed, 13 Mar 2024 15:40:18 +0200 Subject: [PATCH 3/5] =?UTF-8?q?Capitalised=20=E2=80=98instance=E2=80=99=20?= =?UTF-8?q?in=20=E2=80=98Wallet=20Instance=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 a7f7b30..cc2d3bc 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -2440,7 +2440,7 @@ To be done. ### 7.6 Relying Party authorization There is a risk that Relying Parties may over-ask, i.e., ask a Wallet -instance for more attributes than the Relying Party reasonably needs for +Instance for more attributes than the Relying Party reasonably needs for its use case. This is obviously a risk for the privacy of the user, and this risk must be mitigated. At least three approaches can in principle be used to protect the user against over-asking: the user approval From 6420bf4ae0b1e813a8fa3c846b5e89ea394e0792 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 14 Mar 2024 11:48:44 +0200 Subject: [PATCH 4/5] =?UTF-8?q?Lowercased=20=E2=80=98MAY=E2=80=99=20in=20s?= =?UTF-8?q?ection=207.6.1.=20The=20=E2=80=98may=E2=80=99=20is=20in=20a=20d?= =?UTF-8?q?iscussive=20sentence,=20not=20in=20a=20sentence=20that=20descri?= =?UTF-8?q?bes=20a=20requirement.?= 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 cc2d3bc..bc7cb54 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -2456,7 +2456,7 @@ and the specific Relying Party they are dealing with. User approval SHALL be implemented in all use cases. -However, User Approval has some limitations that MAY make it +However, User Approval has some limitations that may make it insufficiently effective in preventing Relying Parties from over-asking, as described below: From cb27b273693f9865fe1d8fd992d49cf0a5b5bc29 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 14 Mar 2024 11:55:51 +0200 Subject: [PATCH 5/5] =?UTF-8?q?Lowercased=20=E2=80=98Approval=E2=80=99=20i?= =?UTF-8?q?n=20=E2=80=98User=20approval=E2=80=99=20because=20it=20is=20not?= =?UTF-8?q?=20a=20defined=20term.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/arf.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/arf.md b/docs/arf.md index bc7cb54..084a4ba 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -2450,13 +2450,13 @@ level. #### 7.6.1 User approval as a means for Relying Party authorization -User Approval protects against over-asking by allowing the User to refuse +User approval protects against over-asking by allowing the User to refuse sharing attributes that they deem unnecessary for the specific use case and the specific Relying Party they are dealing with. User approval SHALL be implemented in all use cases. -However, User Approval has some limitations that may make it +However, User approval has some limitations that may make it insufficiently effective in preventing Relying Parties from over-asking, as described below: @@ -2470,7 +2470,7 @@ as described below: Party does not actually need. Moreover, Users will be tempted to release all requested attributes, just to ensure they can enjoy the benefits of the use case. -* Secondly, although User Approval may prevent a misbehaving Relying +* Secondly, although User approval may prevent a misbehaving Relying Party from over-asking in individual cases, it does not provide authorities with a means to solve disagreements between User and Relying Party as to what attributes can be reasonably requested, and