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