This document details comments on the new version of ARF. We want to restate that privacy and especially unlinkability shall be an essential part of ARF, this is not the case in ARF 1.3.
The GSMA actively participated to the GitHub issues discussion available for review of ARF version 1.1. These comments were related to privacy (especially unlinkability) and security.
Concerning privacy, there were several comments posted on ARF GitHub. These comments explained in detail the fact that privacy is not taken into account in ARF 1.1 and why it matters for civil society as a whole. Specifically, the current protocol and mechanism (ISO mDL, SD-JWT) mentioned in ARF are not suited to guarantee privacy of the EUDIW holder and are problematic from an unlinkability point of view (cf: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66).
Even though we responded in detail to all comments made on the ARF GitHub linked to the privacy and unlinkability, there was no answer from the ARF editors and privacy and unlikability issues are still not addressed in ARF1.3.
More specifically, it is stated in ARF 1.3 section 6.1 that “User privacy is not specifically discussed in this document.”
The trust model defined in section 6 is focused on security and not at all on privacy/unlinkability. In section 6.2.3.4, attestation signature by the issuer to guarantee to the verifier that the attestation belongs to the right holder is defined. This is important and necessary from a security perspective. However when applying these principles to ISO mDL, for all currently defined protocols, the public key is a static information that acts as a tracking identifier. The situation is the same when using SD-JWT. Moreover, the last paragraph of this section raises concerns related to the potential tracking of a WSCD identifier.
Furthermore, when looking at the revocation schemas, it is stated that revocation can be handled in two different ways. In both solutions, the verifier is expected to make use of an ID linked to the attestation. One more time in this case, privacy and unlinkability are not guaranteed.
Based on the elements listed previously, privacy and unlinkability considerations in particular are missing in ARF 1.3.
Also, holder binding is mentioned in tables 3 and 4 but never defined nor used. Later in ARF 1.3, only device binding is mentioned. We are wondering why it is the case given that holder binding is obviously mandatory and whether device binding is necessary if holder binding is well defined and mandatory.
Finally, as already stated in our previous comment, everlasting privacy is not considered at all for the protocols listed in ARF 1.3. As a reminder, everlasting privacy ensures that whatever happens in the future (including a secret leak, a breach in the protocol, etc…), the data and the actors of the transaction cannot be retrieved. This is a mathematically provable property. Everlasting Privacy is an important property for eIDAS2. Please remember that ISOmDL and SD-JWT are protocol/mechanism that do not support everlasting privacy.
This document details comments on the new version of ARF. We want to restate that privacy and especially unlinkability shall be an essential part of ARF, this is not the case in ARF 1.3. The GSMA actively participated to the GitHub issues discussion available for review of ARF version 1.1. These comments were related to privacy (especially unlinkability) and security.
Concerning privacy, there were several comments posted on ARF GitHub. These comments explained in detail the fact that privacy is not taken into account in ARF 1.1 and why it matters for civil society as a whole. Specifically, the current protocol and mechanism (ISO mDL, SD-JWT) mentioned in ARF are not suited to guarantee privacy of the EUDIW holder and are problematic from an unlinkability point of view (cf: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66). Even though we responded in detail to all comments made on the ARF GitHub linked to the privacy and unlinkability, there was no answer from the ARF editors and privacy and unlikability issues are still not addressed in ARF1.3.
More specifically, it is stated in ARF 1.3 section 6.1 that “User privacy is not specifically discussed in this document.” The trust model defined in section 6 is focused on security and not at all on privacy/unlinkability. In section 6.2.3.4, attestation signature by the issuer to guarantee to the verifier that the attestation belongs to the right holder is defined. This is important and necessary from a security perspective. However when applying these principles to ISO mDL, for all currently defined protocols, the public key is a static information that acts as a tracking identifier. The situation is the same when using SD-JWT. Moreover, the last paragraph of this section raises concerns related to the potential tracking of a WSCD identifier. Furthermore, when looking at the revocation schemas, it is stated that revocation can be handled in two different ways. In both solutions, the verifier is expected to make use of an ID linked to the attestation. One more time in this case, privacy and unlinkability are not guaranteed.
Based on the elements listed previously, privacy and unlinkability considerations in particular are missing in ARF 1.3. Also, holder binding is mentioned in tables 3 and 4 but never defined nor used. Later in ARF 1.3, only device binding is mentioned. We are wondering why it is the case given that holder binding is obviously mandatory and whether device binding is necessary if holder binding is well defined and mandatory.
Finally, as already stated in our previous comment, everlasting privacy is not considered at all for the protocols listed in ARF 1.3. As a reminder, everlasting privacy ensures that whatever happens in the future (including a secret leak, a breach in the protocol, etc…), the data and the actors of the transaction cannot be retrieved. This is a mathematically provable property. Everlasting Privacy is an important property for eIDAS2. Please remember that ISOmDL and SD-JWT are protocol/mechanism that do not support everlasting privacy.