Meeting minutes
Agenda Review
Wip: we'll start with talking about Stephen's PR
swcurran: yeah, I think it's ready
Wip: and then we'll talk about DID resolution issues
… manu we did not put any DID core things on the agenda
… should we have?
DID URL Dereferencing PR
manu: there's the ID equivalence one
Wip: let's see if we get to that one
<Wip> w3c/
Wip: let's start with swcurran's PR
swcurran: I can start with a slide presentation
… DID URL can have any combination of URI components
… handling a DID should feel like handling a URL
… a Browser is more similar to a DID Client
… on difference is a DID Resolver
… which is more constrained than a Web Server
… but there are still similarities
… The spec calls a difference between a resolver and a dereferencer
… and I'm still not sure what the difference is there
… and I must confess I merge those two concepts in the PR
… and am not sure if that's OK or not...
… so, fragments are not a DID Resolver issue, the Client handles the fragment
… if the resource is some other resource that a DID Doc, then it should use that resource response's media type
… not sure how Joe and Cosmos feel about it
… because they created their linked resources as fragment identifiers
… because that's Cosmos' best practice
… but I think it's still aligned
… but it stays something only the Client uses
<Wip> did:cosmos is defined here - EarthProgram/
swcurran: Query Parameters. I moved into their own area...like "mini-specs"
… I tried to highlight that the ones involved in resolution are called out specifically
… hopefully they are more complete with normative statements expressed now
… for HTTP, obviously, query params are completely up for interpretation
… whereas, DIDs have some specified
… Path processing. There's currently no clean definition of what to do when one appears
… and `relativeRef` is ugly
… because it has to be URI encoded
… The use cases center around storage location
… paths could also enable redirection
… and there are scenarios where parameters are introduced for handling the path
… so, the idea we came up with is that there would be services
… with a `prefix` attribute in the service definition
… the processing is to take the path, check it against the `prefix`'s of the services, use it to dereference the resource OR return an error if unfound
… the `FileService` type of `service` then would remove the `prefix` from the path, and resolve the rest against the file service
… I used a different example in the slide deck than in the PR
… it uses a different type
swcurran: provides various examples in the slide deck of how did paths could function with his proposal
swcurran: Path + Query parameters, some query parameters might be known to / processed by the DID resolver prior to matching
swcurran: service=<type> is used to limit the types of services that can be used
<Zakim> manu, you wanted to point out difference between DID Resolver vs. DID URL Dereferencer. and to speak to switching off of type instead of prefix.
swcurran: Questions / concerns: 1) DID Resolvers vs. DID URL Dereferencer, 2) Handling "left over" query parameters, 3) Formatting conventions
manu: This is great work thanks. My comments: difference between DID Resolver and DID dereferencer. The purpose is to give you the entire path to the resolver.
swcurran: but it may be part of the resolver....
I think that could be handled with the service type...
we could just define special handlers for these...
manu: we could have a conversation about something like that...
… we did not have the focus on paths before
manu: It looks like the algs also have a focus on type and prefix
manu: if we can switch off from type, we can better understand what the prefix is trying to do
manu: we need a tighter coupling between the type and the prefix
swcurran: Yes but you would the service or service type query param....
swcurran: if you go by type you may have some default ones, but that might be tricky
swcurran: I just used the word prefix as an initial suggestion
swcurran: I would like to avoid being forced to use query parameters to specify the types of services
Wip: We use prefix to understand the service....
swcurran: yes
<Zakim> manu, you wanted to note that you don't have to have serviceType in query parameter.
manu: on the servicetype... I dont think we are forcing it as a query param
manu: this would be up to each implementation...
manu: we can keep the URLs clean and not require that
manu: the reason that I am concerned about switching off from Prefix .... it feels cleaner to me to just say "here are the types that we process that have prefix associated with it.."
manu: this would give us a more clear processing model and helps us avoid collisions
swcurran: we have the service end point, which is a well known attribute, would that help with the path prefix?
manu: suppose we have an implementer that does not use JSON LD... there could be a corner case... we should match on type first therefore...
swcurran: ok I think I can solve that
Wip: I was wondering have you spoken to the folks from Cheqd or Cosmos, they are bound to have opinions on this?
swcurran: yes, my reading is that linked resource is an extension and should no interfere with this....
swcurran: I think also fragment should happen post resolution...
swcurran: the Cheqd folks are using did linked resources and are bypassing query params altogether...
swcurran: I think there should not be any conflict...
swcurran: we are however specifying that query params should suppport "versionid"
swcurran: Cheqd can define the linked resources as a query param if they like in the spec...
markus_sabadello: I think the Cheqd folks are also using a path...
<markus_sabadello> https://
<markus_sabadello> https://
markus_sabadello: these are just some examples of how they do it....
<markus_sabadello> did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b
<markus_sabadello> did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47
swcurran: ok, I will take another look at how Cheqd does it...
swcurran: I will reach out to Alex T., we may need to go to some kind of type
Wip: I think we also talked about a way of how the Cheqd and cosmos folks could work together....
<Zakim> manu, you wanted to note how it might work for cheqd.
<swcurran> +1
manu: Yes, one of the most useful things of this PR is that it would be fully backwards compatible, the other benefit is that since have specific types that define the dereferencing rules... then the Cheqd folks can decide if they would like to use that or not...
markus_sabadello: I cannot speak on behalf of cheqd, but I think it may break a few things of how they operate...
… this proposal may break it because it defines how you have to interpret the path... although this is left to the did method...
swcurran: I think the Cheqd folks would not have to change their URLs... but they might need to change their did documents, just like we have to do it for did:webvh
swcurran: but now having a type param, can allow each did method to decide which approach to follow in interpreting the path...
manu: in response to Markus, I think I read it differently, but maybe there is some language you are seeing in the spec that makes you think differently....
<Wip> +1 that was my understanding
manu: my understanding is the did Cheqd urls based on how they are right now, they do not have servicetype defined...
… maybe we just need stronger language to indicate that you should first use the algs that we define in the spec and if not, then follow a did method specific alg....
markus_sabadello: Looking at the PR, there is some language that doesnt agree with that....
swcurran: Yes apologies, I should have looked into Cheqd more...
swcurran: perhaps we can add language to allow did method specific handling of path, but we try to discourage it...
markus_sabadello: Ok but this feature may not work with all did methods....
<swcurran> +1 to Manu
manu: I am not that concerned, we need to decide how define a standard way whilst still allowing some backwards compatibility...
manu: also we need to acknowledge that in some cases implementers will willfully disregard the specs....
manu: I think we can still have the new standard way and still allow the cheqd or cosmos way of interpreting the path to work....
manu: I would rather not stop us from deciding on this just because a couple of did methods do it differently...
Wip: Yes my interpretation was that this would allow that backwards compatibility...
Wip: if the PR doesnt it say that way, we can still adjust it....
markus_sabadello: I think we should Alex T. from Cheqd to see what they think...
… perhaps they may find a way to make it interoperable...
markus_sabadello: there are some benefits of the cheqd approach...
<manu> yes, +1, we shouldn't depend on HTTPS
swcurran: just to clarify, that HTTP is the service end point... also I noted that we should watch for cycles
<manu> (nor do I think we do)
<manu> ...and if we do, it's a bug :)
Wip: Yes maybe we should reach to Cheqd and the Cosmos team and have a special topic call?