delegation-oriented api requires "consequence-free" - must be free of entropy bits which could enable global tracking when IDPs and RPs collude

[will-bartlett]

In the explainer, it says:

The delegation-oriented model is very compelling as an end-state for WebID because it solves both tracking problems. Because it does, it doesn't have any unintended tracking consequence.

Because it is consequence-free, we expect it to be permission-less (the best permission is that one that isn't needed) and comparably better for users with formulations that impose on the user to make a determination on the consequences of being tracked.

NB: "Colluding" IDPs and RPs are the norm in many circumstances because IDPs distribute JavaScript SDKs that RPs run on their sites. The code running on the two "colluding" parties is often owned by the same organization.

I am not sure the proposed designs and diagrams for the delegation-oriented flow achieve the ambitions in the explainer. I worry that, even in the most privacy-preserving forms (directed identifiers) they enable colluding IDPs and RPs to undermine the proposed privacy guarantees and obtain global identifiers for the user. If so, enabling a delegation-oriented model on a permission-less basis would undermine rather than promote user privacy.

The key problem is the entropy. Baselines:

• 128 or 256 bits of entropy is what is commonly recommended for "un-guessable" values (e.g. onetime codes) by security experts and cryptographers
• 32 bits is enough to identify each human online uniquely
• 8 bits is useful for tracking, because it can be combined with other values.

The delegated model relies on the user agent presenting the relying party a token that contains a certificate signed by the issuer that contains the directed user identifier. However, some digital signature schemes (e.g. RSAPSS, standardized in JWA as PS256) rely on random data. By using a digital signature scheme with random data, but including a global user identifier as some part of the random data instead of fully random random data, and by making this pattern known to RPs, colluding IDPs and RPs could share global user identifiers. Outside of signatures, a IDP interested in collusion could also embed data e.g. in the order of fields in the certificate (e.g. if an order-independent format like a JWT is used) or in the least significant bits of a high precision valid-until timestamp. Finally, digital signature schemes must support rollover - keys expire and get replace - so IDPs could embed entropy in the choice of which key they use to sign a given certificate.

In order to provide the desired guarantees, all certificate data (including timestamps) must be generated by the user-agent AND the IDP must be limited to digital signature algorithms that do not use randomness AND some mitigation must prevent the IDP from using a unique signing key per user in the guise of supporting certificate rollout - this last requirement, in particular, seems especially difficult to satisfy in practice - IDPs could assign users to a cohort and sign certificates for each cohort with a different key in a way that is difficult to distinguish on the client from e.g. a service having one signing key per cloud region (a very normal setup). Without satisfying this entropy-free / no-side-channel requirement, rather than moving the web towards more privacy, I fear that the delegation oriented API instead enables silent tracking of users by colluding RPs and IDPs once they have consented to use an IDP.