search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
42 stars 6 forks source link

[PROPOSED WORK ITEM] DID-Linked Resources Specification #236

Closed Tweeddalex closed 1 year ago

Tweeddalex commented 1 year ago

New Work Item Proposal

DID-Linked Resources Specification

Include Link to Abstract or Draft

cheqd work on DID-Linked Resources:

Context for DID-Linked Resources Technical composition of DID-Linked Resources Trust over IP Draft Specification on DID-Linked Resources, to be superseded by the W3C work item

did:cosmos work on Linked Resources:

did:cosmos Linked Resources

Decentralized Web Nodes work on DID-Relative URLs:

DIF Decentralized Web Node Spec

List Owners

Ankur Banerjee, @ankurdotb (cheqd); Alex Tweeddale, @Tweeddalex (cheqd); Markus Sabadello, @peacekeeper (Danube Tech); Drummond Reed, @talltree (Gen); Orie Steele, @OR13 (Transmute); Joe Andrieu, @jandrieu.

Work Item Questions

Answer the following questions in order to document how you are meeting the requirements for a new work item at the W3C Credentials Community Group. Please note if this work item supports the Silicon Valley Innovation program or another government or private sector project.

  1. Explain what you are trying to do using no jargon or acronyms.

Create a standardized way of referencing, dereferencing and fetching digital resources (schemas, trust & status lists, visual representations of Verifiable Credentials, governance documents, logos). Associating digital resources with Decentralized Identifiers (DIDs) and organizing in DID-Linked Collections, where each individual resource is identifiable through its own DID URL.

Agree on a core data model and set of query parameters for DID-Linked Resources, which is not method specific - including what is required and what is optional. Describe how method-specific additions can be added to the core data model. This should:

  1. How is it done today, and what are the limits of the current practice?

Resources tend to be stored and referenced on centralized infrastructure, such as web servers. This creates single points-of-failure for Verifiable Credential-based ecosystems which rely on these resources. In addition, resources evolve over time, and it is important to be able to reference and link to previous versions of a resource, as well as the latest version.

  1. What is new in your approach and why do you think it will be successful?

Through linking resources to DIDs and organizing them in DID-linked Collections, it is possible to extend the trust established in Verification Method Relationships to digital resources. This means that specific keys defined in a DID Document may be used for creating and managing DID-Linked Resources.

Identifying each digital resource with its own DID-URL creates a method-agnostic and highly resilient way of referencing, dereferencing and fetching digital resources. Establishing a specification with a set of standardized DID URL-based query parameters will enable any DID Resolver to implement the functionality to return digital resources.

  1. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

Ankur Banerjee (UK) and Alex Tweeddale (Australia) from cheqd will both be helping lead this project from different sides of the world and co-wrote the initial cheqd work on DID-Linked Resources. Joe Andrieu has helped pioneer the did:cosmos approach to Linked Resources. Markus Sabadello (Austria, Danube Tech), Drummond Reed (USA, Gen), Orie Steele (USA, Transmute) all have a significant amount of experience in technical specifications, being co-authors of the W3C DID Core specification. The authors, both individually and collectively, are contributing to other leading ecosystem initiatives such as DIF, Trust over IP, eSSIF-lab, the Open Wallet Initiative and the Silicon Valley Innovation Project.

  1. What actions are you taking to make this work item accessible to a non-technical audience?

This work item is primarily intended for a technical audience, whom are familiar with the existing DID specification and the DID Resolution specification. However, we will make best efforts to describe the new concepts described in this specification in simple, plain language, and where possible, support the explanations with clear diagrams and visuals.

OR13 commented 1 year ago

I support this work item proposal and am happy to edit / provide feedback.

peacekeeper commented 1 year ago

I look forward to contributing to this, specifically on the topic of how this will align with the DID Resolution spec.

decentralgabe commented 1 year ago

Agree with @csuwildcat 's point on the mailing list this seems to have significant overlap with the intentions of Decentralized Web Nodes.

See: https://identity.foundation/decentralized-web-node/spec/#service-endpoints

And: https://identity.foundation/decentralized-web-node/spec/#collections

ntn-x2 commented 1 year ago

I am also willing to be involved in the discussion, as we have started "overcharging" our DIDs with additional information, and would be great to agree on a uniform representation of that.

Tweeddalex commented 1 year ago

@OR13 what is the process from here to get this as a repository that we can begin working on?

jandrieu commented 1 year ago

Can you comment on how this relates to the linked resource work done in did:cosmos? https://github.com/EarthProgram/did-cosmos

msporny commented 1 year ago

+1 supportive of this work item (and ones like it) that are attempting to find common patterns for DID URL.

man4prez commented 1 year ago

+1

mprorock commented 1 year ago

Proposal to adopt held on 01/03/2023: chairs note feedback from the group that the work item should consider existing implementations, e.g. as noted by @jandrieu and others, and the work ideally will not be specific to an existing implementation - The chairs look for confirmation of this or other commentary from @Tweeddalex and others

msporny commented 1 year ago

This was noted on the 01/03/2023 call: My understanding the charter process was that if there were multiple implementations and it is within the context of the charter then we cannot deny this work item therefore the question is what is this proposal about? This is a chartering conversation and I'm opposing the chartering as currently defined I would like to see this Charter changed. (ed: There is other work out there, please make note of that in the specification).

jandrieu commented 1 year ago

This particular charter reads as a simple adoption & endorsement of Cheqd's approach to linked resources without acknowledgement or incorporation of existing work with similar function and even, in the case of did:cosmos, the exact same name. The identity hub / DWN work also has similar constructs. I'm sure there are others.

