Meeting minutes
Wip: Is special topic call structure ok?
manu: It would be good to know what the topic is in the meeting invite.
TallTed: Yes, that would be good.
Wip: Ok, we can do that.
DID Resolution URL/Path/Query Parameters
markus_sabadello: Hi all, welcome back after the holidays, let's quickly summarize.
markus_sabadello: DID URLs and the Path and Query components... let me share a slide.
Slide showing examples of DID URLs from TPAC 2024 presentation.
markus_sabadello: This shows query parameters, versionTime, transformKeys, path structures, at a high level the question is: How much of that do we want to define in which place? Which document?
markus_sabadello: We are defining a number of query parameters like versionTime in DID Specification, and we elaborate on them in the DID Resolution specification, we decided that we would move that into DID Resolution spec. Created PRs to move DID Parameters into DID Resolution.
markus_sabadello: One of those PRs has been merged, other hasn't yet.
markus_sabadello: Status of discussion is that we'd define in DID Resolution a number of parameters like versionTime, service, and define how to process them. We haven't talked about path yet, what it means, where it would be specified, to what extent are they method-specific/independent.
manu: There are three categories that we care about, I think.
manu: We need to establish rules across all DID Methods, I think that has benefit -- for query parameters, fragments, paths.
manu: The easiest thing to do is probably query parameters, algorithms/processing rules that are the same across all DID Methods.
manu: The second easiest are fragments -- we care about fragments in the DID Document and fragments that apply to a resolved URL.
manu: The third are paths -- I think we need to discuss how did:web works and paths... the whole colon syntax is awkward and I'd like to see if we can "fix" did:web to use paths by default so it doesn't look strange to most developers that use the web.
Wip: A couple of items, on query parameters, what are the criteria for adding new parameters to DID Resolution spec? What meets the criteria? What's a useful parameter to define in DID Resolution?
wip: The first thing is about query parameters. What are we looking for in adding parameters to the specification? What are the common parameters for all resolutions?
Wip: Regarding the path stuff - path resolution is either defined by DID Method or the client might do resolution.
markus_sabadello: On the last question, where client would handle path -- happens in some applications related to Decentralized Web Nodes -- some DID URLs where some of the query/path parameters are processed after all the DID Resolution is complete and handled by a separate application / client-side application.
markus_sabadello: I've seen quite a lot of diversity in how path and query are used and what part of a system processes them.
markus_sabadello: Wrt. spec today, current text allows for a lot of flexibility -- DID Method might define how to handle path, extension spec might define how to handle parameters. Client can dereference path or query part... that's general discussion. How much do we define, in what places? At moment, we have more experience w/ query parameters than with path parameters.
markus_sabadello: With query parameters, we have five -- several more in DID Extensions registry -- important to point out that we have extension registry for query parameters, and in DID Resolution, we have open issues that propose even more parameters. Between 10-15 parameters proposed. Not many extensions to path.
manu: Going back to something Will said, what makes a good thing to standardize?
<pchampin> sorry I'm late
manu: The answer to that is that it must be generally useful. If it's a parameter that applies to all DID methods like versionTime or versionID, then it's something we define.
… I think that should be the bar. Do we think that's generally useful? If it is, we define it.
… Once we define it, should we allow DID methods to redefine it? Our answer should be no. If you want to do something like versionTime that isn't versionTime, register it as an extension.
… If we define it, we should tell people you can't redefine it. The same applies to fragment identifiers.
… I think those are the only two use cases. We can define these concretely and tell DID authors that these are the restrictions.
… Path parameters might be a little different. I don't know if that's true. We can say, by default, this is how you interpret the path. But maybe we can provide flexibility for a DID method to define it differently.
… I don't know if there's a use case for it, so if someone has one, please provide it.
… Any DID method, like did:web, that uses path, we should use as examples and ask if there's a generic way to resolve paths. If two DID methods define different ways to resolve paths, then we shouldn't define it in the spec.
… We've already made the decision. We have defined query parameters in the spec. We can define them more formally and get clearer on fragments and on paths.
markus_sabadello: I agree with all of what Manu said, if we define certain parameters, DID Methods can't override that.
markus_sabadello: We do have an algorithm in PR now, open PRs -- structure of algorithm would be: validate input URL, resolve the DID to DID Document, separate fragment and process that later, if there is no path and no query, then the result is the DID Document.
markus_sabadello: Then the algorithm could define how to process well known parameters, we could make a judgement call on which ones are generally useful, as Manu said.
markus_sabadello: We could have version ID, version time, service, relativeRef, for all of them, we could specify in DID Resolution, how to process them.
markus_sabadello: After that, we could leave flexibility, if DID URL contains a path or query, we say DID Method can say how to dereference path or query part, or extension specification could do that.
markus_sabadello: Finally, or client can dereference URL in application-specific way... all the wording/structure could be included, at a high level, could be done in a well known resolution parameters in DID Spec way. Everything else, we delegate to DID Methods and specifications. Still leaves open what to do with path, identify common path structures?
Wip: In spec, everything in the path is delegated to DID Method -- nothing in spec is core... what would it be like to bring something into core spec? What about /whois -- everyone would have to use it like that?
<Wip> ack ivan
Wip: What would it look like?
markus_sabadello: The /whois, that's exactly why this topic has come up, first time we see a proposal to standardize the path component to some extent -- this has come up with did:webvh method, also interest to standardize /whois across different DID Methods, do we want to get into the business of standardizing different paths as part of DID Resolution itself, or to just create an extension registry for that.
markus_sabadello: We do have an extension registry for query parameters, don't have one for paths -- for /whois, we dont' necessarily define specific paths, but could have extension registry where initiatives and proposals could be listed.
<Zakim> ivan, you wanted to react to markus_sabadello
ivan: I didn't see the rest of the algorithm, so maybe it's there, what happens if we get an unknown or badly formed URL? In HTTP, it's ignored (I think), do we need to be more careful in this case?
markus_sabadello: If it's malformed, doesn't conform with the syntax, then that's the first item -- error is returned. If there are some parameters that are dereferenced, in DID URL, two query parameters, dereferencing software knows one of them, but doesn't know the other, this isn't covered in the text right now.
markus_sabadello: maybe the answer is to just ignore the unknown ones or raise an error.
manu: I think it might be a little premature to standardize specific paths.
… The question I don't have clarity on is, what is a path in a DID URL?
… Maybe it's just an extension of a fragment.
… We have two paths. We have paths into a DID document, the path to a node.
but before, we said only this was valid:
did:
manu: Then there's pathing to actually get to the DID document, meaning in did:web (for example: did:web:foo.example/bar/baz
… I'm wondering if there are any kind of rules we can add.
markus_sabadello: I think we can do the first thing, but it would be method-specific... something that works for did:web and other web-based DID Methods. I've seen some usages of path where DID URL with path has nothing to do with DID Document, path has nothing to do with main DID Document, path doesn't lead to another DID Document, but adding a path to a DID and dereferencing it could return any kind of resource.
markus_sabadello: For example, you could get JSON Schema file, or PNG image, or PDF document -- that's how I've been thinking about it -- just like HTTPS URLs, the path allows you to namespace resources under the domain.
markus_sabadello: I don't think we want to restrict the path too much, we may want to register certain path structures like /whois, and I think we want to enable what you said in IRC for web-based DID Methods, but also allow other DID Methods to define other ways of using the path to reference any kind of resource.
Wip: It feels like first example Manu gave, it would mean that did:web would not be able to support any other path mechanism... can we have first mechanism but also support other paths?
manu: That's the discussion we need to have. I think we can have other path structures. I agree with what Marcus is saying, maybe we need to figure out what the use cases around paths are.
… There are use cases for static paths. With a static path, I think you get back a verifiable presentation. I think it's premature to standardize static paths in DID resolution.
… That's one class, a static path tacked onto a DID identifier.
… The second class is you have the base DID identifier and you have the path tacked onto the end, like did:web, so instead of awkward colons, you have proper paths, which may require changing the ABNF.
… That path can lead anywhere. You can get any resource: an image, a JSON schema file, whatever. We're just trying to make it easier for DIDs to fit into URL-based infrastructure.
… In did:web, I don't know what you would expect. I think that's why we distinguish between colons and slashes.
… Then we get to Will's use case, I think we can support other things. If the slash path mechanism can't achieve the use case, then you can use colons, and there might be different use cases that can use both.
markus_sabadello: I think the did:web use case and how I see it, where did URL with path could lead to anything, those two use cases are fully compatible -- path can identify any resource including another DID Document. If you do did:web:foo.example/a/b/c could dereference to another DID Document. For did:web, we have colon syntax, some places where you could have a DID but not a DID URL, certain specs like DID Comm has a sender/recipeient, and spec says it
MUST be a DID, not a DID URL, I think that's one reason we have colons, so it doesn't look like a path, but underneath it's a path.
markus_sabadello: I think that might be a historical reason... but on DID spec and DID Resolution spec, all we're talking about is possible.
Wip: Good discussion, what are the concrete next steps? Do we need to create issues?
Wip: Sounds like we should have paths extensions list in DID Extensions, so figure out use cases for paths.
Wip: We might want to finalize query parameters in DID Resolution spec?
Wip: Some work around fragments to further define how we handle fragments?
Wip: We need to capture some of this as next steps.
ivan: I tried to look at document and understand how fragment IDs work -- if the fragment refers to a key within the DID Document, what do I get back from the resolution? The whole DID Document or only the key?
markus_sabadello: In the DID URL Dereferencing section, there is an algorithm that is in two parts -- dereferencing the resource and dereferencing the fragment.
markus_sabadello: If you have a DID URL; the idea is you dereference the resource, get the DID Document, and then look for fragment in there.
ivan: The problem I see, if I remember, the JSON-LD spec says what the fragment id means, but doesn't say what happens in a specific protocol. I don't think this answers whether I get back whole DID Document or I get back only portion which contains the key. The problem is that in the case of HTTP URLs, I know when I get HTML5 with fragment, I get whole file and fragment is processed locally by the client. It says what happens on the wire.
markus_sabadello: In an earlier version there were more details on how to process for JSON-LD specifically, find portion of JSON-LD document, value of ID property, return that object, feedback was that this should be removed because it's not defined by DID Resolution. Defined by the media type, the content delegates this to the media type.
ivan: Let's just not this and discuss later.
pchampin: Going back to slash / thing -- currently, when I look at a URI that starts with did: -- I can unabiguously know if it's a DID or DID URL, then that means it depends on the method, the constraint on DIDComm becomes more error prone. Then if you don't know the method, you can't know what to do -- find this concerning, second part, looking at algorithm, it says something about th epath, but the algorithm needs to be more complex if the resolver knows
the method, generic algorithm, path known to be part of did or did URL -- we should consider that if we allow paths in DID itself.
manu: I think that's an excellent point.
… Two things. Regarding the thing that Ivan mentioned. We had this in there before but we chose to take it out. Most fragment specifications say that the fragment is something the client should do, true for HTTP and other URLs.
… Ivan, I think in general we can say that resolvers are strongly urged to return the entire document and fragment processing is done locally, unless there is clear instruction that the DID resolver handles the fragment.
… In general, we do have a strong feeling about how we would like people to do this, aligned with HTML 5 and the client does the local processing.
… But that local processing may be made easier by the resolver.
… The other complication here is that the DID core spec is the thing that defines what the fragment means and how to process it.
… In that spec, I think we can say what I just mentioned, that we strongly urge the behaviour of the client handling the fragment.
… I think the biggest concern I have with pathing is that if we allow pathing in the DID identifier, then all of a sudden you need a more detailed understanding of how to process that specific DID method.
… But I think you have to do that anyway. I think applications will know the class of DID methods they will be working with, therefore they will know how to process the path on that DID method.
… You always have to a fundamental understanding of the DID method, or you need a resolver that has that understanding. In every case, the DID resolver knows if it is dealing with a path in the DID syntax or a path in the URL.
markus_sabadello: Yes, comment about Ivan's client-side processing statement -- when it comes to fragments, it's a good thing if fragment is dereferenced on client-side, as Manu said, it's also possible to have resolver to instruct to do that fragment processing as part of resolver service. It's also possible to have complete resolution process locally, for did:key, there is no client/server, resolution is entirely local, that's why in algorithm section we
tried hard to not mention anything about clients/servers, that's how DID Resolution differes from DNS Resolution.
markus_sabadello: in DID Resolution you don't necessarily have a remote server, there is some content in Section 6 that covers these concerns.
markus_sabadello: Maybe review client-side dereferencing, some parts can be executed in remote service, some processed by remote client. Trying to keep those separate. The algorithms note inputs and outputs, but doesn't say what part of architecture processes each part.
markus_sabadello: There are open PRs, I think they cover some of what we've discussed in terms of enabling DID Methods and extensions to specify certain path structures. One new issue we could create is to create extension registry for paths, like we have for query parameters, one of conclusions, otherwise what we've discussed should be pretty much possible. Like /whois isn't prevented. PA's comment about the path, need to think about.