Did-core: Consider adding a well-defined method-specific section to the DID Document

[cboscolo]

I realize that there is a long debate taking place regarding the use of JSON-LD (https://github.com/w3c/did-core/pull/142), so the timing of this suggestion may cloud that issue. But in the scenario where we don't want to rely on JSON-LD to avoid on name collisions in the DID Document between DID methods, I propose we add a specific section to that DID Document where a DID method has full control over the JSON names it chooses.

For example, consider a did method named foo (did:foo:123abc456zyx):

"method-data" : { "anything": "that is specific to the foo method" }

Or a did method named bar (did:bar:123abc456zyx):

"method-data" : { "anything": "that is specific to the bar method" }

This gives methods a safe playground to do anything they want in the DID Document, without fear of colliding with other methods.

[OR13]

This is sorta a way to use the concept of a DID Method specific @context without JSON-LD. You are proposing a field which is reserved for DID Method specific values.

In the current spec, this is possible for arbitrary values that do not collide with the core context.

In your proposed property (which I assume is top level). You can put all your method specific data there without worrying about interop issues... however, as @selfissued discussed here: https://github.com/w3c/did-core/pull/142#issuecomment-565081597

The camp that does not want to process JSON-LD is probably also not a fan of explicit versioning which is equivalent to including a method-data property...

I assume you believe the method-data should be @type: @json in the did core spec?

[cboscolo]

In your proposed property (which I assume is top level).

Yes. I am proposing that the Spec specifies this top-level name be used the way I described.

The camp that does not want to process JSON-LD is probably also not a fan of explicit versioning which is equivalent to including a method-data property...

I disagree with classifying method-data as way to do versioning. It is a way to do name-spacing that is, IMO, consistent with the decentralized nature of how DIDs and DID methods should work.

I assume you believe the method-data should be @type: @json in the did core spec?

Yes.

[talltree]

@cboscolo Chris, it's no coincidence that your proposal matches the mechanism currently in the DID spec for namespacing of method-specific matrix parameters. And for that reason I think it's a sound suggestion. Since DID method names MUST be namespaced, it's a very clean way of separating method-specific DID document properties.

[OR13]

I suppose you could use this matrix param, and put a whole DID Document in it... and then always use did's with the matrix param present.

This property would be forced to be treated as normal json.

Its actually similar to my proposal regarding treating DID Documents with less than 2 contexts as vanilla JSON, just using different indicators..

https://github.com/w3c/did-core/pull/142#issuecomment-565554138

However, since you can't override properties in the did-core context, this would likely be exceedingly confusing for anything other than non did-core data, such as blockHash, contractAddress, etc...

[dlongley]

This probably falls under the metadata discussion. (I expect this to be "metadata" not data about the DID subject)

[msporny]

-1, we have the DID Core Registry for this now... suggest that we close this issue with no changes.

[OR13]

-1, we have the DID Core Registry for this now... suggest that we close this issue with no changes.

[dlongley]

So to be clear, -1 to having this be in the DID Document because I don't think it's data about the DID subject, it's "metadata" of some sort.

[cboscolo]

I have a process question.
Wouldn't it be better to close this issue _after_ it has been added to the DID Core Registry?

[OR13]

Not necessarily... we might not want to add any metadata to a did document...

IMO, I'd rather not see method specific metadata in did documents.... if this has not been added to the metadata bucketing google doc, it should be... we will be considering metadata soon.

Related:
https://docs.google.com/document/d/1WoHIA5MzC-kKdyS3XVp5qT-ZiNUbpqXH59g3Q9Fnk04/edit

https://github.com/w3c/did-core/issues/65
https://github.com/w3c/did-core/issues/203

[cboscolo]

I want to clarify that this proposal is NOT about metadata.
It's about preserving a namespace for DID Document properties that are method-specific.

[OR13]

Some people consider method specific properties to be metadata.

If you want to add arbitrary properties to your did document in a way that is interoperable, the did core registry is the place where you would do that.

So to restate this issue, wrt the did-core-registry:

This issue is to propose "method-data" , "@type: @json", as a property of the did core registry. For storing arbitrary json data in a did document.

^ did I get this right?

Is this data needed for interop?

If no, then IMO this issue does not need to be opened here or on did-core-registry, the method implementers are free to do whatever they want.

If yes, then this issue is blocked by the registries issues, and by the metadata debates that I linked, but the registry is probably the right place to try and define what "method-data" is, and why it is needed for interop... but I would maybe wait until we have the great metadata debate, because I can see any PRs getting blocked by that...

[msporny]

I have a process question. Wouldn't it be better to close this issue after it has been added to the DID Core Registry?

I'm going to get pedantic since you asked a process question, my apologies in advance. :)

This is the issue tracker for the DID Core specification. The DID Core Registry is over here:

https://github.com/w3c/did-core-registry/issues

At this point, you could:

1. Argue that method-data is something you want in the DID Core spec.
2. Raise an issue in the DID Core Registry document requesting the addition of method-data.
3. Raise a PR on the DID Core Registry document suggesting method-data.

My expectation is that 1 will be viewed as too generic, against the DID WG F2F grand compromise, and will be argued against. 2 will continue the discussion over there (which may be the right thing to do right now). 3 will probably be delayed due to the same reasons as 1.

[cboscolo]

@msporny, you never need to apologize for being pedantic when discussing process! ;)
I asked, your answer is exactly what I was looking for.
I will close this issue and open one on https://github.com/w3c/did-core-registry/issues