Re: 7th August: DIDWG Special Topic Call - Abstract Data Model

On Wed, Aug 7, 2024 at 6:13 PM Gabe Cohen <gabe@tbd.email> wrote:

> *4. Implementation and Testing*
> - Translation between formats was not trivial; ADM provided a common
> ground.
> - Test suites currently use concrete serializations for testing.
> - Suggestion to keep ADM but have a concrete representation for resolution.
>

Between being a night owl,  some insomnia, and early morning PDT call I was
unfortunately not able to attend the interim meeting today on the Abstract
Data Model.

I strongly prefer to continue to see us use the ADM in the W3C DID
Specification.

I am OK with being more specific in the DID Resolution Specification. For
instance, having a resolver construct an interim JSON-LD-based controller
document on the fly and then use that to validate against various trust
requirements. But part of this is because a DID resolver does not solely
rely on JSON-LD based signatures. For instance in the did:btcr case, the
current DID Resolver code base is actually assembling the DID Controller
document from at minimum two different sources, possibly more, each with
different roots of trust. Having a common format to make that easier for
the resolver to support the ability to validate multiple DID methods makes
sense to me.

Related is that I also believe supporting the DID Resolver spec (with its
ADM) should not be a MUST for the DID Spec itself, instead it can be a
SHOULD or MAY.  I might even be able to make a reasonable argument that the
DID Spec should ONLY have the ADM, and not reference JSON-LD or any
concrete serialization at all (though I doubt there would be consensus or
meet the revised WG charter requirements). This would move all the current
JSON-LD details to the DID Resolver spec.

Part of my challenge with removing ADM in favor of JSON-LD in the core spec
 is that the RDF model inside of JSON-LD  is a node-labeled graph, but
there are other graph forms. I particularly prefer edge-labeled graphs (for
instance used in the popular neo4j database) as I believe that better serve
progressive trust architectures.

Our Gordian Envelope IETF internet draft supports both graph models, and
other models as well, and in our design it may be possible to publish both
models simultaneously. We published a BCR on this topic in some research
"Representing Graphs using Gordian Envelope" at
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-006-envelope-graph.md

I also feel that there are some advanced DID methods in the future that are
based on technology like inclusion proofs or zk-proofs against a larger
herd-privacy data store, and I feel the ADM allows for that, and hope to
demonstrate a proof-of-concept of this in the coming year using our Gordian
Envelope code base. If you are interested in what I mean by herd-privacy
data store, we talk a bit it in our Educational Use Case for Gordian
Envelope, starting here:
https://github.com/BlockchainCommons/Gordian/blob/master/Envelope/Use-Cases/Educational.md#part-three-herd-privacy-credentials
. This use case is more about herd-privacy for VC like objects, but the
concept is applicable to DIDs as well.

-- Christopher Allen