Meeting minutes
Agenda Review
Wip: because msporny can't join us, we're mostly going to focus on DID resolution
… anything else folks want on today's agenda?
APAC DIDWg call
Wip: next week is the first Thursday of the month
… we have been following a pattern of having APAC focused calls at a different time for that region
… however, next week, I'm away next week
… typically, I am also unable at this time, and neither is Dan
… consequently, I'm going to have to cancel next week's call
… unless someone on this call is willing to run the call
… if you are interested in doing that, please reach out
… we may also have someone in that timezone who can run the call and msporny should be there
… I'd prefer not to cancel as we've heard there's good engagement on those calls
… if we can find another chair, we could potentially move the call time to be friendlier for EU and APAC together
… and have a US-side chair run this call
… just something to consider
markus_sabadello: if there's a call for EU and APAC calls, that would be a possibility for me
… when is next week's call?
Wip: it's at 2 am your time
… it's currently marked as tentative
… I'm not hearing any strong concerns around cancelling it
… so I will likely send out a cancellation for that next Tuesday
DID Resolution PR Updates
<Wip> https://
Wip: I'd like to very quickly look through the things marked as "ready for PR"
… if you have anything assigned to you and you're on the call, we could also talk about those
… and assign the ones which are not yet assigned
… let's start with the 3 that are not assigned first
w3c/did-resolution#109
Wip: first up, I have issue 109
… markus_sabadello any comments?
… or is anyone able to take this on?
markus_sabadello: that's an easy one
… if you'd like to get into the commit history, this is a good first issue
swcurran: I'll take it
Wip: k. I'll assign it to you or maybe markus_sabadello can?
w3c/did-resolution#61
Wip: the next one that's ready is 61
… service endpoint construction inconsistency
markus_sabadello: this one is more complicated
… it has to do with the service parameter
… and a relative ref parameter
… they can be used together to point at a service endpoint plus the relative reference
… someone will have to go through the algorithm and fix the references
… and if no one wants to, I can assign it to myself
… but it'd be great to have more contributors
Wip: I agree with markus_sabadello, these issues would be great opportunities to get involved
… we appreciate help
w3c/did-resolution#53
Wip: issue 53 - disallow remote context retrieval
… this is suggesting a normative statement
… this is about nor making remote requests for contexts in a production environment
markus_sabadello: this often comes up with any JSON-LD context, that they should be cached to avoid man-in-the-middle attacks
… there is information in the VC specification that talks about needing to cache contexts
… so we could add something similar here
… it could potentially go in the security considerations section
Wip: something like production DID resolvers MUST cache contexts?
… pretty straightforward, and security considerations seems like a reasonable location
… any takers?
… I'll take it
Wip: I wanted to open the door to JoeAndrieu and smccown
DID Resolution Enhancements
smccown: thanks for the reminder. I'd forgotten
JoeAndrieu: likewise
Wip: we had a bunch of good discussion last week
Wip: and there are about 7 of these left
… it's in recently updated order
… the aim of this is to decide as a group if these are extensions
… and if so, who's going to take on the task of doing the work over there
… or are these core to the DID specification and we should spend time bringing them into the core specification
w3c/did-resolution#38
Wip: should we say that conformant resolvers MUST be public?
JoeAndrieu: I can speak to this real quick
… there's a concern that if you cannot get to the DID document itself, then whomever is preventing that access becomes the new gate-keeping authority
… there's a notion that if you can't get to the document, then you don't have the same guarantees that we were trying to create here
… structurally, we sort of have to allow that you may not have the data--whether or not it is part of an authentication scheme
… these were things we saw in 2019...but not sure it's still a problem now
Wip: I don't think we need to say they are public
… if it's a service you're calling, perhaps there's a way to run your own resolver?
markus_sabadello: do you need to authenticate in order to get the DID document?
… historically, in this community, the assumption has been that it is publicly available
… because if that were not the case, then there is some amount of centralization
… but this does come up from time to time
… issue 79 is related
… Christopher Alan opened that one
… it relates to DIDs within an enterprise or other organization
swcurran: maybe public is a problematic word here?
<JoeAndrieu> +1 "public" is a horrible term
swcurran: did:peer for one is not public, but it does provide it to another peer without authentication
<JoeAndrieu> https://
swcurran: but it's only shared with the other party that is supposed to be able to resolve it
JoeAndrieu: one clarification
… it is not a requirement that local resolution be possible
… some methods do have that as an option, but others do not
Wip: should we continue to discuss this one?
markus_sabadello: we should probably get Christopher's opinion
… or maybe have a special topic call? or dedicate 30 minutes on this topic?
Wip: that's a great idea
… I'll try to find a good chunk of a call on this topic
w3c/did-resolution#7
Wip: this is about supporting DIDs on service endpoints
… DIDs can be used as service endpoints currently
… endpoints are URLS, so they can be set to a DID
… do we need a parameter in the resolution spec that supports redirection?
… so that you can get to the final destination for that service?
markus_sabadello: I remeber that the idea is really useful
… maybe using a parameter resolver would find the final service endpoint
… I don't think anyone has actually explored this, however
… it sounds interesting and useful
… but no one has used it
… so I'm not sure it needs to be in the core specification
Wip: so, maybe the redirection piece is an extension?
… should we be changing any of the specs to show a service endpoint that is a DID?
… that might be an action here
markus_sabadello: but if we do an example, we also need to explain what it means and what is possible
swcurran: my two cents would be to close it and say you can do it, nothing says you can't, but we don't need an example
Wip: good perspective
… let's move on then
w3c/did-resolution#85
Wip: this is about, do we want a parameter on services to find them by type
markus_sabadello: it feels like a really useful feature
… it's very close to the rest of the data model and resolution
… we already have a way of referencing a service by it's identifier
… so adding type seems logical
Wip: thanks, markus_sabadello
… I think it is a useful thing
… but where does that lie? is that for the resolver?
<Zakim> JoeAndrieu, you wanted to say isn't this dereferencing
Wip: or the client post resolution?
JoeAndrieu: my comment is very much in that direction
… this is more about dereferencing than resolution
… because when I do resolution, is the expectation that I'd only get part of the document back?
markus_sabadello: agreed with JoeAndrieu
… resolution returns the DID document
… so this would happen after that and be about dereferencing
… there's another section that talks about different architectural components
Wip: anyone up for championing this issue?
… the work would about how to define the types
… and then how to dereference them
markus_sabadello: you can assign it to me
Wip: go for it markus_sabadello, thanks
w3c/did-resolution#90
Wip: can one dereference a DID document to a specific verification method
… do we want this to be standard across all the specifications?
… we talked about this before
… and manu mentioned it was already in the CID specification
markus_sabadello: I think it's useful and be in the specification
… we can reference the algorithm in the controlled identifier document specification
… another thing manu pointed out is whether it should be a parameter
… which would put it into the URL
<ivan> Manu may have referred to this: https://
markus_sabadello: or should it be an option
… in that way it is separate from the URL itself
… and this case it may be better as an option
Wip: what do others think?
… my question is why not make it a parameter?
… not hearing much interest in this one
… I did open it, but let's leave it for now
w3c/did-resolution#66
Wip: this is related to parameters as well
… things like version and time
… we might add this to extensions
… but there are questions about option use across all methods
markus_sabadello: I don't think this should be an extension
… this is already in use by a number of did methods
… there are use cases where you have `?version_id=` already
… there is already some text around version parameters and examples in the dereferencing algorithm section
… we just need to add a few things about what a dereferencer is supposed to do
Wip: I agree, but we don't list these properties in the did metadata section
… because they're listed in a different section
<Wip> https://
Wip: maybe I misread this
… some of those parameters are in the core spec, but we also list them in the extensions
… but in did resolution we list some, which are not in the extensions list
<Wip> https://
markus_sabadello: yeah, I think you're right
… we have some for URLs, but not for resolution
Wip: what I proposed was maybe not quite right
… I was proposing that they be equivalent spaces
… but some of these are only applicable for dereferencing
markus_sabadello: and the spec already says that
… but you could also just resolve the DID and pass the resolution options then
Wip: maybe that's the change?
… copying the version parameters across
… I'm happy to take on that change to DID extensions
… but markus_sabadello it seemed like there was more to explore here? and maybe we need other issues?
markus_sabadello: yes
Wip: I'll take the DID extensions bit on, but then we should come back to the TODOs in the specification
w3c/did-resolution#59
Wip: k. we have 2 more
Wip: I believe this issue is around asking that one only wants certain things back
… do you want all or some of the metadata, etc.
markus_sabadello: this is about getting a result
… do you want the document and the metadata or just the document?
… to some extent this is possible already
… you can do this with Accept headers and content negotiation
… you could get just the DID document or also include the metadata
… I had a conversation earlier around linked resources
… situations where you can reference images, etc.
… is there a way to just return the content? or just the metadata? or both?
… and what would be the mechanisms for doing that?
… the way it is right now with media types seems straightforward
… I asked a coworker to post about this if it was still needed
<Zakim> JoeAndrieu, you wanted to say this is dereferencing, not resolution
markus_sabadello: so maybe we wait for that comment
Wip: and we can mark it pending closed
JoeAndrieu: it seems to me that resolution would always be the whole document
… and in dereferencing you could use a subset
Wip: I think this is slightly different because of the metadata
JoeAndrieu: yes, but you never get back a subset of the did document
Wip: right. I don't think that is what this issue is asking for
… either way JoeAndrieu you sound aligned with this pending closed plan
JoeAndrieu: yeah. I was imagining this was something else
Wip: markus_sabadello maybe you can talk to the other person about providing more detail?
markus_sabadello: yes
w3c/did-resolution#5
Wip: this is about how do we handle deactivated dids
markus_sabadello: we discussed this a couple weeks ago
… there's been a few more thoughts since then
… if a DID is deactivated and then you try to resolve it, what happens
… currently, you just get info that it was deactivated, but you do not get the DID document
… but there's been discussion about returning the document if explicitly asked
… but some DID methods do not support that
… if the document is deactivated, it's the same as if it never existed
… so we need to review what we say about this currently
… and decide if anything needs changing
JoeAndrieu: I'm confused by what we think we're allowed to say
… DID core makes a clear distinction between revoked and not revoked
… I don't think we get to say you don't have to do that
Wip: part of the discussion is that if the resolver comes across a deactivated did, what should they respond with?
… just the metadata? or the document?
markus_sabadello: current spec says quite clearly what should happen
… and it is not up to the methods
… the core spec says you only get the metadata back with `deactivated: true`
… if you use an HTTPS binding, then it gets a 406 error
… maybe there is a point to providing more information about this scenario
<Zakim> JoeAndrieu, you wanted to talk about the did document when deactivated
markus_sabadello: but I don't believe it is up to the methods
JoeAndrieu: we have had a conversation around whether there is a thing called a DID document once it's deactivated
… you could potentially ask for an earlier time state
… but if you request a deactivated DID, the result is that it should not be there
… I don't think methods can ignore that
Wip: maybe this is just about an extension?
… so, let's move to comments in the issue
… k. I think that's a wap
… next week, probably not going to have a call
… I'll let you know on Tuesday
… talk soon
… thanks, bigbluehat for scribing.
<pchampin> JoeAndrieu, https://
<bigbluehat> pchampin, doesn't look like that says anything about the document itself, only the metadata