DID URL dereferencing and its relationship to different encodings/representations

[tplooker]

On the did resolution call today, the topic was raised around did-url syntax and how
something like a dereferencing operation with a did-url on a did document will occur across different encodings of the did document.

Currently the core data model of the did document expresses a did document as a graph where every node in the graph can have its own identifier. These identifiers are then used by resolvers in conjunction with the did url syntax to enable dereferencing.

For example a did document expressed in JSON-LD

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Dereferencing did:example:123456789abcdefghi#keys-1 yields

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}

However in the specification at the moment in the fragment section. A statement about not excluding the usage of JSON pointers is made.

A JSON pointer solution to the JSON encoding of a did document could look quite different, for example.

{
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Whereby dereferencing did:example:123456789abcdefghi#/authentication/0 would yield

{
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}

To me this raises a discussion about to what degree the did core specifications data model and identifier syntax will describe how operations like dereferencing occurs. IMO if we have a per-encoding approach to dereferencing and or identifying elements of a did document, this could be problematic for interoperability.

In essence the question I am asking with this issue, is will the did core specification define a standardised (but perhaps not the only) way of identifying and dereferencing content in a did document irrespective of encoding?

[tplooker]

CC @dmitrizagidulin @peacekeeper @jonnycrunch @jricher who had opinions about this matter on the call

[msporny]

To me this raises a discussion about to what degree the did core specifications data model and identifier syntax will describe how operations like dereferencing occurs.

I'd say "not at all, that has to do with DID Resolution and dereferencing". The data model provides a mechanism to identify components in a DID Document... it's some other specs job (DID Resolution) to pull each component out in a way that makes sense.

I also find it strange that DID Resolution would have a feature that picks out specific parts of a document... it's usually the application layer that does that (like how browsers treat fragment IDs). It can be argued both ways, so I don't have a strong opinion... other than, this sort of thing should go in a different spec than DID Core.

[peacekeeper]

Thanks @tplooker for raising this.. For reference, here are the DID Resolution meeting recordings and logs where this was discussed: https://github.com/w3c-ccg/meetings/tree/gh-pages/2020-02-20-did-resolution

[peacekeeper]

@msporny

The data model provides a mechanism to identify components in a DID Document... it's some other specs job (DID Resolution) to pull each component out in a way that makes sense.

I agree, but I think @tplooker 's point is: What will the data model say about identifying components in a DID document, and what will be the requirements for representations of that data model (and their MIME types, which define the behavior of a fragment in a URL).

So in his example if you have the DID URL did:example:123456789abcdefghi#keys-1, is this guaranteed to "work" consistently across different DID document representations (application/did+json, application/did+ld+json, application/did+cbor, application/did+xml, ...), or is there a possibility that different representations will handle fragments differently?

This is not just a question of DID Resolution, but also DID Core.

I also find it strange that DID Resolution would have a feature that picks out specific parts of a document

Yes, to be precise "picking out specific parts of a document" is part of dereferencing, not DID Resolution. But how that dereferencing works is dependent on the MIME type of the representation (see above).

[tplooker]

@msporny, yes @peacekeeper is quite right, prior to #225 being merged without requiring public keys to have an id then syntax like did:example:123456789abcdefghi#keys-1 would not be guaranteed to work in reference to identifying public keys. Which could encourage different software vendors building did infrastructure to diverge around how things like public keys are referenced using a did url e.g via a JSON pointer construct.

My feeling after taking time to review this issue a little further is that provided did-core sticks to the commitment to loss less conversion between encoding schemes and the core data model supports consistent ways in which to achieve actions like dereferencing via an element referenced by an id statement in a did document (regardless of encoding mechanism), then I'm comfortable that the outstanding questions are for did resolution to solve.

With that said, I believe the statement about JSON pointer should be removed from did core because I dont think it is a data model concern at heart and unless it can be shown to work in a loss less manner (ie interoperable with a CBOR representation) then it should not feature in did-resolution either.

[burnburn]

@tplooker is anything else needed before we can close this issue?

[kdenhartog]

I'd think this would be covered by #257 in combination with the PRs in flight about resolution/de-referencing. I'll let him know to comment on this issue.

[tplooker]

@burnburn no I believe the concerns have been addressed