Meeting minutes
Agenda Review
wip: Going to spend time finishing off the DID URL path making sure we have the right issues created.
… Then look at the vocabulary PR that Ivan posted.
… I think did:core is fine, only a few issues left.
… Rest of the time on DID resolution looking at open PRs.
<ivan> persent+
<Wip> w?
present Ivan
markus_sabadello: Update on DID Methods working group charter.
… Can do it next week.
DID URL Path next steps
Wip: Will put it on next week's agenda.
… I didn't see any issues created.
<Wip> w3c/
Wip: Action item #1 is on issue 821. Manu is going to review it pending close.
<ottomorac> Link to special topic call minutes: https://
Wip: Action item #2 is there is a question around defining a service type for simple resolution or simple dereferencing e.g., to dereference to your profile picture.
… To me, chair hat off, that is an extension.
… Open to thoughts, happy to create an issue.
<Wip> w3c/
Wip: Third thing, there is a conversation around DID URLs and paths in DID URLs and do they need to be compatible across DID methods.
… Summarized by Joe in issue #150.
… Do we want to move to compatibility across all DID methods for DID paths?
… Do we want to start carving out special paths, e.g., /whois?
manu: +1, we need to talk about setting aside special paths.
… This is probably something that the TAG would likely have input on.
… Special path .well-known is in HTTP, so we can have special paths as well.
… People should be able to register special paths in the DID extensions. If you register one, there should be a detailed specification on what dereferencing does.
markus_sabadello: I agree that we shouldn't have special paths in DID Core but to have them defined instead in extensions.
<TallTed> .well-known/did/...
markus_sabadello: Many protocols use .well-known in a consistent way, but it's not part of the HTTP spec itself.
… We should not have it in the core specification, but registering as an extension should be fine.
Wip: What I'm hearing is there aren't any that we need to create. Cutting out special paths should be an extension point.
<Zakim> manu, you wanted to note that we have to establish the registry somewhere/somehow -- probably thorugh DID Resolution
Wip: What changes do we need to make to the spec for this.
manu: We need to establish the registry through some specification, right now the only one is DID Resolution.
… We should say that it goes in the same place as DID Extensions, and we have something in the document that talks about reserved paths and how they work.
Wip: We need to define a registry for special paths.
manu: Also, /whois is a terrible name for a path as it's not always a "who". DID can point to objects.
<Wip> w3c/
<manu> /info would be better
Wip: I'm inclined to move on. Just to summarize, one of the action items is 821 which I'm hoping you (manu) will review and close.
<Wip> w3c/
Wip: Do we need compatibility across methods for registered paths?
… We need another issue for how to register a path.
… I will raise that issue after this call.
DID Vocabulary PR
w3c/did#892
Wip: I want to give Ivan some time to discuss this.
Ivan: There's not too much to discuss. There are actually two things only I added to the PR: GitHub action, but because GitHub actions are always a bit touchy I want Manu to review before merge, and it also required some change on the GitHub setup.
… I think Manu can review. What has to be done is that the visible pages of GitHub have to be generated dynamically rather than as a static thing.
… The other thing is I generated also the context file from the same vocabulary that could be moved somewhere as a result.
… I don't know if we want to do that. Manu, do you want to put it in the same location as the context file for DID?
manu: I'm looking through the PR now, I have minor changes, but it looks good by and large. I think you're doing all the right things here.
We should merge this and see what happens.
… We should merge this and see what happens.
Ivan: I got an error reply from GitHub on the PR, so it must be reviewed.
manu: I agree to auto-generate the context file and the vocabulary. We should get to automatic generation of everything if possible to reduce errors.
… Let's get it merged and fix any issues that arise.
Ivan: What should we do with the context file?
manu: It's just a redirect for now, isn't it? We can keep it as is for now.
Ivan: I'm asking that the tool now also produces context file. We keep it and change the redirect.
DID Core Update
Wip: Thanks for that, Ivan.
manu: DID Core is in decent shape. I can report on the horizontal review. I need to raise three remaining PRs on DID Core. Kevin has an action for one, Joe for another.
… The horizontal review is going well. The conversation on the anti-pattern for TAG is going well. There's a handful of people that think explainers are very good, others are asking why it isn't in the specification.
<manu> Explainers are an anti-pattern write up is here: w3ctag/
manu: We have a lot of comments. "Explainers are an anti-pattern", write-up at #19.
<manu> Rethink the TAG's review intake process: w3ctag/
manu: It has been suggested that the intake process be overhauled to remove explainers.
… Jeffrey has been trying to restructure the way TAG does horizontal reviews.
… The only time an explainer is needed is when you don't even have a specification.
… This happens a lot for Google when they do stuff on the web. TAG has asked that they provide a separate explainer in markdown for doing the review.
… Explainers should be in the relevant sections of the spec, e.g., what problem are you trying to solve.
… So instead of writing an explainer, we link to content in the specification.
… This also ensures that we also don't deviate from the specification.
… It's still in draft state, so please provide input.
… If this goes into the intake process, it would be an opportunity for DID Resolution to go through the new process.
Wip: I'm wondering how likely this gets adopted in a couple weeks.
manu: Unlikely. It's a big change to the TAG's process, it's probably going to be debated for weeks.
Ivan: It will not be done within a few weeks, that's for sure. But that's not really a big problem. We have time. Manu started this very early, so there's a lot of time.
… I'm editor of another giant document and if I have to make an explainer for the ePub spec, that's an awful thing to do.
markus_sabadello: My question has been answered.
Wip: One thing we can do is review the spec to ensure that the explainer has been properly covered.
DID Resolution PR Processing
<Wip> https://
Wip: Into DID Resolution. We'll spend a bit of time looking at open PRs.
w3c/did-resolution#147
Wip: Add to the security considerations section.
ottomorac: After some reviews of the comments, I added details around the JSON-LD context integrity. It's now its own security consideration. What I said is that I added verbiage that instead the DID resolver should use a trusted copy of the context file.
… I specifically opted to use SHOULD rather than MUST otherwise we get into details about what a trusted copy is.
… I struggled a bit with how to obtain the JSON-LD in the first place.
… Reviews are appreciated.
manu: I don't have an issue with the SHOULD. The confusing thing here is the second sentence, saying that a production resolver MUST NOT retrieve context files from remote locations. But then it MUST use a trusted copy as there's no other choice.
Ivan: It's a more general question. DID Resolution does not use JSON-LD. This is something we decided a few weeks ago.
… I guess you could say how does DID Resolution deal with these problems?
KevinDean: my concern with the prohibition of retrieving context files is that there may be additional context files that will not have direct relationship with the did document generation but if we limit the ability to retrieve remote files then we limit the ability of the resolver...
<Zakim> manu, you wanted to note we should be probably talking about apps that use results from a resolver.
dmitriz: On that topic, what it sounds like it's heading towards, and may resolve Kevin's concern, is we would have a registry of context files and corresponding hashes. e.g., Here's the DID context location and hash so that resolvers, if they are loading remotely, can ensure integrity.
<manu> https://
manu: I agree with both what Kevin and Dmitri are saying. I thought what we were doing with this issue is reuse the language in the VC Data Model.
… We had a very long discussion about this in the VC working group and came up with some text that made everyone equally grumbly but seemed to work.
… "You can load remote things but make sure the hash matches something you expected it to match."
<ottomorac> "It is strongly advised that all JSON-LD Context URLs used by an application use the same mechanism, or a functionally equivalent mechanism, to ensure end-to-end security. Implementations are expected to throw errors if a cryptographic hash value for a resource does not match the expected hash value."
manu: We don't say MUST or SHOULD, except for MUST in the base context value.
… If we do that, we get around the MUST vs. SHOULD thing. I agree that we shouldn't prevent contexts being loaded remotely.
… +1 to what Kevin says. A resolver should have the ability to do validation that a document is well-formed. The guidance should not only be for resolvers but for downstream applications as well.
… I think what we might want to do is try to use almost the exact same language as we used in the VC Data Model spec. We didn't put MUST or SHOULD in there.
… Either because it was too late to change or we didn't want to offend those that didn't want to do JSON-LD validation at all.
… The DID Resolution specification doesn't have a base context. It's really about the DID documents that are returned.
… If there's any object that you process as JSON-LD, that's where the warning applies.
… Those are the things that need to make sure that they use a context with a cryptographic hash.
<Wip> w3c/
manu: You can fetch from the Internet but make sure that the cryptographic hash matches what you expect it to be.
Ivan: Getting back to what Manu said and my original question. What this means is that the DID resolver in general, when it gets a DID document, is required consistency checks on the DID document. Is that clearly described in the spec?
<dmitriz> I agree with Ivan (and manu) that it's not the Resolver's ob
Ivan: It's not just a conduit between the one that asked for the resolution and the one that provided the document.
<dmitriz> job, rather. that it's the consumers of resolvers
manu: I don't know if that's true. I don't know if a resolver has to do any checking. Maybe we have a statement that the resolver can't return an invalid DID document.
<dmitriz> and KevinDean's earlier comment about basic structural validation -- that's not a context's job anyways. that's more for JSON SChemas
markus_sabadello: I don't think we have it in the DID Resolution specification. We have an InvalidDocument error but nothing in the spec requires it.
… I don't want the resolver to transform or manipulate the document. I think that's one of the reasons why validation is not required right now.
Ivan: If it is correct, and I believe Markus, then any context statement is an opaque key-value pair in JSON. So why do we even speak about security issues related to JSON-LD if resolution doesn't do anything with JSON-LD.
<Zakim> manu, you wanted to note that we shouldn't require JSON-LD processing.
Ivan: I have the impression that there is nothing to add here.
manu: I think it's that the resolver might do JSON-LD processing, which is why we have that text. Downstream applications should pay attention as well.
<dmitriz> (I'm still struggling to picture _why_ a Resolver would do any json-ld processing)
manu: We should absolutely not require JSON-LD processing. It's something they can do, but it's not required.
w3c/did-resolution#155
<manu> dmitriz, to error check the returned DID Document, to ensure it's well-formed from a JSON-LD perspective.
ottomorac: On this one, I can help with specific wording on the forks to address issue 143 from Kyle. I added a few ways in which it may be disambiguated.
… The part we need clarification on is that a DID resolver that is aware of such a fork should inform the user that the fork can affect the resolution results.
Wip: Kyle was pretty adamant that he wanted some changes. My feeling is that some of this should be in the DID core specification.
<dmitriz> manu -- that still doesn't seem like the Resolver's area of concern. (but the consumer's)
manu: I'm also on the fence on whether we should say anything or not. It's a pretty extreme corner case.
… The DID method should probably state what to do when there's a network fork. I don't think this should go on the specification. We should punt what to do to the DID method specification itself.
… We should say that what to do in the event of a fork is to consult the DID method specification.
… The suggestion is to minimize the PR.
Wip: Do you think if we did a 2.0 in future that it should not be in the DID Resolution spec?
manu: Yes. We should probably move it but we can't make class 4 changes right now.
ottomorac: I think I can say yes, the DID methods should be able to handle that. We are likely to get pushback from Kyle if we say nothing.
<TallTed> can we make a note of that intent, in the current doc, so that it's more likely to be remembered?
manu: We all know and love Kyle but we don't have to do everything it wants. What we should say is that we don't give generalized guidance in the specification as there's no way to cover everything.
… We're presuming that there's just two branches, whereas some have the ability to look across all the forks and merge them. I don't think we can speak with authority on what you should do.
Wip: Could this be made a point in the security considerations section?
ottomorac: Yes, I could minimize it for that.
w3c/did-resolution#102
Wip: This is asking how a resolution provides proof of inclusion.
<Wip> w3c/
Wip: I think the way that we might address this is by defining a property that DID methods can use, possibly differently, to provide inclusion proof.
… The DID method specification would have to define how to interpret the proof.
… The alternative is to define extensions.
markus_sabadello: I'm not sure that there's much more to say. The only thing I would add is that this is linked to other topics such as trust.
… We have sections about local resolvers and remote resolvers, how to retrieve the data, etc., that are affected.
… I think it's quite clear that having this makes sense. Having a specific property in the metadata makes it possible for a client to independently verify a proof from a resolver.
Wip: We're defining an abstract property to be implemented by DID methods so we need proper text to explain it.
manu: I'm worried that we won't have examples across DID methods to show how it could be used.
… Does it make sense to have examples when it's so open to interpretation?
… I don't want to do this without three different DID methods showing implementations.
<ottomorac> +1 that we should not make things for just one did method