W3C home > Mailing lists > Public > public-credentials@w3.org > December 2022

Re: PROPOSED WORK ITEM: DID-Linked Resources Specification

From: Harrison <harrison@spokeo.com>
Date: Sun, 11 Dec 2022 08:51:44 -0800
Message-ID: <CAFYh=43rim8E8Q+=J2Z2sW5osR47=JkfQcLCObz+yfBHr=PvkQ@mail.gmail.com>
To: Daniel Buchner <dbuchner@tbd.email>
Cc: Orie Steele <orie@transmute.industries>, Markus Sabadello <markus@danubetech.com>, W3C Credentials CG <public-credentials@w3.org>
Great work!  We've invited Alex and Ankur to present and lead the
discussion on this topic of "DID-Linked Resources Specification" on

You can see the upcoming W3C CCG events here:


On Wed, Dec 7, 2022 at 8:46 AM Daniel Buchner <dbuchner@tbd.email> wrote:

> We're working to do that as part of the efforts, and will be as the query
> path aspects solidify (there's a proposal for that underway now).
> On Wed, Dec 7, 2022, 10:41 AM Orie Steele <orie@transmute.industries>
> wrote:
>> Have any of the DWN URLs been registered with the universal resolver or
>> did spec registries?
>> How will folks know how to implement an interoperable dereferenced object?
>> OS
>> On Wed, Dec 7, 2022 at 9:57 AM Daniel Buchner <dbuchner@tbd.email> wrote:
>>> Given DWNs only rely on a few parameters to be able to identify a
>>> resource in this way (schema URI, protocol URI, Record ID, and Context ID
>>> [I don't mean JSON-LD context]), it would be great to see these as params
>>> that can be normalized at whatever layer so we don't have to 1:1 replicate
>>> them through the adjacent service-specific query syntax. If it ends up that
>>> the param set of this desired initiative was inclusive of a param set that
>>> we could use in DWN query URLs, then that would certainly lower the ol'
>>> blood pressure a lot.
>>> - Daniel
>>> On Wed, Dec 7, 2022 at 3:11 AM Markus Sabadello <markus@danubetech.com>
>>> wrote:
>>>> In my mind, the differences are that:
>>>> - DWNs use the existing "service" parameter to select a service
>>>> endpoint from the DID document, and then define additional parameters to
>>>> identify resources behind that service. The functionality of those
>>>> parameters are independent of the DID method.
>>>> - The work done by cheqd/ToIP is about defining parameters which
>>>> identify resources that are independent of any specific service in the DID
>>>> document, but are (at least partially) dependent on the underlying DID
>>>> method.
>>>> I think both are potentially reusable and should be aligned if
>>>> possible, but I don't think they're exactly the same.
>>>> Markus
>>>> On 12/7/22 03:14, Daniel Buchner wrote:
>>>> I'll note that the goal of this proposed work item is the very crux of
>>>> what we're building in the joint DIF/W3C Decentralized Web Nodes work item,
>>>> which enables all objects, file types, schemas, etc., to be addressed in a
>>>> DID-relative way that delivers an implicit, inferrential API without any
>>>> need to craft things specific to a given set of objects/files. Given this
>>>> is already a joint work item of the the two orgs, can we first examine it
>>>> and do a call about how it delivers on the stated goals of this proposal,
>>>> and/or modify it to do so?
>>>> There will be 1:1 overlap if we spin up a new work item to do the same
>>>> thing, and it would be unfortunate if we created competing efforts almost
>>>> immediately as a solution/spec is in the later stages of development.
>>>> How about a call to review sometime before the holidays or just after
>>>> in January?
>>>> - Daniel
>>>> On Tue, Dec 6, 2022, 7:56 PM Alex Tweeddale <alex@cheqd.io> wrote:
>>>>> Dear CCG,
>>>>> The formal new work item proposal is in the GitHub issue below:
>>>>> https://github.com/w3c-ccg/community/issues/236
>>>>> We are proposing to establish a new work item focussed on creating a
>>>>> W3C specification for DID-Linked Resources, which will tie in closely with
>>>>> the existing DID Resolution spec.
>>>>> This work aims to create a standardized way of referencing,
>>>>> dereferencing and fetching digital resources (schemas, trust & status
>>>>> lists, visual representations of Verifiable Credentials, governance
>>>>> documents, logos).
>>>>> We aim to achieve this by associating digital resources with
>>>>> Decentralized Identifiers (DIDs) and organizing in DID-Linked Collections,
>>>>> where each individual resource is identifiable through its own DID URL.
>>>>> Previous work on this topic, leading to this new work item:
>>>>> - (cheqd) Context for DID-Linked Resources
>>>>> <https://docs.cheqd.io/identity/guides/did-linked-resources/technical-composition-of-did-linked-resources>
>>>>> - (cheqd) Technical composition of DID-Linked Resources
>>>>> <https://docs.cheqd.io/identity/guides/did-linked-resources/technical-composition-of-did-linked-resources>
>>>>> - (ToIP) Trust over IP Draft Specification on DID-Linked Resources,
>>>>> to be superseded by the W3C work item
>>>>> <https://wiki.trustoverip.org/display/HOME/DID-Linked+Resources+Specification>
>>>>> Looking forward to getting this kicked off!
>>>>> Alex
>>>>> Alex Tweeddale
>>>>> Product Manager & Governance Lead
>>>>> Schedule a meeting
>>>>> <https://calendly.com/alex-tweeddale/introductory-call>
>>>>> cheqd.io <https://www.cheqd.io/> | Twitter
>>>>> <https://twitter.com/cheqd_io> | LinkedIn
>>>>> <https://linkedin.com/company/cheqd-identity> | Telegram
>>>>> <https://t.me/cheqd>
>> --
>> Chief Technical Officer
>> www.transmute.industries
>> <https://www.transmute.industries>

*Harrison Tang*
<https://www.linkedin.com/in/theceodad/> •
<https://twitter.com/TheCEODad>Twitter <https://twitter.com/TheCEODad>  •
<https://www.tiktok.com/@tang_toks> Tiktok
<https://www.tiktok.com/@tang_toks>  •
<https://www.facebook.com/TheCEODad> Facebook
Received on Sunday, 11 December 2022 16:52:15 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 11 December 2022 16:52:17 UTC