Adding things to the registry

[OR13]

See also:

w3c/did#188
w3c/did#187

Should I just open PRs to move the JSON Schema and Context definitions from DIF here?

https://github.com/decentralized-identity/context

Is there strong opposition to using JSON-Schema for JSON only did document validation?

Do we want interoperability tests mixed in the core registry repo?

[OR13]

@msporny can I be a code owner / editor of this repo so I can fix things faster? are we going to have PRs sit open for weeks for every property change?

[msporny]

@msporny can I be a code owner / editor of this repo so I can fix things faster? are we going to have PRs sit open for weeks for every property change?

I'm happy to have you as an co-editor, +1000 to that.

All normative changes to this document (which is basically everything that we're going to put in the document) will have to go through PRs and may sit open for weeks because this will become an official registry of the group and WG participants are going to have things to say about a lot of stuff.

We could probably move quickly to get the registry into shape, since this is only an Editor's Draft, but will have to get approval from the group to go into that mode... if we don't, it'll create political turmoil (again) and people will assert that the Editor's are abusing their privileges.

All that said, I don't have the ability to make you a code owner / editor - @iherman does and can only do so once approved by the chairs @brentzundel and @burnburn... possibly after conferring with the WG.

All that said, in the meantime, PRs welcome... and we'll just have to see how the WG reacts to them. Also note that the structure of the registry is something I felt might work initially, but is possibly flawed (and I haven't had enough bandwidth to think through all the ways it's not going to work yet).

[msporny]

Should I just open PRs to move the JSON Schema and Context definitions from DIF here?

Possibly, the group didn't discuss if the registry is going to contain the JSON Schema files and Context definitions yet. The other place we could put those items, which is where it exists today, is in the did-core spec repo.

Is there strong opposition to using JSON-Schema for JSON only did document validation?

There is no consensus on doing that yet, but it seems like a reasonable path forward.

Do we want interoperability tests mixed in the core registry repo?

No, absolutely not. There is a separate test suite for that (that needs to be moved over to W3C... which typically doesn't happen until we are close to transitioning into CR): https://github.com/w3c-ccg/did-test-suite/

[OR13]

I worry that by not showing DID Methods Passing or Failing WRT the registry... there will be little incentive to follow the did core spec, as is currently the case... I'd also like to be able to see how when PRs are merged in the registry that did methods become passing... we should know that a registry change will break interop or fix it on the PR... in integration tests.

I won't open a PR until I have some idea of what a "passing" registry change is... we need to enforce machine verification of the registry at the PR level.... I can pull the test suite from the W3C here and use it as a starting point if thats desirable.

obviously the DIF registry has what I am describing working today, with definitions for all properties. .. If we can't figure out how to make the W3C as good or better, there is little incentive to contribute here... I'm willing to do all the work to get us there, I just need permission.

Changes to this registry could result in broken interoperability, thats a condition that should be guarded against in software.

[iherman]

All that said, I don't have the ability to make you a code owner / editor - @iherman does and can only do so once approved by the chairs @brentzundel and @burnburn... possibly after conferring with the WG.

Indeed.

[OR13]

This issue will be survived by its children:

• Add Github actions for testing machine readable definitions of registry #8
• Fix JSON-LD Context Links #3