Re: DID-Linked Resources: Ready for Final Report Status

Dear Alex,

From Spherity perspective, having worked with centralized and decentralized
trust infrastructure technology artifacts, we recommend positioning DLR as
one composable layer in a “hybrid trust architecture,” not as the “full
trust artefact type discovery stack.”

DLR could be positioned for “trust artifact addressing and dereferencing.”

Governance-grade trust discovery should remain separable, for example
through DNS/DNSSEC-based approaches such as TRAIN (and an ENS extension)
for human-readable trust domain definition, which anchors trust-list
pointers in DNS or ENS. I personally like ENS type trust discovery because
it is a contributing component to a ZTA stack (I.e. I can operate and sync
a note with the ENS registry and can do all look up operations locally.)

For broader adoption, we suggest an explicit hybrid profile with
authoritative trust discovery through governed infrastructure and
standards, DLR for linked artifact resolution, and optional decentralized
mirrors for public metadata and resilience.

As mentioned, ENS can be useful in that mirror role because it supports
human-readable arbitrary text records (aka ENS domains).

A concrete DPP example would help. In DPP deployments, a product DID or
issuer DID may need to resolve a credential schema, a status or revocation
resource, a governance profile, a conformance policy, and supporting
provenance artifacts. DLR can provide a clean way to bind and dereference
those artifacts, while the trust decision on whether they are acceptable
remains anchored in the governing trust framework. That is a useful fit for
regulated supply chains and cross-ecosystem verification. This example can
then be extended to trade documents, digital twins and AI agents.

One point we recommend making more explicit in the draft process is that
proof of controller binding is not the same as governance acceptance (i.e.
a resource may be cryptographically bound to a DID, but that alone does not
mean it is trusted or accepted by a given ecosystem, regulator, or trust
framework.) DLR proof shows that the DID controller authorized the
resource. It does not show that the resource is accepted under a sectoral
or regulatory trust framework. Such a trust framework can m a give industry
domain must be agreed upon in a regulated industry and the trust domain
must then be “configured” in a verifier module. Everything else can then be
machine automated in the verification process.

This can be also tied to the trust list works that originated in a RWOT
working group in The Hague.

If you like we can contribute to the DLR standard.

Carsten

Alex Tweeddale <alex.tweeddale@gmail.com> schrieb am Fr. 3. Apr. 2026 um
14:11:

> Dear CCG,
>
> I'm pleased to share that the DID-Linked Resources (DLR) specification has
> received a significant set of updates over the past few weeks. The latest
> working draft is available here:
>
> https://w3c-ccg.github.io/did-linked-resources/
>
> We believe the specification is now mature enough to move toward Final
> Report status within the CCG, with the longer-term goal of bringing it onto
> a formal standards track (whether at the DID WG or another suitable home).
> Before requesting that step, we'd welcome review and feedback from the
> group.
>
> Some notable changes in this revision:
>
>    - Broader applicability across DID methods. The spec now includes
>    concrete guidance for web-based methods (did:web, did:webvh), static
>    methods (did:key, did:jwk), and peer methods (did:peer), in addition
>    to ledger-based methods.
>    - A new section on Binding Verification Mechanisms defines three
>    patterns (ledger-validated, signature-based, and content-addressable) so
>    that any DID method can adopt DLRs.
>    - Proof property for non-ledger methods. A new optional proof
>    property, conformant with VC Data Integrity, allows DID controllers using
>    non-ledger methods to cryptographically bind resources to their DID without
>    relying on a consensus mechanism.
>    - Alignment with Linked VP. A new section describes how a Verifiable
>    Credential published as a DLR can be surfaced as a Linked Verifiable
>    Presentation, composing the two specifications for public credential
>    discoverability.
>    - Alignment with DID Resolution. The dereferencing algorithm has been
>    updated to note the relationship with the PathService work in DID
>    Resolution, ensuring the two approaches are complementary rather than
>    competing.
>
> We'd appreciate any feedback, whether on the overall approach, specific
> sections, or areas we may have missed. Issues can be filed on the GitHub
> repo:
>
> https://github.com/w3c-ccg/did-linked-resources/issues
>
> Thank you, and looking forward to seeing this move along!
>
> Alex
>

-- 





Spherity GmbH <https://www.spherity.com/>  |  Emil-Figge-Straße 80  |  
44227 Dortmund

LinkedIn <https://www.linkedin.com/company/spherity>   |  
YouTube <https://www.youtube.com/@spherity2407>

Managing Directors: Dr. 
Carsten Stöcker, Dr. Michael Rüther

Registered in Dortmund HRB 31566