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

Hello Christopher,

I think most DID methods are in a way very similar to did:btcr, insofar 
as they don't retrieve complete DID documents, but rather assemble them 
dynamically.
Maybe the only exception is did:web and perhaps a few others.
Yes, this makes roots of trusts very method-specific, and I completely 
agree that a resolver can't just rely on JSON-LD based signatures, and I 
don't think many DID methods even use JSON-LD based signatures (Data 
Integrity).

Having only the ADM in DID Core, and moving JSON-LD in DID Resolution is 
a new proposal, and I can see some arguments for that, but OTOH I think 
the current structure (data model in one spec, resolution process in 
another spec) is also quite clean.

Regarding node-labeled graphs, I also share an interest in that.
I guess one could define a representation of the ADM based on such a 
graph model, with the appropriate production/consumption rules, that 
might be an interesting exercise.

Markus

On 8/8/24 7:58 AM, Christopher Allen wrote:
> 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