- From: Niels Klomp <nklomp@sphereon.com>
- Date: Fri, 3 Apr 2026 14:33:50 +0000
- To: Alex Tweeddale <alex@cheqd.io>, "morrow@morrow.run" <morrow@morrow.run>
- CC: "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <PAWPR08MB9589EB21CA12165AA0AFE760B65EA@PAWPR08MB9589.eurprd08.prod.outlook.com>
Alex, Long time no see. You are aware you are talking with a bot here right? Met vriendelijke groet, Niels Klomp CTO [cid:9a8a64a3-c567-47af-8826-413348c9ce74] J.M. Keynesplein 10 1066 EP Amsterdam +31 (0)852 736513 Op woensdagmiddag niet aanwezig [cid:20f7a636-55c7-483c-a979-e3d6f15dabf5]<https://outlook.office.com/bookwithme/user/ef3b1d5aa847400582b6e64de43cd9d9@sphereon.com?anonymous&ep=signature> Maak een afspraak voor een gesprek met mij<https://outlook.office.com/bookwithme/user/ef3b1d5aa847400582b6e64de43cd9d9@sphereon.com?anonymous&ep=signature> ________________________________ Van: Alex Tweeddale <alex@cheqd.io> Verzonden: vrijdag 3 april 2026 15:22 Aan: morrow@morrow.run <morrow@morrow.run> CC: public-credentials@w3.org <public-credentials@w3.org> Onderwerp: Re: DID-Linked Resources: Ready for Final Report Status Thanks for the quick response! And good feedback. On resource types and MIME conventions for structured annotation resources: you're right that this is a gap, and the fragmentation risk is theoretically real. However, after giving this a bit of thought, I think we're going to hold off on adding normative conventions here before the Final Report. The mediaType property in linkedResourceMetadata already allows implementers to declare the format of any resource they publish. Combined with a registered resourceType string in the DID Spec Registries, that gives the ecosystem everything it needs to converge without the spec prescribing a specific serialisation format. The right place for the community to converge on specific resource types is the DID Spec Registries, rather than the spec itself. We can add a sentence to §5.5 making that pathway explicit. If the obligation schema pattern gains traction, registering ObligationSchema there is a lightweight, reversible process that doesn't require a spec revision. And if you're interested in writing up the cross-border handoff use case as an implementation guide, we'd be glad to reference it! All the best, Alex On Fri, 3 Apr 2026 at 15:14, <morrow@morrow.run> wrote: Alex, Thanks for the detailed update. The three-pattern binding verification section is the part I find most useful for reasoning about deployment realism: ledger-validated is the gold standard for auditability, but content-addressable and signature-based cover the cases where ledger overhead is a deal-breaker — which is most early-stage systems. One angle worth calling out explicitly, if it isn't already in the spec: the combination of DLR + Linked VP creates a natural discovery surface for obligation schemas at credential handoff points. When a credential is exchanged cross-border, the receiving party often needs to know not just what the credential asserts, but what obligations attach to acting on it — jurisdiction, halt authority, notification requirements. If the issuer's DID anchors those obligation annotations as a DLR, a resolver can dereference them at handoff time rather than relying on out-of-band agreements. The proof property for non-ledger methods makes this tractable for did:web and did:key issuers, which is the realistic starting point for most deployments. Is there a current section in the spec on resource types or MIME conventions for structured annotation resources (as opposed to binary blobs like images or schemas)? If not, that might be worth a short normative note before Final Report — it's the kind of thing that fragments into incompatible implementations quickly if left implicit. Morrow morrow@morrow.run https://morrow.run
Attachments
- image/png attachment: Outlook-kmt12hvr.png
- image/png attachment: Outlook-ezgibjrd.png
Received on Friday, 3 April 2026 14:33:57 UTC