The trust assumptions of the ARF state that colluding parties are a privacy problem and explicitly provides Relying Parties as an example (emphasis added)
Relying Parties may try to violate a User's privacy by tracking the User by processing their data without lawful grounds. They can do so, as an example, by comparing without lawful grounds a signature, hash, or public key value present in an attestation that the User presents to them to similar values known to the Relying Party. Moreover, Relying Parties may collude with other Relying Parties to do so.
So why shouldn't Relying Parties not also try to collude with Wallet Providers?
The "classic" security/threat model of related technologies and anonymous credential systems (such as BBS+ for example) usually describes three roles:
Signer/Issuer, this would be the Identity Provider (IdP), sometimes also referred to as PID Provider (PP), in the context of ARF
Prover/Holder, this would be the Wallet Instance (WI) acting on behalf of the user in the context of ARF
Verifier, this would be the Relying Party (RP) in the context of ARF
In addition to these roles, the ARF defines another role, namely that of the Wallet Provider (WP).
According to ARF the WP has the following responsibilities:
Note that the initial verification and authenticity of the Wallet Solution provided by a WP to a user, is either left to the official app store (i.e., implicitly trusted device manufacturers and subsystems providers), or in the responsibility of the user.)
on request of PID provider (PP) in case user has died WIRevocation_11
To implement Wallet Instance revocation, the Wallet Instance Attestation (WIA) is used.
The Wallet Provider SHALL be the only party capable of execution the revocation or suspension of a WIA:
... the Wallet Provider of a given WIA SHALL be the only party in the EUDI Wallet ecosystem capable of executing the revocation or suspension of that WIA. VCR_01
This in turn means, that the Wallet Provider is always capable of attributing a WIA to its activated Wallet Instance and thus link it to its user. Moreover, PID/Attestation Providers and RPs should be able to check if a certain WIA has not been revoked:
6.6.2.4 [...] during activation of a Wallet Instance, issues a Wallet Instance Attestation (WIA) to the Wallet Instance. The WIA allows PID Providers, Attestation Providers and Relying Parties to verify that the Wallet Instance is not suspended or revoked.
WIRevocation_17: A Wallet Instance SHALL be able to transfer the WIA to PID Providers and Attestation Provider during the issuance of a PID or attestation and to Relying Parties during the presentation of attributes.
This means PID Providers and RPs have to, rely on the validity of a WIA (which is valid for less than 24h), or check for revocation of that specific WIA with the Wallet Provider. So the WIA is either ephemeral (short lived <24h), or long lived and requires a revocation check on every use of the Wallet Instance when interacting with an PP or RP.
So lets see how the issuance of the WIA is described in Annex 2 Topic 38:
WIRevocation_01: To enable a Relying Party or an Attestation Provider to verify the authenticity and revocation status of a Wallet Instance it is interacting with, a Wallet Provider SHALL issue one or more WIAs to the Wallet Instance during the activation phase of a Wallet Instance
Here the ARF explicitly allows to only issue one WIA during the activation, which would effectively make the WIA a static tracking cookie if implemented that way. This problem might have been noticed and led to requirement WIRevocation_04 which should prevent this:
WIRevocation_04: The Wallet Provider SHALL manage the issuance processes for WIAs in such a way that the WIAs cannot be misused by colluding Relying Parties (and Attestation Providers) to track a User.
But beyond this requirement, the ARF does not provide any guidance on how this should be done.
Moreover, even if the Wallet software uses a different ephemeral (validity <24h) WIA with every RP and PP, the fundamental problem stays unsolved: Namely that collusion between any party (RP or PP) with an WP will always allow to link a WIA to a user, thus violating unlinkability.
Suggested Mitigation:
Do not treat the WP as a special party, but treat the WP as yet another issuer/IdP that issues an attestation over the successful activation of a Wallet Instance (comparable with the WIA). The encountered problems (unlinkability and revocation) are the same as in the "classic" scenario where there are only issuers, provers/holders, and verifiers. The only difference is that, as a first step, the holder always verifies that they have a valid attestation for a WP for their wallet instance, for example, before requesting another attestation from another issuer (PP) or before verifying any other PID to an RP.
Therefore, if unlinkability and revocation can be solved in the "classic" case, for example by using a scheme such as BBS+, then the problem of unlinkable activation and revocation of a Wallet Instance can be solved as well, as it reduces to the classic case.
The trust assumptions of the ARF state that colluding parties are a privacy problem and explicitly provides Relying Parties as an example (emphasis added)
So why shouldn't Relying Parties not also try to collude with Wallet Providers?
The "classic" security/threat model of related technologies and anonymous credential systems (such as BBS+ for example) usually describes three roles:
In addition to these roles, the ARF defines another role, namely that of the Wallet Provider (WP). According to ARF the WP has the following responsibilities:
Wallet Instance revocation can happen,
To implement Wallet Instance revocation, the Wallet Instance Attestation (WIA) is used. The Wallet Provider SHALL be the only party capable of execution the revocation or suspension of a WIA:
This in turn means, that the Wallet Provider is always capable of attributing a WIA to its activated Wallet Instance and thus link it to its user. Moreover, PID/Attestation Providers and RPs should be able to check if a certain WIA has not been revoked:
This means PID Providers and RPs have to, rely on the validity of a WIA (which is valid for less than 24h), or check for revocation of that specific WIA with the Wallet Provider. So the WIA is either ephemeral (short lived <24h), or long lived and requires a revocation check on every use of the Wallet Instance when interacting with an PP or RP. So lets see how the issuance of the WIA is described in Annex 2 Topic 38:
Here the ARF explicitly allows to only issue one WIA during the activation, which would effectively make the WIA a static tracking cookie if implemented that way. This problem might have been noticed and led to requirement
WIRevocation_04which should prevent this:But beyond this requirement, the ARF does not provide any guidance on how this should be done. Moreover, even if the Wallet software uses a different ephemeral (validity <24h) WIA with every RP and PP, the fundamental problem stays unsolved: Namely that collusion between any party (RP or PP) with an WP will always allow to link a WIA to a user, thus violating unlinkability.
Suggested Mitigation: Do not treat the WP as a special party, but treat the WP as yet another issuer/IdP that issues an attestation over the successful activation of a Wallet Instance (comparable with the WIA). The encountered problems (unlinkability and revocation) are the same as in the "classic" scenario where there are only issuers, provers/holders, and verifiers. The only difference is that, as a first step, the holder always verifies that they have a valid attestation for a WP for their wallet instance, for example, before requesting another attestation from another issuer (PP) or before verifying any other PID to an RP.
Therefore, if unlinkability and revocation can be solved in the "classic" case, for example by using a scheme such as BBS+, then the problem of unlinkable activation and revocation of a Wallet Instance can be solved as well, as it reduces to the classic case.