🦗 🦗 🦗 ... this is a multifaceted issue, for sure, but my intuition is that there are a lot off different, and sometimes contradictory, expectations about what a registry will achieve. Yet this registry as currently manifest and likely reasonably achievable variants thereof are probably unable to meet many/most of those expectations. Meanwhile the general issue/question of a registry here seems to be holding up or detracting from progressing things within this subgroup of the WG. As such, I'm tentatively supportive of removal.

After much consideration, and considering that this is a complex issue as Brian says, I would propose:

• Keeping the registry but with non-collision/non-duplication functions, to satisfy what the charter says: “protocol-agnostic”
• For security and privacy issues, which are important and fundamental considering the context, adding a section to the specification where we put the implementation requirements (e.g., on EME), to cover the various issues both on the implementation side of the DC API itself and for the other levels of the ecosystem

Closing in favor of #401

Context:

• Paths towards resolution on the registry [TPAC] #396 (comment)
• Paths towards resolution on the registry [TPAC] #396 (comment)