The following comments are linked to privacy, unlinkability and everlasting privacy. GSMA EIG does want to remind the fact that privacy is an important topic and that it shall be addressed properly in the ARF. The definition of unlinkability and everlasting privacy technical concepts shall be added as technical objectives of ARF. GSMA EIG remain concerned about the capacity of the proposed solutions to implement these technical concepts in particular for revocation and on the structural incapacity of ISO mDL and SD-JWT standards to support full unlinkability. (In the rest of this text, the text between quotes in italic is extracted from ARF 1.4)
§ 2.4: In state-of-the-art solutions, a pseudonym is provided by the user himself and not by a third-party pseudonym provider. This is the best way to ensure user privacy. User authentication shall be anonymous by default. Depending on the regulatory and/or legal context, anonymity may be reduced.
§ 3.5: It is stated “QEAA Providers provide information on the location of the services that can be used to enquire about the validity status of the QEAAs, without having an ability to receive any information about the use of the attestations”. However, the implementation of this feature is not detailed. State-of-the-art solutions are available to ensure the validity of an attestation without compromising privacy and in particular while preserving unlinkability.
§ 4.1.1: “Users should have clear control over their data and privacy, with transparent information about what data is being shared and with whom”. We agree with the statement, however when trackable metadata are shared without proper user knowledge / understanding, then we do not consider privacy as being fully addressed. State-of-the-art solutions exist that provide unlinkability.
§ 4.1.3: “The wallet empowers users with granular control over what data is shared and with whom. Transparency is built into the system, with clear explanations of how data is used and protected” The section discusses privacy related to user attributes and data minimization. However, there is no mention of user tracking and impacts of sharing technical identifiers or signature fingerprint, neither any mention of everlasting privacy. Furthermore, the claims about data minimization are not substantiated in the remainder of the document.
§ 4.2.1: We do not think that accounting shall be under the responsibility of the Wallet. We do not understand how such an architecture would comply with the functional accounting requirement and be privacy preserving. There are state-of-the-art solutions for accounting that are privacy preserving and allow flexible business exchanges.
§5.2: With ISO/IEC 18013-5, SD-JWT and SD-JWT VC current specifications, user tracking can be achieved by tracking technical identifiers like public keys, salts value and expiry date or Issuer signature fingerprint. Furthermore, everlasting privacy is not offered at all by the protocols defined in these specifications.
The possible tracking that can be performed and that will put in danger user privacy are the following:
RP tracking on subsequent interactions
RP – RP tracking
RP – Issuer tracking
§ 6.1.3: “Moreover, Relying Parties may collude with other Relying Parties to do so”. Data sharing / collusion can happen not only between RPs but also theoretically between RP and issuer. It can be involuntary, for instance in the case of hacking, social engineering or corruption. This shall be added in this sentence.
§6.5.3: “Moreover, the WTE contains a WTE public key. During the issuance of a PID or an attestation (see section 6.6.2.3), a PID Provider or Attestation Provider can use this public key to verify that the Wallet Instance is in possession of the corresponding private key”
If the cryptographic protocols used for signature do not allow for randomization of the public key and associated signature, Issuer-Issuer tracking can be achieved by tracking the public key.
We are waiting for the “whitepaper on WTE” but given the rest of the document, we assume the protocols to be used not to allow public key and signature randomization.
For the same reasons, we are also assuming that all this WTE infrastructure will not support everlasting privacy.
§ 6.6.2.3: “The PID Provider or Attestation Provider verifies the signature over the WTE, using the Wallet Provider trust anchor obtained from the Trusted List.” Issuer-Issuer tracking could be achieved by tracking WTE signature. (same comment as above)
“Next, the PID Provider or Attestation Provider verifies that the Wallet Instance possesses the private key belonging to the public key in the WTE” Issuer-Issuer tracking could be achieved by tracking the WTE public Key. (same comment as above)
“How the PID Provider or Attestation Provider can obtain a so-called proof of association from the WSCD. This proof of association proves that the WSCD described in the WTE protects both the WTE public key and the public key of the PID or the new attestation” Issuer-Issuer tracking could be achieved by tracking the proof of association.
The previous statements also imply that everlasting privacy is not addressed.
6.6.2.4: “The WIA allows PID Providers, Attestation Providers and Relying Parties to verify that the Wallet Instance is not suspended or revoked” Issuer-Issuer tracking could be achieved by tracking WIA signature and public key. (We are looking forward to this “Whitepaper on Wallet Instance Revocation” that shall detail what protocols will be used here). Everlasting privacy cannot be achieved if this tracking is possible.
6.6.3: “The Relying Party Instance verifies the electronic signature or seal of the PID or attestation”.
RP tracking on subsequent interaction could be achieved by tracking the Issuer signature,
RP-RP tracking could be achieved by tracking the Issuer signature.
RP-Issuer tracking can be achieved by tracking the Issuer signature
“The Relying Party verifies that the PID Provider or Attestation Provider issued this attestation to the same Wallet Instance that provided it to the Relying Party. In other words, it checks that the attestation was not copied or replayed”
RP tracking on subsequent interaction could be achieved by tracking the attestation’ public key
RP-RP tracking could be achieved by tracking the attestation’ public key
RP-Issuer tracking can be achieved by tracking the attestation’ public key
Everlasting privacy cannot be achieved if such tracking is possible.
6.6.3.5: “The Relying Party Instance verifies the electronic signature or seal over the PID or attestation”
RP tracking on subsequent interaction could be achieved by tracking the Issuer signature
RP-RP tracking could be achieved by tracking the Issuer signature.
RP-Issuer tracking can be achieved by tracking the Issuer signature
Everlasting privacy cannot be achieved if such tracking is possible.
§ 6.6.3.6 & Annex 2 (VCR_09, VCR12): “This revocation information must include a URL indicating the location where a Relying Party can obtain a status list or revocation list, and an identifier or index for this specific certificate or attestation within that list.”_
RP tracking on subsequent interaction could be achieved by tracking the identifier or index
RP-RP tracking could be achieved by tracking the identifier or index.
RP-Issuer tracking can be achieved by tracking the identifier or index
Everlasting privacy cannot be achieved if such tracking is possible.
There are state-of-the-art solutions available that can handle non revocation proofs while preserving privacy. Moreover, it is also stated that the validity period is 24h. We do not see any clear justification for having such a long validity period. There are ways to have shorter validity period.
6.6.3.7: “During an interaction, the Relying Party verifies that the PID or attestation it received from a Wallet Instance is indeed bound to the WSCD used by the Wallet Instance. The Relying Party does so by requesting the Wallet Instance to sign some data using the private key corresponding to the public key in the PID or attestation.”
RP tracking on subsequent interaction could be achieved by tracking the WSCD public key
RP-RP tracking could be achieved by tracking the WSCD public key
RP-Issuer tracking can be achieved by tracking the WSCD public key
Everlasting privacy cannot be achieved if such tracking is possible.
6.6.3.10 “verifies the signature over the WIA using the Wallet Provider trust anchor obtained from the Wallet Provider Trusted List''.
RP tracking on subsequent interaction could be achieved by tracking the signature over the WIA
RP-RP tracking could be achieved by tracking the signature over the WIA
RP-Issuer tracking can be achieved by tracking the signature over the WIA
Verifies that the Wallet Instance has the private key belonging to the public key in the WIA. This proves that the Wallet Instance is authentic and is provided by the trusted Wallet Provider.
RP tracking on subsequent interaction could be achieved by tracking the public key in the WIA
RP-RP tracking could be achieved by tracking the public key in the WIA
RP-Issuer tracking can be achieved by tracking the public key in the WIA
Everlasting privacy cannot be achieved if such tracking is possible.
6.6.3.11 “Section 6.6.2.4 explained how a PID Provider, or an Attestation Provider, can verify that a Wallet Instance is not suspended or revoked. The same mechanism is used by Relying Party Instances as well.”
RP tracking on subsequent interaction could be achieved by tracking WIA signature, public key or WIA identifier
RP-RP tracking could be achieved by tracking the WIA signature, public key or WIA identifier
RP-Issuer tracking can be achieved by tracking the WIA signature, public key or WIA identifier
Everlasting privacy cannot be achieved if such tracking is possible.
A.2.3.9: “The WTE contains a public key. By including this public key in the WTE, the Wallet Provider attests that the corresponding private key is protected by a certified WSCA/WSCD that has the properties and security posture described in the WTE. The PID Provider or Attestation Provider then asks that WSCA to create a key pair for its new PID or attestation, and to prove that this new key is associated with the key in the WTE”
Issuer-Issuer tracking could be achieved by tracking the WTE public Key. (cf above)
Issuer-Issuer tracking could be achieved by tracking the proof of association. (cf above)
“A Wallet Provider SHALL consider all relevant factors, including the risk of a WTE public key becoming a vector to track the User, when deciding on the validity period of a WTE. A Wallet Provider MAY use short-lived WTEs to mitigate such risks”
Mitigating tracking with short-lived WTEs does not solve the issues related to Issuer-Issuer tracking.
Everlasting privacy cannot be achieved if such tracking are possible.
Annex 3.2: “A data model for ISO/IEC 18013-5-encoded mDLs is fully specified in ISO/IEC 18013-5. No changes need to be made to this data model for an mDL attestation within the EUDI Wallet.” If no changes are made to ISO/IEC 18013-5, user tracking can be achieved using technical identifier like public keys, signatures, salts value and expiry date.
RP tracking on subsequent interaction could be achieved by tracking technical identifiers
RP-RP tracking could be achieved by tracking the technical identifiers
RP-Issuer tracking can be achieved by tracking the technical identifiers
The same problem exists for SD-JWT credential format.
Without any changes in these protocols, everlasting privacy cannot be achieved.
The following comments are linked to privacy, unlinkability and everlasting privacy. GSMA EIG does want to remind the fact that privacy is an important topic and that it shall be addressed properly in the ARF. The definition of unlinkability and everlasting privacy technical concepts shall be added as technical objectives of ARF. GSMA EIG remain concerned about the capacity of the proposed solutions to implement these technical concepts in particular for revocation and on the structural incapacity of ISO mDL and SD-JWT standards to support full unlinkability. (In the rest of this text, the text between quotes in italic is extracted from ARF 1.4)
§ 2.4: In state-of-the-art solutions, a pseudonym is provided by the user himself and not by a third-party pseudonym provider. This is the best way to ensure user privacy. User authentication shall be anonymous by default. Depending on the regulatory and/or legal context, anonymity may be reduced.
§ 3.5: It is stated “QEAA Providers provide information on the location of the services that can be used to enquire about the validity status of the QEAAs, without having an ability to receive any information about the use of the attestations”. However, the implementation of this feature is not detailed. State-of-the-art solutions are available to ensure the validity of an attestation without compromising privacy and in particular while preserving unlinkability.
§ 4.1.1: “Users should have clear control over their data and privacy, with transparent information about what data is being shared and with whom”. We agree with the statement, however when trackable metadata are shared without proper user knowledge / understanding, then we do not consider privacy as being fully addressed. State-of-the-art solutions exist that provide unlinkability.
§ 4.1.3: “The wallet empowers users with granular control over what data is shared and with whom. Transparency is built into the system, with clear explanations of how data is used and protected” The section discusses privacy related to user attributes and data minimization. However, there is no mention of user tracking and impacts of sharing technical identifiers or signature fingerprint, neither any mention of everlasting privacy. Furthermore, the claims about data minimization are not substantiated in the remainder of the document.
§ 4.2.1: We do not think that accounting shall be under the responsibility of the Wallet. We do not understand how such an architecture would comply with the functional accounting requirement and be privacy preserving. There are state-of-the-art solutions for accounting that are privacy preserving and allow flexible business exchanges.
§5.2: With ISO/IEC 18013-5, SD-JWT and SD-JWT VC current specifications, user tracking can be achieved by tracking technical identifiers like public keys, salts value and expiry date or Issuer signature fingerprint. Furthermore, everlasting privacy is not offered at all by the protocols defined in these specifications.
The possible tracking that can be performed and that will put in danger user privacy are the following:
RP tracking on subsequent interactions RP – RP tracking RP – Issuer tracking
§ 6.1.3: “Moreover, Relying Parties may collude with other Relying Parties to do so”. Data sharing / collusion can happen not only between RPs but also theoretically between RP and issuer. It can be involuntary, for instance in the case of hacking, social engineering or corruption. This shall be added in this sentence.
§6.5.3: “Moreover, the WTE contains a WTE public key. During the issuance of a PID or an attestation (see section 6.6.2.3), a PID Provider or Attestation Provider can use this public key to verify that the Wallet Instance is in possession of the corresponding private key” If the cryptographic protocols used for signature do not allow for randomization of the public key and associated signature, Issuer-Issuer tracking can be achieved by tracking the public key. We are waiting for the “whitepaper on WTE” but given the rest of the document, we assume the protocols to be used not to allow public key and signature randomization. For the same reasons, we are also assuming that all this WTE infrastructure will not support everlasting privacy.
§ 6.6.2.3: “The PID Provider or Attestation Provider verifies the signature over the WTE, using the Wallet Provider trust anchor obtained from the Trusted List.” Issuer-Issuer tracking could be achieved by tracking WTE signature. (same comment as above) “Next, the PID Provider or Attestation Provider verifies that the Wallet Instance possesses the private key belonging to the public key in the WTE” Issuer-Issuer tracking could be achieved by tracking the WTE public Key. (same comment as above) “How the PID Provider or Attestation Provider can obtain a so-called proof of association from the WSCD. This proof of association proves that the WSCD described in the WTE protects both the WTE public key and the public key of the PID or the new attestation” Issuer-Issuer tracking could be achieved by tracking the proof of association.
The previous statements also imply that everlasting privacy is not addressed.
6.6.2.4: “The WIA allows PID Providers, Attestation Providers and Relying Parties to verify that the Wallet Instance is not suspended or revoked” Issuer-Issuer tracking could be achieved by tracking WIA signature and public key. (We are looking forward to this “Whitepaper on Wallet Instance Revocation” that shall detail what protocols will be used here). Everlasting privacy cannot be achieved if this tracking is possible.
6.6.3: “The Relying Party Instance verifies the electronic signature or seal of the PID or attestation”.
RP tracking on subsequent interaction could be achieved by tracking the Issuer signature, RP-RP tracking could be achieved by tracking the Issuer signature. RP-Issuer tracking can be achieved by tracking the Issuer signature
“The Relying Party verifies that the PID Provider or Attestation Provider issued this attestation to the same Wallet Instance that provided it to the Relying Party. In other words, it checks that the attestation was not copied or replayed”
RP tracking on subsequent interaction could be achieved by tracking the attestation’ public key RP-RP tracking could be achieved by tracking the attestation’ public key RP-Issuer tracking can be achieved by tracking the attestation’ public key
Everlasting privacy cannot be achieved if such tracking is possible.
RP tracking on subsequent interaction could be achieved by tracking the Issuer signature RP-RP tracking could be achieved by tracking the Issuer signature. RP-Issuer tracking can be achieved by tracking the Issuer signature
Everlasting privacy cannot be achieved if such tracking is possible.
RP tracking on subsequent interaction could be achieved by tracking the identifier or index RP-RP tracking could be achieved by tracking the identifier or index. RP-Issuer tracking can be achieved by tracking the identifier or index
Everlasting privacy cannot be achieved if such tracking is possible. There are state-of-the-art solutions available that can handle non revocation proofs while preserving privacy. Moreover, it is also stated that the validity period is 24h. We do not see any clear justification for having such a long validity period. There are ways to have shorter validity period.
RP tracking on subsequent interaction could be achieved by tracking the WSCD public key RP-RP tracking could be achieved by tracking the WSCD public key RP-Issuer tracking can be achieved by tracking the WSCD public key
Everlasting privacy cannot be achieved if such tracking is possible.
RP tracking on subsequent interaction could be achieved by tracking the signature over the WIA RP-RP tracking could be achieved by tracking the signature over the WIA RP-Issuer tracking can be achieved by tracking the signature over the WIA
Verifies that the Wallet Instance has the private key belonging to the public key in the WIA. This proves that the Wallet Instance is authentic and is provided by the trusted Wallet Provider.
RP tracking on subsequent interaction could be achieved by tracking the public key in the WIA RP-RP tracking could be achieved by tracking the public key in the WIA RP-Issuer tracking can be achieved by tracking the public key in the WIA
Everlasting privacy cannot be achieved if such tracking is possible.
RP tracking on subsequent interaction could be achieved by tracking WIA signature, public key or WIA identifier RP-RP tracking could be achieved by tracking the WIA signature, public key or WIA identifier RP-Issuer tracking can be achieved by tracking the WIA signature, public key or WIA identifier
Everlasting privacy cannot be achieved if such tracking is possible.
Issuer-Issuer tracking could be achieved by tracking the WTE public Key. (cf above) Issuer-Issuer tracking could be achieved by tracking the proof of association. (cf above)
“A Wallet Provider SHALL consider all relevant factors, including the risk of a WTE public key becoming a vector to track the User, when deciding on the validity period of a WTE. A Wallet Provider MAY use short-lived WTEs to mitigate such risks” Mitigating tracking with short-lived WTEs does not solve the issues related to Issuer-Issuer tracking.
Everlasting privacy cannot be achieved if such tracking are possible.
RP tracking on subsequent interaction could be achieved by tracking technical identifiers RP-RP tracking could be achieved by tracking the technical identifiers RP-Issuer tracking can be achieved by tracking the technical identifiers
The same problem exists for SD-JWT credential format.
Without any changes in these protocols, everlasting privacy cannot be achieved.