dvorak42
commented
1 year ago The registration requirement is a result of a few considerations:
1) A technical need to have a system of preventing the issuer from presenting targeted keys to different users (the key consistency problem in privacypass), and to enforce key rotation limits globally to avoid frequent key rotations. Initially (see consideration 3) we expect that any issuer that can maintain the technical requirements of registration will be accepted, our current registration requirements (https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md) is purely technical and an acknowledgement of having to refresh their registration after a period of time. We're hoping to increasingly automate the registration process over time where once an issuer provides their information, automated systems will verify the endpoints/keys before adding it to the commitment fetcher. Long-term a more consistent key consistency story/service would be nice, perhaps some sort of key transparency system, however that would need buy-in from other UAs/ecosystem for spinning up such a service or other key consistency system.
2) As we expect this API to evolve and change somewhat as the protocol is further standardized and other changes are made as other UAs help standardize this API, this registration process is also intended to give a way for communication with active issuers to help with future updates.
3) Finally, while we hope that the technical limitations of the API will prevent bad actors/uses of the API, having this registration/re-registration requirement lets us re-evaluate the sorts of requirements/limitations on issuers if it becomes necessary to mitigate/prevent abuse of the API.
I'll add a spec-work tag to this issue to track adding a note to the spec to reference the UA-specified behavior on "registering" issuers before websites can use them.
etrouton
martinthomson
thegreatfatzby
I had somehow completely missed that there was some intent to have issuers register with browser vendors.
That's problem 1: the spec isn't clear about this at all. I had assumed that sites would pick (and maybe commit to) an issuer of their choice. After all, the issuer identity is part of the URL that is provided as an argument to
fetch().Problem 2 is the bigger one: is this a good idea? Apple does it for PAT too, but that doesn't make it good.
I think that it isn't good and anything that depends on registration needs really careful consideration of alternatives, because building the necessary safeguards (technical, procedural, and governance) is icky.
There are a ton of reasons why using a legally-enforceable contract or similar agreement makes it easier to deploy something like this, but it means that Google now becomes a gatekeeper for the operation of the system. Google has to deal with a bunch of interesting governance questions about how they approve issuers, what rules they apply, how those rules are enforced, and so on. See also CA/BF[^1].
[^1]: I mention CA/BF because there are strong similarities. There we have different policies from different browsers, but because the system somehow manages to operate despite that. Browser policies there tend to be mostly compatible, but it is the CA/BF and the people that work there that produce that consistency that allows the system to function. CA/BF is also a special case and I have strong reservations about the viability of trying to make another system like it.
It means that other browsers need to stand up their own system as well. Then, if there are differences (there will be), sites will shoulder the cost of having to interoperate with browser-specific issuer sets. The anti-competitive effects that come from this seem like they might be tricky to navigate (the usual disclaimers apply). There might even be geopolitical consequences. I don't say this to be alarmist, but because these are potential consequences of building something like this.