Meeting minutes
Agenda Review
Wip: Holidays coming up -- need to cover that, then DID Methods charter, then this WG and work we have to do, then some PRs on exporting terms, READ operation discussion, then Path URL discussion.
Wip: Any other changes to agenda?
Holiday Schedule
Wip: We will have a call next week, but then a break for multiple weeks, coming back on Jan 8th.
<JoeAndrieu> +1 for two week break
manu: +1 for a multiple week break.
Wip: In two weeks, we need to try to make progress on PRs. Will move onto next discussion.
WG Progress Update
Wip: There are a few things around this -- DanubeTech is no longer a member of W3C and doesn't have financial support to be a Member and be an Editor -- Markus will still be around, but until he has more funding/support, he won't be very active. Since he's not in W3C, he can't be Editor, but in practice it's been Markus mostly doing the PRs.
Wip: I'm happy to take on work, but need others to take responsibility to write PRs and merge PRs. Second part is around issue assignment, we have a lot of issues, but issues are marked ready for PR, most of them are straightforward, everyone on call needs to get this done, we have six months to get through everything, need to get 1 PR a week done, that will moev things faster.
Wip: We can assign them to folks, happy to do that, we have limited participants, we need people to do PRs and move work forward.
manu: let me explain my thinking here
… participating in a WG is not a spectators sport
… specifically, invited experts are expected to provide some value to the group
… as Wip said is not a huge amount of work
… every person on this call should be taking on a PR
… if you don't know how to write a PR, write your contribution in an issue
… every person on the call should be able to take a PR
Wip: On the Editors -- you are listed as Editor on DID Resolution, Markus can't participate anymore, do you have time/capacity to step into role more?
Dmitri: I see, didn't realize that about Markus -- ok, will set aside time to work on DID Resolution, do some PR processing.
Wip: That would be great, shouldn't be too much -- but would help if others do it.
DID Methods WG
pchampin: We have issue w/ Chairs role on DID Methods WG -- we are short of a Chair for DID Methods WG -- I will send an email to DID mailing list calling for volunteers from W3C Member, would send a better signal.
pchampin: We can re-appoint Markus if DanubeTech becomes a member again, goal isn't to pull Markus away, just to remove blocking point and have charter go to vote.
pchampin: There are only so many people on the call, I'll reach out for more member orgs on mailing list.
manu: You might also send it to CCG.
pchampin: Good point, thank you.
manu: you might also send it to the CCG. Not all of them are members, but you would have more eyes on this.
ivan: There might be another problem w/ Markus -- if we want to reappoint, he has to be Invited Expert -- giving IE to someone that is a former member of a W3C Member is an uphill battle.
DID Core PR Export Terms
w3c/did#913
otto: This PR is attempting to solve issue about duplicate terms between DID Core and DID Resolution, before we do the PR for DID Resolution, we need to export some terms from DID Core to make it possible to refer to them in DID Resolution. Proposed terms, most of them use DID prefix so they won't conflict, but there are some (resources/services that could work w/ local alias) . Just trying to export terms, once this PR is merged, there will be another PR
for DID Resolution.
Wip: Service endpoint is too generic?
otto: Could avoid conflits by using DID Service Endpoint.
manu: there is a way to deconflict the terms when using them (specify which spec they come from)
… we are contemplating reusing "serviceEndpoint" in CID
<Zakim> JoeAndrieu, you wanted to mention CIDs
manu: so I would not make it specific to DIDs.
… But this looks like a good PR, I will review it.
JoeAndrieu: We should also look at CID spec and see what we need to synchronize there -- service endpoint might not be owned by DID. We can't change CID spec. We should figure out impact.
DID Resolution "Read" operation
<Wip> w3c/
Wip: What is the impact here? Move resolve to read? What are we doing here?
Wip: There is significant change to change Read -> resolve.
JoeAndrieu: I don't think we had consensus -- I think I'm on the opposite side... DID Methods define resolve -- what they dont' define is how they read from the VDR. Bitcoin defines how you read from Bitcoin, Method says how to resolve.
JoeAndrieu: I think we need more conversation.
manu: We need to tease out the nuance here, more discussion needed.
Wip: It feels like what is being said is "Read" as an operation needs to be moved from Resolution spec -- resolver has "resolve" function, which then calls "resolve" operation for DID Method? I'll take another pass and have a look.
Wip: I was looking through did:cel and that defines a "READ" operation -- read algorithm, that's true of many DID Methods... they don't define "resolve", they define "read".
https://www.w3.org/TR/did/upcoming/#method-operations
<Zakim> JoeAndrieu, you wanted to mention you don't "call" resolve on a method
Wip: DID Core spec might say they have to define "read" operaiton, but it doesn't say that ... <quotes from DID spec>
JoeAndrieu: I think one of the things that is happening, is that you don't call "resolve" on the method, it's abstract, it's not something you call -- the resolver PERFORMS resolution... we are creating terra firma between DID client and rresolver, some nuance on the language.
Wip: Maybe we can address Jeffreys' concern by talking about "resolution" instead?
DID Path URL Discussion
Wip: I'll take a look at this some more.
swcurran: I've prepared a presentation about DID URL Path Handling -- https://
swcurran: A DID URL can have any combination of frament, query, and path. handling should feel like HTTP URL processing...
swcurran: Fragments are not a DID Resolver issue... they are handled by client after it gets a resource back
swcurran: thus, we can exclude fragments from remainder of the discussion.
swcurran: query parameters are combined with paths... very flexible -- some are applied/defined in DID Resolution, some are in extensions, some can be combined w/ path handling, some can be applied as DID Resolution path process... unknown to DID Resolution.
swcurran: path processing -- relativeRef is ugly, have to URL encode it... awkward, not natural... there is no clean, DID Resolution definition of what to do with <did>/path/to/file
swcurran: some use cases -- single storage location, multiple storage locations, dreidct to resource in specific location, storage location with parameters for retrieving resource, etc.
swcurran: proposal -- services with a `prefix` attribute -- new algorithm would be:
swcurran: 1. Extract the path from the DID URL
swcurran: 2. Collect services based on the known path-handling types.
swcurran: if service and service-type query parameters are used, consider only services of those types.
swcurran: 3. Determine longest matching prefix in the path and use that service -- if there are none or more than one match, return an eror
swcurran: 4. Use the type of the service to process the dereferencing... DID Resolution spec only defines the FileService type (for now).
swcurran: but maybe not Services... perhaps Resources?
JoeAndrieu: That was a good segue -- I didn't follow the connection between the path and the service? Why would path be mapped to service endpoint?
Wip: The path in the DID URL is used to identify the service and service contains prefix which then uses service endpoint to resolve.
swcurran: I have examples that might be helpful later on.
swcurran: One objection that Markus had was overloading services.
swcurran: The FileService type of service does the following:
swcurran: 1. Remove the prefix from the path
swcurran: 2. Append result to the serviceEndpoint
swcurran: 3. Resolve the resulting URL, if possible (noting errors and cycles)
swcurran: <shows simplest example>
swcurran: <shows IPFS example>
swcurran: Noting that the "<CID>" shouldn't exit on serviceEndpoint.
swcurran: <shows google slides example>
swcurran: <shows whois service example>
swcurran: You can have extensions that are types -- would love to see `/whois` promoted into DID Resolution spec.
manu: I'd support /whois in DID Resolution spec, but understand that's a separate discussion.
swcurran: Path and query parameters -- some parameters are processed by resolver priorit to matching... unknown ones are passed onto path'd resource -- unconsumed query parameters are passed on.
swcurran: questions/concerns?
<Zakim> JoeAndrieu, you wanted to ask about getting rid of service altogether
JoeAndrieu: Seems like what's happening, using service property, use path to map to service properties -- mostly I like what you've done here... can we get rid of service as a parameter? We could use prefix to do that? Service part always felt weird to me -- possible?
swcurran: So, remove service service-type behavior?
JoeAndrieu: Yes.
manu: +1 to JoeAndrieu, I would like to get rid of the service query parameter if we can do that
… the cleaner the DID URL processing, the better for developers
<JoeAndrieu> +1 to needing to think through getting rid of service. might be hidden dragons
manu: We might need to thin kthrough removing service in this algorithm.
Wip: Removing service and service-type -- might not want to do that? One specific service type that you might add into possible services that we might have for path... there are other types.
Wip: We don't want to only identify them by prefix, which we might not have.
pchampin: Bikeshedding point... don't like "file service", maybe subpath service, not always resolving to a file
<ottomorac> +1 to PAs comment
manu: to what Wip said, what I meant was "getting rid of the service parameter for this use case"
… we need to do more analysis to be sure we don't lose anything
<Zakim> JoeAndrieu, you wanted to say they can all have prefixes. this is about how to get from a DIR URL to the service.
swcurran: you are saying that the services in the DID doc would be used
… but the service and service-type parameters would not
manu: yes
<ottomorac> Manu overall you think this fits ok with what the Cheqd folks have?
JoeAndrieu: I think we're mostly aligned -- you said something that gave me a bit of doubt... if we overload serviceEndpoint properties to ping off of prefix, then we no longer need query parameters that are service and service type -- but we woul dlose type function... as long as you can have multiple service endpoint sw/ same prefix, you can have multiple endpoints w/ same type -- keep DID Document the same, we had used service parameter, if we move to
path, look slike it might be a godo way to do it... might be able to get parameter together (service and service-type), maybe we use different property?
JoeAndrieu: Could have `path` or something else, new property where you did matching to path to get metadata for how you dereference particular file -- don't know if we can get rid of service, but maybe?
<Wip> +1
JoeAndrieu: Might create confusion?
<JoeAndrieu> +1 to ramifications
manu: the only reason I didn't go that far is that I don't know the ramifications
Manu: Yes but need to check the ramifications of this....
manu: I agree it might cause some confusions
Manu: What Stephen said is my position
Manu: Joe you are right this might cause some confusion...
Manu: we could encourage this new path mechanism and over time get rid of the old way with service...
<JoeAndrieu> +1 to that proposal to split the innovation
Wip: I don't think we can get rid of service and serviceType -- but sometimes you want to retrieve services from DID Document, like in BTCR2, we want to query DID Document, we just want to get all services -- might be same in DIDCommv2.
swcurran: I was amazed to discover that not only a DID Resolution return a DID Document and a resource, but there is a thing that says if you set accept, you get list of services back -- service endpoints, so that's what a DID Resolution could result in -- that's why we can't get rid of service and is being used.
<Zakim> JoeAndrieu, you wanted to say you query for #service
JoeAndrieu: I think we can get this same behavior through another mechanism
swcurran: The current spec allows result of array of services as return type.
ottomorac: Wondering, Manu, if you know what did:cheqd is doing?
manu: Not me :) someone else
swcurran: I did look, would be improved by what we're doing here.
<JoeAndrieu> cheqd is returning data in the metadata
<Zakim> manu, you wanted to get back to Stephen's proposal? and to
<pchampin> +1, passing leftover parameters only seems brittle
manu: We might have to pass more query parameters on than just the leftover ones
JoeAndrieu: cheqd have to pass properties -- did document metadat holds linked resource mechanisms...
swcurran: if this was available ahead of time, this might have been done differently to achieve the same result.
swcurran: Anything else on this approach?
<ottomorac> Regardless great work here by swcurran, kudos for taking this on!
Wip: It might be best to close existing PR and resubmit a new PR.
swcurran: Yep
swcurran: Anything that is defined like versionId and versionType should be in a formal part of spec -- removed it from another place and moved to its own section, what amount to minispecs of what service parameter means, what serviceType path resource will be -- I think that is important, wonder if folks have opinion on that?
manu: I didn't quite understand the question, we need more time to discuss it
swcurran: There are a set of things that are query parameters, but they are not specified clearly -- might need to add that.
Wip: This is a good feature, appreciate the effort on it.
<ottomorac> thanks!
Wip: See everyone next week!
<Wip> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/