ankurdotb
commented
3 weeks ago Hey @emg110, thank you so much for your comments! It's a long message, but I hope it goes towards clarifying some of the questions. We would love for any suggestions / changes, since that means there would be more authors on the spec and better ideas bubbling through from many different sources, so just to say that if there are indeed any modifications that come through the community editing process on our own implementation, we're open to that.
What you're quite right about is that there parts of the draft where the language is confusing/misleading, and these can/should be cleared up. Thank you for pointing those out!
1- There is no cryptographic verifiability relation there in the proposal.
Our suggestion in the DLR specification is that any request to create/link a resource to a DID should be signed by the controllers for the DID. (The other approach a DID method could take is to use one of the properties specified in DID Core under Verification Relationships instead, e.g., Capability Invocation. However, in practice, I have not seen many DID methods actually use too many of the properties under Verification Relationship, hence didn't suggest this as the primary method.) So in that sense, there's cryptographic verifiability that the resource publishing was authorised. Also, an optional part of the draft is to include a checksum - in did:cheqd, this is a SHA256 checksum - which can be used for integrity checking.
If you meant cryptographic verifiability in a different sense, happy to try clarify that.
2- Directionality is unknown in that draft proposal (incoming or outgoing resource links are not differentiated). For example a verifiable relation from parent to child is different than of child to parent unless you use symmetric cryptographic method (PKC is mostly used asymmetric and usually symmetric methods are derived from asymmetric methods in PKC).
Good question. Currently, we have indeed not proposed any directional relationships because the only ownership we've proposed is which DID Document "owns" a resource. I suspect though that here, you're talking about directionality in linkages in the contents of a DID Linked Resource, for example, a trust accreditation. In the DLR draft and in our implementation, we don't actually check the contents of the DLR in any way, since that is likely going to be covered in their own specifications. For example, if using a DLR to store a status list, the structure/content of the status list should be covered by the status list specification(s), rather than that being in DLR. This keeps the scope of the DID Linked Resources specification limited to describing generic resources that are owned by DID Documents and common ways to resolve to them, rather than also make it about contents.
3- The requirement of using just UUIDs as identifiers, restricts the proposal and is an overdesign IMHO and as long as the unique-identifier complies to DID core and Controller document W3C standards it must be enough (this brings 100% coverage for existing DID implementations).
100% agree and this is misleading in the current draft. did:cheqd uses UUIDs, but I agree that the identifier format should be up to the DID method to choose. The language used in DID Core is pretty good on this front. @Tweeddalex, could you please look at edits in the draft spec to clarify/use broader language that it doesn't just have to be UUIDs?
4- The mandatory "/resources" is an overdesign because it already exists and is declared under linked resource context.
Another point of clarification here: the only bits that should be common (IMO) across DID methods should be the query-based syntax where query parameters are appended after a DID. This is because DID Core / DID Resolution keep this open enough. The path-based syntax, e.g., /resources/xxxxxx IMO is method-specific syntax which is unique to did:cheqd and doesn't/shouldn't need to be replicated by others. It makes sense to keep this method specific, for instance, since a different method may have a different method-specific syntax on how to get to a file, or indeed choose a different path than /resource.
I'm also open to considering whether path-based syntax should be mandatory, but so far I'm skewing towards suggesting this is optional and/or method-specific if desired, and not a common implementation.
5- Digital files as it described in the beginning of the proposal are very restrictive as linkedResource can be literally anything that can be the subject to a DID, especially in a "DID-Linked" resource context.
Yes, the intention is that this can be any file. Examples have been taken to demonstrate what could potentially be stored and resolved as a DLR (and what the benefits are). I'm open to any suggestions on language to clarify that this is not as restrictive as implied.
6- According to the proposal , the linkedResources does not place in DID document but in didDocumentMetadata. Given the fact that linked Resources have more or less similar functionality as service, having them in separate models is bit confusing. By convention all DID initiated / related stuff normally goes to DID document body and all metadata-related stuff goes under didDocumentMetadata so the naming of DID-Linked Resource with assertion on DID-Linking in contradictory with having it under didDocumentMetadata.
This was indeed one of the design considerations in the beginning. Initially, we thought of making this section as a top-level "resources" property within the DID Document itself. After a lot of discussions, the consensus seemed to be that unless DID Core itself was modified to add this top-level property, it would be very unlikely to get adopted. Also, while DID Core does allow other properties without "core" to be defined (so technically, we could add a resources top-level property), in practice we found when reviewing most DID methods and libraries/SDKs that were written in strongly-typed languages such as Rust, TypeScript, Golang etc that software libraries generally assumed that only the properties defined in DID Core would be present. Many, when presented with anything top-level outside of those, would even go so far as crashing/rejecting the DID Document altogether as malformed. Hence, the direction of specifying it in metadata - metadata is covered under DID Resolution specification, and in practice, a lot of DID methods already seem to be using it to store method-specific differences (e.g., see did:indy and how it presents state proofs in DID document metadata.)
That's the practical reason. But the other, logical reason to keep it in metadata is that DID Linked Resource are pointers to dereference and fetch data from some sort of storage (whether on-chain or not), which is arguably not part of the DID document contents itself. Especially with versioning, this can run into 100s/1000s of entries, which makes more sense to deal with as a specific dereferencing use case under DID Resolution spec, rather than DID Core spec.
7- It would be great if the proposal draft could benefit from cosmos LinkedResource proposal as well and extend it or inherit from it with metadata properties which the proposal draft has in it's core.
From @Tweeddalex: "The original linkedResource work you're referring to was I think done by Joe Andreiu as part of the did:cosmos method a few years ago. Since then we decided that we wanted to create a standardised way of referencing to DID-Linked Resources with a common set of query parameters and syntax."
We'd be very open to collaborating with the authors/maintainers of did:cosmos to bring the implementation in line with this spec, or incorporate any suggestions. That original implementation was definitely one of our inspirations!
8- The proposal is focused only on DAG family of graph connectivity because there is a requirement on parent-child / collection hierarchies only, and other structures like DCG or simple open DID linking without hierarchy as the name suggests.
I need to think about this, but the current implementation in did:cheqd (at least) is a simple, 1-level hierarchy between a DID and its resources, as far as ownership is concerned. The contents might be bi/multidirectional/nested (e.g., a resource that's a schema, or a resource that's a trust accreditation with nested levels) but that's a content-specific issue. So, I don't quite see how this is a DAG (since our underlying storage isn't a DAG), but maybe I'm misinterpreting the question (in which case, my apologies!).
emg110
Thank you for the great specification proposal. Here are my comments following our discussion on DIF Slack wd-ig channel: 1- There is no cryptographic verifiability relation there in the proposal. 2- Directionality is unknown in that draft proposal (incoming or outgoing resource links are not differentiated). For example a verifiable relation from parent to child is different than of child to parent unless you use symmetric cryptographic method (PKC is mostly used asymmetric and usually symmetric methods are derived from asymmetric methods in PKC). 3- The requirement of using just UUIDs as identifiers, restricts the proposal and is an overdesign IMHO and as long as the unique-identifier complies to DID core and Controller document W3C standards it must be enough (this brings 100% coverage for existing DID implementations). 4- The mandatory "/resources" is an overdesign because it already exists and is declared under linked resource context. 5- Digital files as it described in the beginning of the proposal are very restrictive as linkedResource can be literally anything that can be the subject to a DID, especially in a "DID-Linked" resource context. 6- According to the proposal , the linkedResources does not place in DID document but in didDocumentMetadata. Given the fact that linked Resources have more or less similar functionality as service, having them in separate models is bit confusing. By convention all DID initiated / related stuff normally goes to DID document body and all metadata-related stuff goes under didDocumentMetadata so the naming of DID-Linked Resource with assertion on DID-Linking in contradictory with having it under didDocumentMetadata. 7- It would be great if the proposal draft could benefit from cosmos LinkedResource proposal as well and extend it or inherit from it with metadata properties which the proposal draft has in it's core. 8- The proposal is focused only on DAG family of graph connectivity because there is a requirement on parent-child / collection hierarchies only, and other structures like DCG or simple open DID linking without hierarchy as the name suggests.
Improvement propositions: I am working on a PR to add both Cosmos extension and my own proposal as one addition to this great specification and that includes :