Decoupling DID Core spec from LD-Proof / LDS specs

[awoie]

We should decouple the DID Core spec from LD-Proofs to allow people to use DIDs without understanding LD-Proofs.

For example ...

• proof purposes are specified in the LD-Proof specification such as assertionMethod, authentication etc. We should always keep in mind that people want to use keys in DID Docs to generate proofs other than LD-Proofs as well, e.g., signing pdfs (probably not the best example). It feels a bit weird that someone needs to look at the LD-Proof spec to understand the different proof purposes.
• allow other proofs for DID Documents, e.g., JWS.

[OR13]

I think this is actually a request to have the jsonld context documented, since that is what is required for both VC JWT and VC Linked Data Proofs.

[OR13]

Or rather, its not possible to use DID Docs for anything unless we understand what the properties mean, and in order to do that, we need to document every property in the existing jsonld context, as it applies to DIDs and VCs... and if we remove the context, then we would need to do the same thing with something else, like json schema, and ensure that they aligned or we would have a massively broken VC ecosystem...

[awoie]

@OR13 Thanks for the additional comments. That is what the intention was.

[OR13]

Related issues... in sidetree: decentralized-identity/sidetree#362

[OR13]

Also related:

• Update did-v0.11.jsonld to match the current spec #156
• JSON-LD Parsing Error Blocking VC Data Model Integration decentralized-identity/universal-resolver#77

IMO the did core context should not rely on "sec": "https://w3id.org/security#",... since we cannot ensure that it is updated in a timely manner.

We might want to import the security context and its definitions into the did core spec... So that documentation can be fixed.

[OR13]

Blocked by registries discussion

please review:

w3c/did-spec-registries#14

w3c/did-spec-registries#11

[iherman]

See also discussions on https://www.w3.org/2020/03/16-did-minutes.html

[jonnycrunch]

This is also blocked as LD-Proofs are dependent on the RDF normalization algorithm which is draft and at least I am having inconsistent results.

[OR13]

@jonnycrunch does this help?

https://github.com/rdf-ext/rdf-normalize
https://github.com/digitalbazaar/jsonld.js/#canonize-normalize (JavaScript)
https://github.com/jsonld-java/jsonld-java (Java)
https://github.com/piprate/json-gold (Go)

What language are you using?

[jonnycrunch]

Thanks. I mostly use Go and Rust. 9 days ago https://github.com/piprate/json-gold (Go) was updated to use JSON-LD 1.1. so, I still need to do some interop testing.

[msporny]

The direction that we're heading in here is decoupling the DID Core spec from the Linked Data Security specs. We are in the process of removing proof, created, updated, and a variety of other Linked Data Security-y things.

[OR13]

I think this has been address by w3c/did-spec-registries#47

[awoie]

I agree that this addresses my initial issue.

[jonnycrunch]

section 7.9 Proof states that the proof property, the value MUST be a valid JSON-LD proof. I am having difficulty conforming to the spec with the CBOR representation with this constraint. I will make a PR to update this section to address my concerns.

[OR13]

PRs to remove LD Proof stuff from core / registries welcome.

[msporny]

All normative and informative references have been removed from the specification, we can close this issue.

[jonnycrunch]

will do

[brentzundel]

No comments since marked pending close, closing.