Meeting minutes
burn: gave instructions about scribing
Agenda Review, Introductions
burn: we will focus today's meeting on DID resolution issues
burn: provided an update about Gabe's entire team being laid off at Block TBD.
… That's why he's not on today's call. Gabe has already applied as an invited expert.
DID Resolution Issue Processing
<burn> https://
w3c/did-resolution#37
burn: that link will show issues in the proper order.
… subtopics that reference issues like that will automatically post an update to that issue.
joeandrieu: I think we've moved on from this issue (it was posted five years ago).
… it is understood that at different points in time, your keys may have rotated. So resolvers need to understand to ask for the DID document current at a particular point in time or a particular version.
burn: yes, that's a helpful resolution to an issue. In the WebRTC WG, they called it "overtaken by events".
… however Joe also commented that it would be helpful to make sure it was clear in the spec.
<burn> drummond: if the spec doesn't make Markus' point clearly, it should
<burn> ack
denkeni: key rotation has always been a key part of the spec, so is this a question of whether key state should be specified by a DID method.
… he mentioned that Christopher Allen said once that "everything should expire". This applies to verifiable credentials. Have we ever considered that for DIDs? How does that apply to key rotations?
… this topic needs more high-level discussions.
burn: this is about explicit versioning?
denkeni: should you rotate keys or have to change the DID URL?
jennieM: from the start of this WG, this was a topic: what happens when a DID method goes away completely.
… we can see that in the minutes from the meeting of Sept 23rd at TPAC.
<JennieM> https://
<burn> drummond: this gets deep fast.
<burn> ... the question of the relationship of the state of a did document to a DID (what we used to call a naked DID, without the URL bits) and potentially to a DID URL which could include identifiers of a state. Whether its a version, a time, or something else. This is a complex question.
<burn> ... the original spec is fairly clear about when to use each method.
joeandrieu: this expiry question is a good one. I lean against having some state indicator in the raw DID itself.
… but verification properties should have an expiration. And if they don't, I'd like to understand.
burn: there is more to this issue that was in the initial response that he had been typing in this issue.
joeandrieu: can anyone check to see if verification methods have an expiration property.
drummond: we should clarify whether verification methods have an expiration property?
joeandrieu: if so, that could resolve this issue. If not, then that may open a larger question.
… it also raises the larger question of whether the root DID document might need an expiration property.
drummond: yes, I don't remember that ever coming up, but that could indeed make sense.
<denkeni> https://
denken: I added a link to the section about key and signature expiration in DID Core.
… it raises the question of whether this is a DID Core issue, a DID Resolution issue, or a DID method issue.
… this is relevant because we're going to start DID method standardization.
… it could also be important for distinguishing between DID methods.
… some DID methods may want to take responsibility for this control and some won't.
burn: I prefer this speed of conversation. Makes for better deliberation.
drummond: +1
w3c/did-resolution#28
burn: the real question is whether the DID Resolution spec adequately covers the question of local vs. remote resolvers.
… the easiest way to resolve this issue would be to check with the submitter (Christopher Allen).
denkeni: This question of local vs. remote was "under the radar" when we implemented our DID Resolver because we required developers to verify the VDR.
… so this question is worth investigating further, in particular when a mobile phone is running a resolver.
burn: could you add a comment directly?
denkeni: Yes.
burn: thanks to everyone who was able to come today. This was a good start on some very old issues.