3.3
PID Providers may e.g., be the same organisations that today issue official identity documents, electronic identity means, EUDI Wallet Providers etc. --> Delete "EUDI Wallet Providers" as today none is issued
3.6
The requirements from Authentic Sources on the issuance and operation of PuB-EAAs are intended to enable to Relying Parties... --> Delete "to" before "Relying Parties"
3.8
Art. 5a, par. 5g provides for free of charge signing only and not sealing. So, it should be clarified that sealing, although supported, will not be free of charge in general.
3.13
Hence, device manufacturers, and related subsystem providers need to provide a platform on which where the EUDI Wallet Solution can... --> Delete "where".
3.14
Common schemas, including by sector- specific organisations... --> Remove extra space after '-'.
4.2.1
RSI --> Since the wallet supports also sealing, shouldn't this be renamed into something like "Remote Signing or sealing interface"?
4.4.1
In this chapter, state diagrams are presented to explain the relations between the Wallet Solution the Wallet... --> Add comma after "Solution".
4.4.3
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; the Wallet Instance status is installed. --> ')' is missing.
6.5.2.1
If the relevant PID Provider or Attestation Provider does not support the Wallet Solution, the User would not be able to use the Wallet Instance for obtaining those PID(s) or attestation(s). --> the User will not
6.5.2.2
Finally, it prevents the User must allow side-loading of apps, which --> from allowing the side-loading
6.6.2.2
The Wallet Instance also verifies that the certificate is authentic, that it is valid at the time of validation, and that the issuer of the certificate is a CA that is in the Attestation Provider CA Trusted List. --> Access CA
6.6.3.3
The PID Provider or Attestation Provider optionally embeds a disclosure policy in the PID or attestation. Such an embedded disclosure policy contains rules determining which (types of) Relying Party are --> which types of Relying Parties are
6.6.3.8
or in an unsupervised proximity flow if equipped with the appropriate equipment It may also be possible --> '.' is missing
7.2.1
the following key documents are prepared; a Risk and Cybersecurity Assessment, a HLR, and --> an HLR
A.2.3.12
ARB_1 ...that at least one or more... -> Remove "or more". "at least one" covers all cases.
ARB_6 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. ==> Something seems to be missing.
A.2.3.16
QES_06 2nd bullet "Walle Instance" --> 't' is missing in Wallet.
C. Requirements for the Commission
Why are the QES_23 and QES_24 included here?
A.2.3.25
CAT_08 Note: The catalogue of attributes does need not be a --> does not need to be able
CAT_11 The Commission SHALL make publicly available the existence and maintenance of the catalogue of attributes mentioned in CAT_09 --> CAT_08
A.2.3.27
Reg_05 The Commission SHALL establish a technical specification for the common formats mentioned in Reg_04 and Reg_05 --> Reg_05 in this sentence is wrong.
A.2.3.42
QTSPAS_03 Authentic source or designated intermediary SHALL define and implement QTSPAS_001 in a secure and privacy-preserving channel in accordance with technical specifications referred to in QTSPAS_007. --> QTSPAS_001 => QTSPAS_01 and QTSPAS_007 => QTSPAS_07.
QTSPAS_04 Authentic source or designated intermediary SHALL define and implement QTSPAS_001 so that the QTSP will receive the result of the verification of the requested attributes, as described in QTSPAS_002. --> QTSPAS_001 => QTSPAS_01 and QTSPAS_002 => QTSPAS_02.
QTSPAS_05 Member States SHALL define QTSPAS_001 so --> QTSPAS_001 => QTSPAS_01.
ARF
3.3 PID Providers may e.g., be the same organisations that today issue official identity documents, electronic identity means, EUDI Wallet Providers etc. --> Delete "EUDI Wallet Providers" as today none is issued
3.6 The requirements from Authentic Sources on the issuance and operation of PuB-EAAs are intended to enable to Relying Parties... --> Delete "to" before "Relying Parties"
3.8 Art. 5a, par. 5g provides for free of charge signing only and not sealing. So, it should be clarified that sealing, although supported, will not be free of charge in general.
3.13 Hence, device manufacturers, and related subsystem providers need to provide a platform on which where the EUDI Wallet Solution can... --> Delete "where".
3.14 Common schemas, including by sector- specific organisations... --> Remove extra space after '-'.
4.2.1 RSI --> Since the wallet supports also sealing, shouldn't this be renamed into something like "Remote Signing or sealing interface"?
4.4.1 In this chapter, state diagrams are presented to explain the relations between the Wallet Solution the Wallet... --> Add comma after "Solution".
4.4.3 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; the Wallet Instance status is installed. --> ')' is missing.
6.5.2.1 If the relevant PID Provider or Attestation Provider does not support the Wallet Solution, the User would not be able to use the Wallet Instance for obtaining those PID(s) or attestation(s). --> the User will not
6.5.2.2 Finally, it prevents the User must allow side-loading of apps, which --> from allowing the side-loading
6.6.2.2 The Wallet Instance also verifies that the certificate is authentic, that it is valid at the time of validation, and that the issuer of the certificate is a CA that is in the Attestation Provider CA Trusted List. --> Access CA
6.6.3.3 The PID Provider or Attestation Provider optionally embeds a disclosure policy in the PID or attestation. Such an embedded disclosure policy contains rules determining which (types of) Relying Party are --> which types of Relying Parties are
6.6.3.8 or in an unsupervised proximity flow if equipped with the appropriate equipment It may also be possible --> '.' is missing
7.2.1 the following key documents are prepared; a Risk and Cybersecurity Assessment, a HLR, and --> an HLR
Annex 2
A.2.3.12 ARB_1 ...that at least one or more... -> Remove "or more". "at least one" covers all cases.
ARB_6 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. ==> Something seems to be missing.
A.2.3.16 QES_06 2nd bullet "Walle Instance" --> 't' is missing in Wallet.
C. Requirements for the Commission Why are the QES_23 and QES_24 included here?
A.2.3.17 IM_01 "PID-s" --> PIDs
A.2.3.19 DASH_03 For each presentation transaction executed --> For each presentation of a transaction executed
A.2.3.24 Topioc --> Topic ProxId_044 -> ProxId_04
A.2.3.25 CAT_08 Note: The catalogue of attributes does need not be a --> does not need to be able CAT_11 The Commission SHALL make publicly available the existence and maintenance of the catalogue of attributes mentioned in CAT_09 --> CAT_08
A.2.3.27 Reg_05 The Commission SHALL establish a technical specification for the common formats mentioned in Reg_04 and Reg_05 --> Reg_05 in this sentence is wrong.
A.2.3.42 QTSPAS_03 Authentic source or designated intermediary SHALL define and implement QTSPAS_001 in a secure and privacy-preserving channel in accordance with technical specifications referred to in QTSPAS_007. --> QTSPAS_001 => QTSPAS_01 and QTSPAS_007 => QTSPAS_07.
QTSPAS_04 Authentic source or designated intermediary SHALL define and implement QTSPAS_001 so that the QTSP will receive the result of the verification of the requested attributes, as described in QTSPAS_002. --> QTSPAS_001 => QTSPAS_01 and QTSPAS_002 => QTSPAS_02.
QTSPAS_05 Member States SHALL define QTSPAS_001 so --> QTSPAS_001 => QTSPAS_01.