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
431 stars 60 forks source link

[Credential Revocation] Continuous Monitoring of Credential Status #208

Open peppelinux opened 5 months ago

peppelinux commented 5 months ago

There are cases where the Verifier only needs to check the revocation status of a Digital Credential at the time of presentation, and therefore it should not be allowed to check the status of a Digital Credential over time due to some privacy constraints, in compliance with national privacy regulations.

For instance, consider a scenario where a Verifier's repeated access to a status list, such as the one defined in [draft-ietf-oauth-status-list] to check the revocation status of a Digital Credential could be deemed as excessive monitoring of the End-User's activities.

e.g.: Let's assume a long-lived affiliation credential is presented to a private Relying Party (RP). By continuously monitoring the credential's status, if it gets revoked before its expiration, this could implicitly reveal changes in the user's affiliation status.

This could potentially infringe upon the End-User's right to privacy, as outlined in [ECHR-ART8] and in the the European Union's General Data Protection Regulation [GDPR], by creating a detailed profile of the End-User's Digital Credential status without explicit consent for such continuous surveillance.

ivanek666 commented 5 months ago

You presume, that there will be an ability for RP to check the credential status in some kind of ledger. But it is possible that Member State will use only PKI scheme with no ledger, thus there will be no ability for RP to check the status of a Digital Credential.

peppelinux commented 5 months ago

ledger is not relevant to this issue

the point I have raised is that revocation list allow revocation monitoring over time, while the revocation should be checked only during the presentation of the credential and limited for the scope of the presentation (such as the user authentication)

status list are inspired by PKI CRLs (such as the ones defined in RFC5280) and even if better than CRL lists they inherit the same approach, for which some considerations was listed in the issue below:

https://github.com/peppelinux/draft-demarco-oauth-status-assertions/issues/50