Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split the DID Specification Registries into separate documents #568

Closed
msporny opened this issue Jul 19, 2024 · 6 comments
Closed

Split the DID Specification Registries into separate documents #568

msporny opened this issue Jul 19, 2024 · 6 comments
Assignees

Comments

@msporny
Copy link
Member

msporny commented Jul 19, 2024

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.

@msporny msporny changed the title Split the registries into separate documents Split the DID Specification Registries into separate documents Jul 19, 2024
@msporny msporny self-assigned this Jul 19, 2024
@ChristopherA
Copy link

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
Copy link
Member Author

msporny commented Jul 19, 2024

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
Copy link
Member Author

msporny commented Jul 21, 2024

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
Copy link

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

@ChristopherA
Copy link

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

@msporny ?

@decentralgabe
Copy link
Contributor

This is complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants