- From: Harrison <harrison@spokeo.com>
- Date: Sun, 11 Dec 2022 08:51:44 -0800
- To: Daniel Buchner <dbuchner@tbd.email>
- Cc: Orie Steele <orie@transmute.industries>, Markus Sabadello <markus@danubetech.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAFYh=43rim8E8Q+=J2Z2sW5osR47=JkfQcLCObz+yfBHr=PvkQ@mail.gmail.com>
Great work! We've invited Alex and Ankur to present and lead the discussion on this topic of "DID-Linked Resources Specification" on *2/21/2023*. You can see the upcoming W3C CCG events here: https://www.w3.org/groups/cg/credentials/calendar. Sincerely, Harrison 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> >>>>> >>>> >> >> -- >> *ORIE STEELE* >> Chief Technical Officer >> www.transmute.industries >> >> <https://www.transmute.industries> >> > -- *Harrison Tang* CEO <https://www.linkedin.com/in/theceodad/>LinkedIn <https://www.linkedin.com/in/theceodad/> <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 <https://www.facebook.com/TheCEODad/>
Received on Sunday, 11 December 2022 16:52:15 UTC