make DID document deterministic

[jonnycrunch]

This seems like a very w3c centric view of the world that the @contextmust be a URL. I think there are better solutions, including @contextbeing and object ( still valid). Also checkout this argument for why I think IPLD is a more secure solution: https://github.com/jonnycrunch/rwot7/blob/master/draft-documents/ipld_did_documents.md.

@context with root path should be valid as a self-describing cryptographic link. i.e.:

{ "@context" : { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" } }

---

Preview | Diff

[jonnycrunch]

Also, should consider changing public key from an array to an object. Much easier to reference by key rather than by position in a non-deterministic array. see: https://github.com/jonnycrunch/rwot7/blob/master/draft-documents/ipld_did_documents.md.

[peacekeeper]

Jonny, @context requiring a URL is a fundamental property of JSON-LD, we can't "override" this here on the level of the DID spec..

[jonnycrunch]

from the json-ld schema https://github.com/json-ld/json-ld.org/blob/master/schemas/jsonld-schema.json an object is valid.

"context": {
            "additionalProperties": true,
            "properties": {
                "@context": {
                    "description": "Used to define the short-hand names that are used throughout a JSON-LD document.",
                    "type": ["object", "string", "array", "null"]
                }
            }

I'm just suggesting an object in the form:

{ "@context" : { "/" : "zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq" } }

be valid for DID spec.

where the key "/" represents a link to a self-describing cryptographic hash. This is a much more secure representation of what JSON-LD is attempting.

@ChristopherA @kimdhamilton welcome your feedback/support.

[msporny]

@jonnycrunch I suggest you do this instead (which would be fully valid JSON-LD and require zero changes to the JSON-LD spec):

"@context" : "ipfs:zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq"

You'd need to provide a URL scheme for IPFS, but that's way easier and already on my list of "things to work on with Protocol Labs" /cc @jbenet @daviddias

Doing that would also address a long-standing issue in the Linked Data community wrt. content-addressed JSON-LD Contexts.

[jonnycrunch]

But an object is valid @context in JSON-LD schema, is it not? (see above) So no changes to JSON-LD spec required.

The direct "/" link is helpful as there is no parsing involved. And linking is the point of JSON-LD, is it not?

[msporny]

But an object is valid @context in JSON-LD schema, is it not? (see above) So not changes to JSON-LD spec required.

No, not just any object. An object that a JSON-LD processor knows how to process... and the way it processes "/" is definitely not what you want here.

Here's the algorithm for processing a JSON-LD Context:

https://www.w3.org/TR/json-ld-api/#context-processing-algorithms

[jonnycrunch]

That section with the algorithm is non-normative and not part of the spec. I'm recommending a different approach for the DID spec.

What are your thoughts regarding changing array of public keys to object?

{
  ...
  "publicKey": {
    "keys-1": {
      "type": "RsaVerificationKey2018",
      "owner": "did:example:123456789abcdefghi",
      "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n", 
      "status" : "revoked"
  }, 
    "keys-2" : { 
      "type": "Ed25519VerificationKey2018",
      "owner": "did:example:pqrstuvwxyz0987654321",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }, 
  }, {
    "keys-3" : { 
      "type": "Secp256k1VerificationKey2018",
      "owner": "did:example:123456789abcdefghi",
      "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
    }
  },
  ...
}

see: https://github.com/jonnycrunch/rwot7/blob/master/draft-documents/ipld_did_documents.md

[davidlehn]

Related to naming keys, the draft JSON-LD 1.1 Data Indexing or Node Identifier Indexing features might be useful to look at:

• https://w3c.github.io/json-ld-syntax/#data-indexing
• https://w3c.github.io/json-ld-syntax/#node-identifier-indexing

[msporny]

Manu to close this PR w/ other PRs as replacements.

[jonnycrunch]

So, I'd like to keep this issue open until everyone has a chance to review the related work items for Multihash, Multicodec and Multibase, etc. Afterwards y'all may have a better understanding of where I am coming from. In particular, IPLD is not the same as IPFS. IPLD (Interplanetary Linked Data) is a self-describing abstracted data model relating a cryptographic identifier to the content and does not necessarily depend on resolving it over a particular protocol, although this is often how it is used in IPLD. It is important to emphasize that the CID (content Identifier) stands on its own without relying on a platform. It is basically the application of multihash, multicodec and multibase which equals the CID. In context of DID, the CID could be used with pairwise identifiers and NOT be stored on IPLD/IPFS and thus may not necessarily resolve. see the draft of the paper here: https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/draft-documents/ipld_did_documents.md If we go down the path of MUST include the URI schema name (IPLD:) then it implies that it must be a resource resolvable on IPLD, which may not be the case. What I am asking for is a reservation of "/" to describe a CID NOT an IPLD or IPFS resource.

[jonnycrunch]

The second part of my PR relates to the list of public keys should be by object and thus becomes a deterministic outcome when serialized in to CBOR. just a simpler approach in my mind than the iterating over an array, which could change and thus NOT be deterministic changing the hash (and therefore CID) of the content. Perhaps my title of this pull request should be "make DID document deterministic" and relates to the @context which can change and the array of public keys which if you don't keep track of the order will change the hash of the content ( CID ).

[jonnycrunch]

so, the real lift here is to make IPLD a valid type of JSON on par with JSON-LD. similar to my PR from VC data model: https://github.com/w3c/vc-data-model/pull/261.

[brentzundel]

This repo is scheduled to be archived. The work has moved to the DID WG. The artifacts in the DID WG repository share commit history with this repo, so it should be possible to raise this PR against that repo, if that is still desired.

[msporny]

Raised issue in new DID WG to continue this discussion. Closing this PR in preparation for archival of this repo in favor of the DID WG "DID Core" specification.