It should be clarified that the goal here is not to simply adopt or endorse a specific approach used in a specific method, but rather to start the conversation about how different approaches can harmonize and work together.

decentralgabe commented 1 year ago

the last thing we need is more competing implementations, so big ➕ to @jandrieu. The mission of this work item must first be to do an analysis of existing solutions and work towards unification. If it cannot be achieved that is a fine outcome and should be detailed as well.

Tweeddalex commented 1 year ago

@jandrieu https://github.com/jandrieu I 100% agree that the aim of this should be to reach a common consensus on how to utilize resources associated with DIDs. That includes looking at your work on did:cosmos, the DWN work and our work at cheqd and forming a harmonised and standardised approach.

As long as the outcome of this is something that:

  1. Is built using existing, familiar DID Core Spec patterns
  2. Supports existing DID Resolvers and principles of DID URL dereferencing
  3. Protects against linkrot for long-term retrieval
  4. Enables resources to be versioned and organised, with individual versions being able to be fetched
  5. Includes linkage between DID Documents and associated resources (via metadata or otherwise)

From taking a look at did:cosmos' implementation, it seems to fit into the above - so I'm sure there will be learnings from the cheqd approach and likewise from the did:cosmos approach which can be discussed as this gets kicked off.

On Wed, 4 Jan 2023 at 07:51, Gabe @.***> wrote:

the last thing we need is more competing implementations, so big ➕ to @jandrieu https://github.com/jandrieu. The mission of this work item must first be to do an analysis of existing solutions and work towards unification. If it cannot be achieved that is a fine outcome and should be detailed as well.

— Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/236#issuecomment-1370212326, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCJTEU3JQFDVTQHAJAMNWLWQSGODANCNFSM6AAAAAASWG2FZY . You are receiving this because you were mentioned.Message ID: @.***>

jandrieu commented 1 year ago

Thanks, @Tweeddalex that is a great response.

Since this issue ends up as the de facto charter for the work item, would you be open to editing the description to capture some of these ideas?

In particular, referencing the DWN and Cosmos work as input documents equal to the work already cited would definitely open the aperture of intention.

I especially liked the set of functionality you are looking for. Those are all goals I support.

In that same spirit, the features of the linkedResource property that I'd like to see picked up include:

  1. DID subject specific namespaces of identifying both digital and real-world assets, e.g., did:ex:myNFTid defines a namespace that expands for path and query parts so that every DID can establish its own, unambiguous identifiers in an exclusive namespace. [This is essentially free by using DID URLs to refer to resources related to a DID.]

  2. Linked resources representable in multiple, privacy-agile ways, all of which MUST be supported. This is similar to the multiple ways that CSS styles can be defined and applied in HTML: link tags to external resources, style tags for document-wide embedded styles, element attributes for element-specific styles, and javascript/DOM methods for dynamic styles. The means of defining styles is nearly irrelevant (they matter only in the operational order of processing, not in the semantics of the styles).

The Cosmos linkedResources supports inline presentation, endpoint references (with and without hash), pure hashes without any endpoint, and a hashgraph with neither endpoint nor the count of resources included in that hashgraph. This feature means we don't end up with one privacy approach for every DID. Instead, DID controllers can select which approach best suits their use case, and all resources get treated equally.

In particular, inline Linked Resources provide an interoperable way to include arbitrary meta-data about the DID Subject with more privacy flexibility and interoperability than adding an arbitrary property to the DID Document. Arbitrary properties lose the privacy-agile flexibility of Linked Resources: transitioning from a simple property to a hash reference changes the semantics and would require all implementations that support that property to support these alternative, yet-to-be defined semantics. Providing the same information inside a linkedResource allows the property to be managed in various privacy preserving ways based on the proclivity of the DID controller and supported by all implementations. This separates the DID URL syntax from the DID controllers' privacy policies.

  1. Support for treating DID URLs with fragments as references (used to make statements) and DID URLs with paths as downloadable/interactive resources. This includes supporting both a path and an id for every resource, with a convention to use the same value (modulo the "#" and "/" character) so the same resource has distinct ways to refer to it and download it. This is, IMO, a legitimate, if constrained solution to the HTTPRange14 problem; the pattern of usage clarifies the DID URLs that are downloadable and those which define a reference.

  2. Support for specifying service endpoints by reference within the linkedResource, similar to how verification methods can be defined inline or by reference.

  3. Support for separate verification relationships specific to each resource, so that the resource itself (as identified by DID URL) can have different relationships than the DID itself, e.g., authentication as a particular resource like did:ex:abc#creator can be cleanly separated from did:ex:abc#owner and event did:ex:abc itself. A user could be authenticated wrt particular DID resource without empowering that user in any other way relative to that DID. This is technically already supported (verification relationships are not restricted to the top level), but I don't know of any implementations (other than did:cosmos-based work) that are even aware such an option exists.

Tweeddalex commented 1 year ago

@jandrieu I've made an initial update to the work charter to reflect my previous message and include reference to the did:cosmos and DWN work. I've also asked @ankurdotb to help respond more specifically on some of the other points you raised in your last message, since there's a few points for discussion.

vongohren commented 1 year ago

+1 to support this work item, aslong as there is a clear conforming of the existing ways of doing it, since there has been great minds thinking from different angles

Tweeddalex commented 1 year ago

Thanks everyone for joining the discussion today - here is the slide deck we used for the presentation:

https://docs.google.com/presentation/d/1-YmtlteNTrerRY_l0S5jl6IX9uM6-_8jeD523jZfSds/edit#slide=id.g1347c024e1b_0_116

man4prez commented 1 year ago

DID Linked Resources repository has been created. Editors as listed in this issue has been assigned as codeowners.