Guidance on registries?

[wseltzer]

Hi TAG, in the context of the Digital Credentials API, we've gotten a detailed issue with arguments against the use of a registry for protocol elements. The FedID WG will consider these points when deciding whether/how to use registries for our specs. I'm sending the general discussion over to TAG to see if there's existing guidance. Thanks!

[jyasskin]

I believe the TAG doesn't have any existing guidance on registries. I'll give my thoughts here as a starting point for discussion, but none of this post is a committed position or informed by discussion with the rest of the TAG.

First, though, I'll describe my understanding of the Digital Credentials situation to double-check that I have it right.

I believe this is about the registry defined in https://www.w3.org/TR/digital-credentials/#protocol-registry. That registry has a stricter-than-usual list of entry criteria:

1. MUST be standardized at a consortium the W3C liaises with
2. MUST be defined in a specification which is freely and publicly available at the stable URL listed in the registry.
3. MUST define a representation, as either a WebIDL dictionary or a JSON object, of the exchange protocol request structure (i.e., the dictionary which defines the semantics and validation of the DigitalCredentialGetRequest's data member) and the issuance protocol request structure (i.e., the dictionary which defines the semantics and validation of the DigitalCredentialCreateRequest's data member).
4. MUST define a representation, as either a [WebIDL] dictionary or a JSON object, of the exchange protocol response structure (i.e., the dictionary which defines the semantics and validation of the DigitalCredential's data member.
5. MUST define validation rules for members of the request and response structures.
6. MUST have undergone privacy review by the W3C's Privacy Working Group and Federated Identity Working Group.
7. MUST have undergone security review by the Security Interest Group.
8. MUST have implementation commitment from at least one browser engine, one credential provider/wallet, and one issuer or verifier (depending on the protocol type). Each component MUST be from independent organizations.
9. MUST have formally recorded consensus by the Federated Identity Working Group to be included in the registry.

Where 1 and 6-9 feel unusual. I'll call these the "higher bar" requirements below. Unusual doesn't mean unjustified, of course. Items 2-5 are a requirement for the registered protocol to be adequately specified, and I'll call them the "specification requirements".

---

Thank you @jandrieu for the structured list of issues, which I'll follow here:

Act as a barrier to adoption

The argument here isn't really about adoption of the main specification, but rather that these requirements might mean that only a subset of the world's developers can reasonably extend the specification. However, there's no requirement in the spec that the registry must only refer to English specifications. Now, as a global standards body, we're in the business of pursuing globally interoperable implementations, and that means that the implementers need to be able to read the specifications. So it would make sense to require that registered protocol specifications be translated into some common language, and there is an implicit requirement for that, since someone attached to the W3C needs to be able to evaluate the registration requirements for the spec.

Once the specification is translated for other implementers, I think the "higher bar" requirements are also reasonably easy to pass.

Squelch innovation.

There is a required registry of websites: DNS, and IP addresses underneath it. That's equivalent to the "specification requirements", since in order to interoperate with a protocol, other implementers have to be able to find its definition.

The "higher bar" requirements are likely to reduce innovation, but I believe the justification for them is meant to be that not all innovation is positive. We don't want people to innovate a protocol that on the whole causes harm to society, reduces people's security or privacy, or takes credentials out of people's individual control.

Propagate Western technocolonialism

If the structure of the W3C and the main Digital Credentials spec take a too-Western perspective, that's not something that's going to be fixed by leaving a protocol field undefined. People with these other perspectives need to bring specific bugs. I think it doesn't entirely serve this purpose right now, but I'd like the W3C Chapters program to act to help translate these perspectives into forms that WGs can understand. (cc/ @lianqi)

Don't actually improve the security of the system

This is only about the "higher bar" requirements, since the "specification requirements" don't attempt to improve security.

It seems strictly better to have a shared review process where everyone involved can pool their resources to do a security review, rather than expecting every potential adopter to do their own review. It's true that the shared assessment might not cover everyone's needs, but then the unusual implementer can build on top of that assessment, rather than needing to start from scratch.

Put the W3C in an inappropriately elevated position

This is only about the "higher bar" requirements, since the "specification requirements" only ask the W3C to serve as a bookkeeper and check that specifications facilitate interoperability, and that's appropriate for a standards body.

I do think it would be reasonable for the W3C to outsource some of the privacy and security review to a body that's more expert in those areas, if such a body is willing to volunteer. Is there any?

Are primarily a first-mover advantage that controls and limits adoption, rather than advance it

Adoption is not materially affected by needing to pick a different string name. On the other hand, ambiguity about which sub-protocol is named by a protocol field does cause bugs, which harm adoption.

Create a novel and unnecessary attack surface

Nothing is novel about registries. I'd need more detail about how an attacker compromises a system by getting inappropriate changes made to a registry. However, it looks like the proposed alternative is for the protocols to be named by GUIDs, and their definitions looked up in a search engine, which allows the same attack via googlebombing.

---

Overall, I think we should endorse registries with requirements that specifications in them promote interoperability. I have less of an opinion about the "higher bar" requirements, but I haven't seen anything that makes me doubt that the WG knows its domain and the need for those requirements in that domain.

[martinthomson]

I agree with @jyasskin here. The point of a registry is to allow choice at a certain point in the protocol. It is a substitute for just specifying a single thing that fits a given slot. The decision to allow a choice is one that recognizes a set of reasons for that choice.

DC seems to justify the choice to have an extension point using things I think are going to be bad for interoperability or user agency -- having multiple protocols means that either sites are going to have to support multiple protocols or people are going to be unable to use credentials they have -- but that's a decision I can understand and respect.

[jyasskin]

Discussed at the F2F: https://github.com/w3ctag/meetings/blob/gh-pages/2025/09-Hong-Kong/09-15-minutes.md#when-and-how-are-registries-appropriate (This link might move at the end of the week; I'll try to update it if so.)