diff --git a/docs/arf.md b/docs/arf.md index d9edb94..f7b280a 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1120,7 +1120,7 @@ To be done. #### 6.2.2 EUDI Wallet Instance activation -##### 6.2.2.1 Required trust relationships[^15] +##### 6.2.2.1 Required trust relationships[^14] After its' installation, a new EUDI Wallet Instance will need to be activated by the Wallet Provider. Activation has at least the following @@ -1441,7 +1441,7 @@ Regarding the technical implementation of these steps: * The mechanism for step 3 is described in section 6.3.4. ##### 6.3.2.4 Relying Party trusts device binding -The Relying Party SHALL be able to trust that an attestation it receives was not copied and replayed. In other words, the Relying Party trusts that the attestation is bound to the same device to which the Provider issued it [^16]. +The Relying Party SHALL be able to trust that an attestation it receives was not copied and replayed. In other words, the Relying Party trusts that the attestation is bound to the same device to which the Provider issued it [^15]. 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. @@ -1468,7 +1468,7 @@ The mechanism(s) for User binding depend on the type of use case: transaction, on behalf of the Relying Party. If User binding is required in such cases, the Relying Party can request the User portrait, next to other attributes, and the EUDI Wallet Instance can - release it. The portrait SHALL be signed by a trusted Provider [^17]. + release it. The portrait SHALL be signed by a trusted Provider [^16]. The human supervisor then visually compares this portrait to the face of the person presenting the attestation. However, please note that the presence and use of the User portrait in the PID will be further @@ -1483,7 +1483,7 @@ The mechanism(s) for User binding depend on the type of use case: User portrait for user authentication by the Relying Party is generally considered to be impractical. Relying Parties SHALL therefore trust User authentication mechanisms present on or connected to the device - which the EUDI Wallet Instance is installed on [^18]. + which the EUDI Wallet Instance is installed on [^17]. ##### 6.3.2.6 User trusts the identity of the Relying Party @@ -1541,7 +1541,7 @@ of such a document and has a cryptographic proof of its authenticity with a validity period that is typically short, for example - several weeks. This implies that an attestation Provider will renew the attestation -regularly during the validity period of the document[^19]. Also, an +regularly during the validity period of the document[^18]. Also, an attestation Provider MAY issue multiple attestations that are simultaneously valid but represent the same document. For example, a User MAY have a mobile passport on their private phone and their work phone. @@ -1596,7 +1596,7 @@ invalidate an attestation. For example, in many jurisdictions the police are allowed to confiscate a driving license 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 +after the User has received the medicines[^19] . A third example is when 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 @@ -1806,7 +1806,7 @@ the Relying Party Instance SHALL perform the following steps: 2. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the attestation to see if it contains Attestation Status List information. If so, the Relying Party Instance SHALL use the inspection procedure - specified in \[JWTStatusList\][^21] to find out the current status of + specified in \[JWTStatusList\][^20] to find out the current status of the attestation. 3. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the attestation to see if it contains Attestation Revocation List @@ -2255,7 +2255,7 @@ In essence, a Relying Party authentication mechanism works as follows: 1. The Relying Party Instance SHALL create a signature over some data in the protocol for the request, using a Relying Party Instance private key. -2. The Relying Party Instance SHALL include its certificate[^22] (and all +2. The Relying Party Instance SHALL include its certificate[^21] (and all other certificates in the trust chain leading up to its trust anchor) associated with the private key in the request. The certificate SHALL be signed (directly or indirectly) by a Certification Authority, whose @@ -2669,7 +2669,7 @@ C., Zundel, B., and D. Chadwick, "Verifiable Credentials Data Model Looker, "OpenID for Verifiable Presentations", 30 December 2022, -\[OpenID4VCI\] Lodderstedt, T., Yasuda, K., and T. Looker, OpenID for Verifiable Presentations – draft 18, 21 April 2023[^23] Retrievable from [OpenID for Verifiable Credential Issuance - draft 12](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) +\[OpenID4VCI\] Lodderstedt, T., Yasuda, K., and T. Looker, OpenID for Verifiable Presentations – draft 18, 21 April 2023[^22] Retrievable from [OpenID for Verifiable Credential Issuance - draft 12](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) \[Prop_eIDAS\] COM(2021) 281 final @@ -2677,7 +2677,7 @@ Looker, "OpenID for Verifiable Presentations", 30 December 2022, \[DP_Revoc\] eIDAS Expert Group WG1 Discussion Paper Revocation for PID and (Q)EAA, v.1.0 -\[SD-JWT\] Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt 04, 11 April 2023[^24] +\[SD-JWT\] Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt 04, 11 April 2023[^23] \[W3C StatusList2021\] @@ -2742,33 +2742,33 @@ https://www.w3.org/TR/json-ld/ accreditation and market surveillance relating to the marketing of products and repealing Regulation (EEC) No 339/93 -[^15]: Please note that work on further specifying the EUDI Wallet +[^14]: Please note that work on further specifying the EUDI Wallet Instance Attestation is planned to be carried out. This section may need to be revised depending on the results of that work. For instance, EUDI Wallet Instance Attestation may not be issued in all cases nor are alternative possibilities excluded from consideration. -[^16]: The ARF implicitly requires device binding for the Wallet Instance +[^15]: The ARF implicitly requires device binding for the Wallet Instance (by requiring support for ISO/IEC 18013-5 and SD-JWT) -[^17]: Preferably the same Issuer that also signed the other attributes +[^16]: Preferably the same Issuer that also signed the other attributes that were released. However, the combined presentation of attributes originating from different attestations will be further detailed in a future version of this document. -[^18]: Note that this implies that Relying Parties SHALL also trust +[^17]: Note that this implies that Relying Parties SHALL also trust device binding, see section 6.2.3.4. The Relying Party trusts that the attestation is bound to a device trusted by the Provider, and subsequently trusts that this device has properly authenticated the User. -[^19]: A PID MAY be an exception: because the concept of a PID is new, it +[^18]: A PID MAY be an exception: because the concept of a PID is new, it is not known yet what validity period PID Providers will use for their PIDs, and if there will be a difference between the administrative validity period as seen by the User and the cryptographic validity period of the attestation. -[^20]: In this case, an alternative to revocation is that the pharmacy +[^19]: In this case, an alternative to revocation is that the pharmacy backend marks the prescription as used, and all pharmacies check that backend before handing out the medicines. This goes in fact for any attestation: if there is a backend system that allows Relying Parties @@ -2777,22 +2777,22 @@ https://www.w3.org/TR/json-ld/ exists for all attestations that can be ‘consumed’, i.e., that must become unusable once they have been used. -[^21]: The current version of \[JWTStatusList\] does not explicitly +[^20]: The current version of \[JWTStatusList\] does not explicitly describe such a procedure. The EC will point out to the authors that this should be added. -[^22]: Please note that the term "certificate" does not mean only X.509 +[^21]: Please note that the term "certificate" does not mean only X.509 certificates, but it includes also other formats of certificates, such as in Distributed Ledgers. -[^23]: The exact version to be referenced is to be determined. \[ARF\] +[^22]: The exact version to be referenced is to be determined. \[ARF\] references v0.14 of 30 December 2022. Draft 18 is the latest version available at the time of writing of this document. The level of interoperability between these versions is not known. As \[OpenID4VP\] is still under development, presumably later versions will become available over time. -[^24]: The exact version to be referenced is to be determined. Draft 18 +[^23]: The exact version to be referenced is to be determined. Draft 18 the latest version available at the time of writing of this document. The level of interoperability between these versions is not known. As \[SD-JWT\] is still under development, presumably later versions may