search

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
369 stars 55 forks source link

Possible conflict between requirement 6.3.4.7.3.ii and some of the revocation mechanisms presented in the ARF #147

Open joelposti opened 3 months ago

joelposti commented 3 months ago

In section 6.3.4.7 of the ARF there is the following requirement:

3.ii. Any attestation identifiers and other values used for enabling revocation checking SHALL NOT allow Relying Parties to correlate (and thus track) the User, even if they collude with other Relying Parties.

Section 6.3.4.8 of the ARF presents a number of possible revocation mechanisms such as Attestation Status List and Online Attestation Status Protocol. It is difficult to see how the presented mechanisms, with the exception of the short-lived attestations mechanism and perhaps the OASP stapling, fulfill the requirement because they rely on the fact that the attestation has some sort of revocation-related identifier. That identifier can be used by the Relying Party for correlating the User.

Should the requirement be relaxed or dropped? Or should more advanced revocation mechanisms be used?

If more advanced revocation mechanisms are used it could be that the requirement 6.3.4.7.8 gets in the way next.

  1. The revocation mechanism SHOULD be mature, meaning that many different parties have experience with implementing and operating the mechanism.
samuelmr commented 2 months ago

Would it make sense to have different kinds of attestations (credentials) with different revocation mechanisms?

If you present an attestation of your bank account number or a credential proving that you own a car with a specific license plate number, it doesn't make much sense to set strict requirements for non-traceability of the revocation, since the verifiers get identifying information as attribute values. The same, of course, applies to use cases where the user uses their PID for authentication.

The issuer of a credential could label the credentials they issue using a three-tier classification:

  1. non-traceable (the credential doesn't contain uniquely identifying attribute values, including revocation data)
  2. potentially traceable (the credential contains selectively disclosable attributes that can be used for tracking if disclosed)
  3. traceable (the use of the credential can be tracked by colluding verifiers since it may contain identifying information
pinamiranda commented 1 month ago

Thank you for bringing this to our attention. The requirement 6.3.4.7.3.ii will be removed in the next version of ARF (ARF v1.4). If you encounter any further issues, please don't hesitate to let us know.

joelposti commented 2 weeks ago

Thank you! Looks like the requirement has been removed from ARF 1.4. This issue can be closed.