Paths towards resolution on the registry [TPAC]

[timcappalli]

Based on the discussion on the 2025-10-29 call (which was based on all of the previous discussions), this is an attempt to map out potential paths forward, to discuss at TPAC 2025.

This list is deliberately exhaustive.

Current State

• The spec has a protocol registry, and each protocol must go through W3C privacy and security review to be added to the registry, as defined in the spec
• The security and privacy requirements in the spec are closely tied to the registry.

Option 1

• Drop registry from the spec completely
• Change current security and privacy requirements that map to the registry, to be protocol implementation recommendations

Option 2

• Drop registry from the spec completely
• Change current security and privacy requirements that map to the registry to be protocol implementation requirements (which can be used by other organizations as part of certification)

Option 3

• Change the registry to a "list of known protocols" (protocol identifier and spec link) with no normative requirements outside of avoiding identifier collisions
• Change current security and privacy requirements that map to the registry to be protocol implementation recommendations

Option 4

• Change the registry to a "list of known protocols" (protocol identifier and spec link) with no normative requirements outside of avoiding identifier collisions
• Change current security and privacy requirements that map to the registry to be protocol implementation requirements (which can be used by other organizations as part of certification)

Option 5

• Change the registry to a "list of known protocols" (protocol identifier and spec link) with no normative requirements outside of avoiding identifier collisions
• Change the current security and privacy requirements to only talk about considerations for the API surface itself
• Move ecosystem / protocol security and privacy requirements into its own document/spec

Option 6

• Drop registry from the spec completely
• Change the current security and privacy requirements to only talk about considerations for the API surface itself
• Move ecosystem / protocol security and privacy requirements into its own document/spec

Option 7

• Drop registry from the spec
• Normatively reference OpenID4VP 1.0 (signed, unsigned, multisigned), OpenID4VCI, and ISO 18013-7 Annex C in the spec
• Requests with unsupported protocols are ignored

Related issues

• Is a registry needed? #345
• user agents should limit to protocols listed in the registry that meet the group's requirements #288
• Can we require protocols to support unlinkable revocation? #280
• registration of and commitment to a particular use case and purpose #266
• Protocol registry: specification availability #257
• Protocol registry: royalty free requirement #256
• Protocol registry: Reviewing is not sufficient #255
• Registry requirements should not use RFC2119 language #240
• privacy review for registry inclusion #226
• Document WG security review requirements for protocols #215
• [Registry] Re-evaluate "freely available" requirement #214
• Add ISO/IEC 18013-7 Annex C to protocol registry #213
• Add OpenID for Verifiable Credential Issuance (OpenID4VCI) to registry #212
• Add OpenID for Verifiable Presentations (OpenID4VP) to registry #211
• Describe trust signals in protocol registry #136
• Add examples of usage in registry #69

[marcoscaceres]

Irrespective of option we pick, we need to keep the recommendation for how to structure the identifiers to conform to IDL enum and the TAG’s naming things guidelines.

[marcoscaceres]

Don’t forget to add Option 7 (or Option 0), which is to maintain what we currently have even if just for completeness.

We should seek input from the TAG also to help resolve this issue.

[hlflanagan]

@marcoscaceres I’m unclear as to exactly what we’re asking the TAG at this time. Are we basically asking when w3ctag/design-principles#596 Will be done?

[marcoscaceres]

Sorry for not being clear. w3ctag/design-principles#596 doesn't need to be done for the TAG to provide guidance if to include the registry and in what capacity (the options above). w3ctag/design-principles#596 can help as a guide though, as it largely has TAG consensus.

At the same time, it is ultimately the WG that gets to decide how we proceed. But it is, nevertheless, important to get a broad set of opinions/inputs for us to make the right decision on how to proceed.

The formats have a massive implications on the privacy, security, and societal impacts of this technology - so it's important that we make an extremely informed decision that include a wide range of stakeholders before we make a decision. And, given the significance, we are able to clearly articulate why we made that decision when people come asking.

[simoneonofri]

Hi @timcappalli, thank you for summarising the options!

Regarding security and privacy requirements/recommendations. We can also provide them as a self-assessment questionnaire upon request (kind of like we do for recs), linking their answers to the registry entry, depending on whether the requirements are met.

Please note this is a specific option, but we can use it when one of the options has "Change current security and privacy requirements..."

[npdoty]

If we are being exhaustive on options: in #288 I suggested that we keep the registry with a privacy and security review process, and also add requirements that UAs should only implement protocols that went through that review for the registry.

[npdoty]

I'm not clear on the recommendations vs requirements difference (Option 1 vs 2, and 3 vs 4). All W3C normative requirements are still just published as Recommendations, all specs are for voluntary implementation.

I wouldn't see the value in having non-normative advisory text where we currently have requirements. It doesn't make it easier for anyone to ship anything, but it does make it less clear when someone else is evaluating the requirements and seeing if it satisfies them or not.

[timcappalli]

Option 7 added during TPAC 2025 (2025-11-14)

[martinthomson]

Requests with unreferenced protocols are dropped

The challenge here is how you manage the addition of new protocols. "unreferenced" could be interpreted as fixing the set of protocols in time. The way to manage this is to define an error code for an unsupported protocol. That error needs to be the same whether the protocol is listed and not supported or whether the protocol is introduced.

As Rick is saying right now, unsupported protocols are ignored. If the intersection of the sets of supported protocols and protocols that are passed to the API, you will get an error.

[timcappalli]

2025-11-14 TPAC meeting: consensus on option 7

[RByers]

As Rick is saying right now, unsupported protocols are ignored. If the intersection of the sets of supported protocols and protocols that are passed to the API, you will get an error.

Clarification: If the intersection of the sets of supported protocols and protocols that are passed to the API is empty, you will get an error.

[RByers]

Next step: Tim to propose draft PR and Rick to do initial review ASAP.

[wseltzer]

Minutes from TPAC