Meeting minutes
<Wip> Agenda: DID URL Paths
<Zakim> Wip, you wanted to testing this out
<Wip> w3c/
Wip: This is a special topic call, to try and get some closure on issue 821 -- been around for a while, I wasn't fully sure what the closure would be - or look like. Decide what are the actions here. I don't know if that'll take the entire call.
Wip: We have cheqd here to provide input on how they're using paths. We want to understand how to generalize this, commonality across methods using paths.
<Zakim> manu, you wanted to note goals.
manu: +1 to look through what cheqd has done. Goal is to try figure out some generalized language to increase interop around how people are using paths
… initial intention was pretty clear. associate files with an identifier that is not bound to a specific domain
… achor files to a DID
… straightforward usecase, we want this to be supported across DID methods
… goal, speaking as an editor, is to try at least very clearly state this goal
… we left it to DID methods to define how that works, this is still ok, but perhaps there is stronger language that we could add in to increase interop
… In the spec we could say the path should resolve to a file, the DID method should define how this works
… how are people use DID web, is the path semantics the same across DID methods
… In your DID method you should try for alignment otherwise it defeats the purpose of using paths
Wip: Thanks for the Editor's perspective.
tweeddalex: Completely agree, Manu -- maybe by end of call, we offload to DID Resolution spec, maybe we could signal to the DID Linked Resources spec for standardized ways for resource queries and paths -- maybe we can think of DID Linked Resources as extension to DID Core/Resolution for this specific issue.
markus_sabadello: I also agree with both Manu and Alex, so far we've left it up to DID Methods completely, how a path and DID URL is processed, we don't define any specific names or path segments in DID spec or DID Resolution spec.... there is a section in DID Resolution, which is an algorithm for dereferencing a DID URL. It says that when there is a path, how you dereference can be defined by DID Method or by extension, very open ended.
markus_sabadello: Could be DID Method, could be extension like DID Linked Resources, I agree that stronger language could be useful as long as we don't limit future innovation.
ankurb: Just to clarify, when we say "paths in DID URLs", do we mean paths and queries?
ankurb: The only one defined in spec is how that is handled for query parameters to service... language to expand, it's one way that DID URL can be defined, leads to a resource, but other ways can happen... resource that is file or API. Would that make sense?
markus_sabadello: To respond about query, that's treated a bit differently in the spec, we do define concrete query parameters, DID Parameters, version_id, version_time, service and so on... in resolution, we do define what happens when there is a query parameter.
markus_sabadello: Resolution spec defines how to dereference that, but it's also completely extensible, could be DID Method parameters, or extension parameters... difference between query and path is that we do define concrete query parameters, but don't define anything about the path.
<dlongley> note that we could decide on a difference for queries based on whether a path is present, i.e., no path means the DID spec defines the queries, if there is a path, the method does.
<dlongley> (that would be one way to clearly namespace to allow more flexibility for DID methods)
manu: We can't make class 4 changes to the DID specification, but we can make class 4 changes to DID Resolution, and I hope we do that. I think we did a good job with query parameters -- some are normatively defined in DID Resolution, but you can extend them via DID Method specs or DID Extension specs. I hope we end up in the same sort of place with path parameters.
manu: I would like to see if we could merge some language that we can come to consensus on from DID Linked Resources into the DID Resolution spec if we want to make more normative changes to the specs.
dlongley: My memory is that we defined query parameters we have today based on them occurring without a path in the DID URL... service, version time, all related to DID Document w/o a path, presuming path refers to other resource about authority. I don't know if we were very clear about that, we might want to be more clear about that. That might help namespace how query parameters work... no path, here's how they work, if there is a path, could continue
to use general query parameters, could be of some use.
tweeddalex: On Manu's point, some of the language from DID Linked Resources have been pulled into DID Resolution spec, there is now language for dereferencing to resources and draws on a lot of logic / work on DID Linked Resources. Also in universal registrar, resource functions defined there as well.
markus_sabadello: To Dave's point, yes, agree with Dave that we defined query parameters that we have right now were meant, definition of how they work, intention was for that to be the case. In those situations where there isn't a path -- assuming DID Parameters that we have now, that's how they work without a path. I agree with Dave on that point.
markus_sabadello: To Alex's point, don't know if we've taken concrete language into DID Resolution from DID Linked Resources, but definitely want to make sure those things are aligned, Linked Resources are compatible w/ what we have in DID Resolution, don't have to change anything to make it work, but could decide to have stronger language.
<ankurb> We can suggest language to expand DID resolution spec to provide an example
Wip: Can Alex and Ankur walk us through how DID Linked Resources work? Which things might you want to see, what could be merged into DID Resolution?
tweeddalex: There are at least 7 DID Methods using DID Linked Resources... spec is fully generalized, all cheqd-specific logic is generalized and removed, can be applied to any DID Method.
<ankurb> I have a clash for the next 15 minutes at half past the hour for 15 mins I couldn't get out of, but I'll try to be back after that if I can
tweeddalex: DLRs (DID-Linked Resources) -- extension to DID URLs, standardized format for CRUD for digital resources. In a nutshell, DIDs as parents, linked resources can have multiple children, controller keys are controller keys for linked resources. When linked resources, the rsources are created from parent DID Document, parent can assert control over one or more resources, and collections of resources.
tweeddalex: Why are DLRs needed? schemas, status lists, trust registries, JSON-LD context files, etc.
tweeddalex: These things are usually stored on Web URLs, which could fail because certain domains fail.
<dlongley> having the DID document be the "object" (in object capability parlance) and the path refer to interfaces on it also seems to match what's being described (DID doc being the "parent", other resources underneath being children under the control of whomever controls the DID doc)
<ankurb> Link to the deck: https://
tweeddalex: This could be a big security risk if you're relying on separate web domains for verification of credential -- we decided to create DLRs to improve the existing paradigm. Looking at schemas, 2012 driver's license, 2015 DL -- both schemas have a lifespan that overlaps, but different schemas, one on left doesn't have height weight, eye color... when VC tries to verify schema, new schema has overwritten old schema. Old schema is still valid, but
can't be verified.
tweeddalex: We want to create versioned resources in a way that is more natural..
tweeddalex: How does a DLR work? you have authentication to update DID Document, identifier in organge... when DLR is defined, you specify unique identifier of collection ID and each individual resources has unique identifier, different type of metadata, resource name, type, and publish resource file associating it with DID and collection ID. On cheqd, sign the resource file with same key material that you update/authenticate DID. DID Controller always
has ability to CRUD linked resources.
tweeddalex: What this looks like in practice... service endpoint, pulls into linked resource metadata... metadata about each individual resource, if we take URL, resolve it, it pulls up a resource... trust registry entry on cheqd... but we have schemas as well. Resources that derefrence to schemas, logos, etc.
<dlongley> (hmm, seems like it should be an assertionMethod verificaiton method that gets used if this is for creating a proof that lives on the resource for later verification by consumers ... but if the proof is used to determine authz for updating/writing the resource then it would be a capabilityInvocation verification method that would be used)
tweeddalex: In the spec, we've defined query parameters, if you want to query resources by a particular name/type... you can create query parameters/strings to fetch specific type of resources, fetch resource, version times, etc.
tweeddalex: Does this solve a global problem? If you're using did:web, probably not useful -- might be good to use specific resources using common syntax, but if you're using did:web, you might as well keep using it... you could sign data integrity on resources, but could build sme sort of architecture like this.
tweeddalex: DLRs have better features when you are linked to underlying ifnrastructure... keys used to create resource update can be proven... controller of resource is same as controller of DID. You can still do this with Data Integrity Proofs on did:web, but not spec'd there yet.
tweeddalex: You can have accreditations for legal entities, for example, organizational trust registires, etc.
tweeddalex: Spec is getting adoption across other DID Methods: ebsi, cheqd, cardano, hedera, canow, besu, iota coming soon -- universal resolver/registrar supports this for ebsi/cheqd and cardano.
tweeddalex: Hope this leads to a world where web-based DID Methods and blockchain-based ones can work... sometimes you need more immutability/provenance, verifyability of updates... maybe did:webvh did:scid uses anchors... spec is in solid draft state, please review. We hope this can make a more resilient mechanism.
Wip: DID Linked Resources define processin gof the path -- how to get form path to resource, what should be common? DID Resolution spec -- we could just adopt it and just use DID Linked Resources ... how do you know if a path is a DID Linked Resource vs. something else.
tweeddalex: In cheqd implementation, we have path-based syntax... `/resources` -- query parameters defined in spec... resolvers that are "resource smart" will see query parameters or path parameter defined by DID Method and know that will fetch DLR.
tweeddalex: We could define something at spec level, but others might need to be done at DID Method level.
manu: This was excellent, Alex. A lot of stuff to like in that presentation.
manu: And +1, the use cases are legitimate and good, stuff we should support. Rather than go down all the things I agree with, I'd like to point out things we can figure out, I hope. You said people have to pick did:web or something else at the end there, we don't want that future, I agree.
manu: As we have rolled did:web out to production there are clear shortcomings, I don't think anyone thinks there are no problems there, if you use it you have the same problem as before with binding to domains. I'm hoping to make one of the other did:web extensions the new did:web with better security features.
manu: We're finding people do really want to better security around changes and to be able to detect changes in the infrastructure, detect DID doc compromises and handle change history and so on.
manu: My hope is that did:webvh can let us back all that history and features in a backwards compatible way onto it.
manu: We can then start talking about DID resources there as well. There's another part of it, where there are uses where you don't want something as heavy weight as DID Linked Resources, which is great, but there is considerable implementation there and you need a little better infrastructure for change history.
manu: If you need really high assurance you want to use that, if it's your profile image on your blog maybe you don't need that.
manu: As an individual, if my goal is to be able to move away from services and I want a profile image that I can use across multiple services but the hosting of the file I want to be in control of, I could do that with the path parameter, but I care more about having the service do the resolution ...
manu: ... One of the things we haven't talked about a service resolve it, so the root of control is still the DID document but I don't have to do countersigning of the resources and so on, because I have control over the DID doc so I can modify what service is used and how the resolution happens and so on.
manu: So there's a set of use cases here where I don't need the complexity.
manu: Of DID Linked Resources; I think there's value there for the not super high security use cases that you're speaking to.
manu: I really want to try to make sure that we decide how to support that use case and that we do this high security and change control stuff as well.
manu: But I wanted to see if there was something simpler that could still fit into the DID path mechanism.
markus_sabadello: The ability to do something similar in a more lightweight way could be the service parameter that we already have -- also important to understand difference between service parameter and DID URLs, similar -- use service parameter, could be able to do something like what Manu described... DID Document points to some place you control, but back to Linked Resources, which are really useful and interested in figuring out how much of that we
could incorporate closer to DID Resolution. Not everything poitns to DID Linked Resources -- for example /whois.
markus_sabadello: /whois dereferences to something, but it's not a Linked Resource -- would be interesting to figure out how we can encourage the use of DID Linked Resources, or at least mention them, but also allow /whois.
<Wip> w3c/
Wip: Agree, flagged issue that speaks to linkedResources.
tweeddalex: A lot of points raised -- I've been speaking to JC about combining work on /whois with DID Linked Resources, so you can have model where you have a DID that issues Legal Entity accreditation (did:a), could be issued to did:b, could pull up resources for did:b... could be useful.
tweeddalex: about did:web moving to did:webvh direction -- problem where genesis VH file needs to be stored in secure infrastructure, if you store that on infra, that could fail -- talking w/ Stephen Curran, can you store initial file and then use did:webvh off of blockchain, always rely on initial genesis log -- could have some type of overlap when you have high assurance / high security needs.
<Zakim> dlongley, you wanted to ask why try to fit that into the DID path mechanism when service query param solves it?
dlongley: To speak to simpler use case that Manu brought up -- do think use case is first use case for service parameters/query parameters -- don't think we should add third approach to do high security DID Linked Resources... so why add a third approach? We have service-based paths, and DID Linked Resources, we might only need those two. I don't think we need something halfway between those things... if you want something lightweight, ensure you have
hosting -- we might need to define particular service type used for interop... might be something to explore.
dlongley: If you want to have a folder that gives you directory structure, you can create service type, base URL in there, and then use relative ref feature.
dlongley: Maybe URLs don't look as pretty -- don't think we want to cut into DID Path to specifically use services to make it look prettier -- at application layer, URL should be opaque, DID Resolution layer should hand back relative ref, hit appropriate service that user configures for public portable data container with path support. ALl of that works today, only piece that's missing is good service type name definition.
<Zakim> JoeAndrieu, you wanted to mention the property linkedResources
<JoeAndrieu> https://
JoeAndrieu: We already have a property in extensions, that does this... we should figure out how to reconcile it, we're going to have these sorts of disconnects... if we add fully decentralized notion, that's one route to go... if we want to unify this, we have to take that registration into account and we're not doing that yet.
<Wip> w3c/
Wip: Issue is 821 is about if DID subjects being DIDs... wonder if we should close 821?
JoeAndrieu: The DID subject is not something in our documents -- the identifier...
<Zakim> manu, you wanted to propose next steps.
manu: I need to go back and re-read 821, but if that's the case we can close that one. We're not done with this conversation, we're now all working with the same information.
manu: Couple of open questions: Do we want to normatively define a service type for doing the simple resolution thing. The second is how do we reconcile the `didLinkedResources` property with the spec and w/the DID Linked Resource spec and is it better off as an extension now or do we want to bring Alex+Ankur to bring some of that spec to the DID / DID resolution spec for generalized things.
manu: Do we want to start cutting out special paths? So "/whois" should we suggest some SHOULDs here -- that you SHOULD use some existing extensions, etc.?
manu: I think we need to at least cover those four questions for the next call and maybe other issues are generated from this.
Wip: Ok, we can create some issues.
tweeddalex: +1 to what Manu said -- we should close 821 because the content of issue is resolved, but I do think conversations today suggest that we should raise new issue about more simplistic service type to dereference to company logo or other things you don't need high assurance on, and then look at high assurance stuff as well (provenance, versioning)... should cater to those as well.
Wip: Thanks all for your time, this was fruitful, let's discuss further. Have a great next of the week!
rrsagent. draft minutes