Split the DID Specification Registries into separate documents

[msporny]

There was a suggestion on the last telecon to split the registries into separate documents. This issue is intended to track that request and create a proposal that could achieve consensus and be acted upon by the Editors. Options include:

• Keep the current structure.
• Split into multiple registries, but keep everything in one Github repository.
• Split into multiple registries, each with its own Github repository, and separate W3C Technical Report publication location.

This is related to #565.

[ChristopherA]

So clearly there is a need to at least split out §14: DID Methods from the rest.

I could make an argument that that is the only split needed. But if we do more, it is not as clear to me where the other dividing lines are.

At first glance, splitting out every section into a separate registry document probably overkill. One possible organization is to split into 5 portions:

• DID Properties (current §5: Property Names, §6 Property Values)
• DID Representations (current §7: Representations, §8 Representation Specific Entries)
• DID Metadata (current §12: DID Document Metadata, §13 Parameters)
• DID Resolver (current §9: DID Resolution Options, §10: DID Resolution Metadata, §11: DID Dereferencing Metadata)
• DID Methods (current §14)

My only reservation about this is that some smaller lists within a section might be more (or less) security sensitive, and thus have different registration and review requirements compared to the rest of the section. For instance, in §5: Property Names, there is §5.4.1: Service Endpoints, which probably should be much less restrictive to add to then adding new §5.2 Verification Relationships.

[msporny]

I agree with @ChristopherA's proposal above.

Regarding the mechanics of how that could work, we could:

• Keep index.html as a reference with links to the other registries. We can keep the Registration Process here for now and state that all registries must follow that process (and point each registry back to the registration process to ensure that there is no confusion).
• Create a new file, such as did-methods.html, for each registry.
• Set up Echidna to publish all registry files (this is an easy change, AFAIK).

At a minimum, I believe that's all we need to do to enact @ChristopherA's proposal above.

[msporny]

I would also like us to consider:

1. Renaming the current TR location to "/TR/did-specifications/" (it will be clear that it's a registry by the ReSpec document template used).
2. Make it clear that we are just providing documentation to ease interop and not "policing" whether or not other registries can exist elsewhere. That is, we do not desire to police other organizations creating DID registries of their own.

[wip-abramson]

Wondering if this can be closed now, given the migration to did-extensions is complete

[ChristopherA]

Wondering if this can be closed now, given the migration to did-extensions is complete

@msporny ?

[decentralgabe]

This is complete.