Meeting minutes
Agenda Review, Introductions (5 min)
<Zakim> manu, you wanted to note DID v1.1 CR
manu: I just want to make sure that DID v1.1 candidate recommendation is taken forward.
wip: I think it's been a holiday this week.
manu: That's going to be a problem to publish it on the schedule that we agreed to, which is the 19th.
wip: I'll ping him.
DID Resolution Issues \[1\] (20 min)
wip: There's a few issues, not labelled.
<Wip> https://
w3c/did-resolution#274
wip: Four to discuss. I'll probably jump around a little.
… This is from TAG review. It's pointing to a fuzzy statement we have in the spec around proofs.
… In the DID document metadata and the DID resolution metadata we define this value called "proof" but one of our sentences makes it sound like not much of a proof, e.g., "this is only a proof if you trust the DID resolver".
… I looked at it, and I feel that proof in this context is more like a data integrity proof. The problem is both proof values in our spec are just placeholders for DID method developers to fill in and may not be very good in that respect.
… I don't feel that there's guidance about what we should do with the proof.
manu: The purpose of this is so that proxies can cache DID resolution results and you could do a lot more edge caching with this mechanism.
… There would be some resolver or set of resolvers that you trust out there, and you don't have to talk to them directly to get the results. Rather, you can talk to the caching layer, and the caching layer needs to talk to the upstream resolver e.g., only every five minutes.
… You need to trust the upstream resolver but we haven't defined this at all, so maybe we should delete the sentence until we refine it. I don't feel give where we are that we have time for it right now.
<Zakim> JoeAndrieu, you wanted to ask about implementations
joeandrieu: I don't feel that caching is a legitimate use case. It's an echo of the proxy conversation. +1 to your proposal to remove it, and I don't think that we have any implementations that do this.
… We should start to figure out what the use cases are so we can update the spec.
wip: The simple solution is to delete this sentence, but it points to a bigger problem that the whole proof property is a little questionable. It took me some time to realize that this proof property referred to a data integrity proof. I think the proof in the DID document metadata is more of a proof in that you could provide e.g., all the
… transactions in Bitcoin that led to this document.
… I don't know what we're trying to gain by saving this proof name in the metadata without telling anyone how to use it.
<Zakim> JoeAndrieu, you wanted to say the immediate proof is from TLS
joeandrieu: I agree with everything you just said with the proof being a data integrity style attachment. But we are using TLS, so we can prove that it came from the resolver we think we're talking to.
… I think we should remove the proof from DID documents because we don't have a firm definition. If you have a resolver you can trust, you can trust what it provides.
<ottomorac> dev.uniresolver.io
ottomorac: We just mentioned that very few or no people are using the caching feature and I'm curious about that. I asked Gemini, and it came back with saying that the DIF universal resolver uses caching.
<ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK
ottomorac: There's also one in Affinity that I believe is built in Rust.
… There's also one in Python that mitigates what's called "Thundering Herd" problems on a resolver.
<ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK built by Affinidi to add a high-performance caching layer to the Universal Resolver architecture. It is designed to minimize the latency of blockchain-based lookups (like did:ethr or did:indy) which can be slow.
swcurran: We use short caching to prevent multiple resolutions in five-second spans where each one involves pulling the same DID document. So, short caching for what amounts to a single activity prevents going out to the source every time for the duration of the activity.
… We have a TTL attribute as well.
<Zakim> JoeAndrieu, you wanted to say it isn't that people aren't caching, its that we have not defined a standard way to do that with any guarantees of integrity
<ottomorac> dev.uniresolver.io: often use Nginx or similar reverse proxies to cache resolution results based on the DID URL.
joeandrieu: It's not that people aren't caching, it's whether we come up with a standard way to guarantee the integrity of cache results. Right now, if you are using the DIF resolver, you have to trust that they're giving a good result, but we don't have a way to know that any resolver that DIF proxied to gave you a valid result.
manu: I agree with Joe. We should just delete the sentence. We're out of time.
w3c/did-resolution#289
wip: I raised this because I was confused about a few things that Steven raised. I came to the realization that this statement in the spec that support for DID parameters should be optional. Should it apply to DID methods only and not DID resolvers? It feels strange that a DID resolver is queried with a set of parameters, some of which it doesn't
… understand, and then just drops them. How does the client know that it has happened, and will the results be different because of it?
… If a request has DID parameters that you don't recognize, you should fail, and the client should change the request.
<KevinDean> +1
<Zakim> JoeAndrieu, you wanted to say the requester may not be the did creator
joeandrieu: I think I disagree, but you're saying two things I'm confused by.
… The requestor is likely not the creator of the DID. At their level, it's an opaque stream. If I've given a DID on a business card, I don't know how to unpack it.
… One thing that was confusing was the statement that they have to understand all the parameters that they process.
… If they process it, they understand it.
wip: If you're talking about the client, I agree. They don't need to understand the DID itself, but they need to understand if the DID resolver dropped any of the parameters.
swcurran: Can we learn from HTTP here, where if you put in a parameter, if the web server doesn't understand it, the parameter is silently ignored?
… Do we add something in the metadata to say that a parameter was ignored?
… The only possible exception is if it's one of the core parameters. Every resolver should handle them.
<Zakim> manu, you wanted to note I agree in general, but wondering about corner cases such as foo=bar in a path?
swcurran: It shouldn't error off if it couldn't process them.
manu: I like what Steven just said. I think the problem with "it must" is that I'm wondering what happens with a parameter meant for a path. People aren't going to encode these things in relative references.
… I like Stephen's solution that you must process the parameters defined in the spec.
… You're not going to throw just anything at a resolver and expect it to handle it.
<Zakim> JoeAndrieu, you wanted to say they trust that resolver for that method
manu: I think this is as good as we're going to do for this iteration of the spec.
joeandrieu: I push back against more parameters that are "musts", as that puts too much of a burden on each DID method implementation.
<ottomorac> +1 to what Joe is saying
joeandrieu: I think this is overblown, because if I trust a resolver for a DID method, then it should handle every parameter defined by the DID method.
<Zakim> Wip, you wanted to mention version
<JoeAndrieu> +1 to "if you implement this property, it should do this"
wip: I think we talked about this. There are some DID parameters like version ID and version time, where if you're implementing a resolver for a DID method, then you must implement support for those parameters.
… If someone passes in a DID with a version ID and the DID doesn't support it, then I just ignore it.
KevinDean: I agree with Joe in that if a resolver supports a group of DID Methods, it should support the parameters for those DID Methods. If someone passes in a parameter that DID Method doesn't support, such as versionId, that's a problem for the requesting client, they're asking for something DID Method doesn't support. The best I think we can do is return some metadata on ignored parameters. To Joe's point, if I'm asking a resolver, any parameter
… that's in the spec, plus ones in DID Core, should be supportable as defined in the spec for method X.
manu: I think this just comes down to just how strict the resolution process should be. When we detect an error, do we fail or just warn?
… Developers using vibe coding etc. are not going to check metadata etc., but they don't have the time to learn it all anyway.
… The system loudly complaining or refusing to proceed is sometimes the better option.
… We need to decide on the philosophy and apply it evenly across the algorithms.
swcurran: I would make it a warning and put it in the metadata and return it to the client. I don't think it's as much of a concern for this case.
<Zakim> manu, you wanted to note "strict mode" might be an option.
manu: One thing we could tell people is that there's a strict mode that forces an error rather than a warning.
<ottomorac> I like the idea of an optional strict mode
manu: I'm concerned that there's going to be some kind of horrible security error by ignoring the warnings and that's going to come back on the ecosystem.
DID Resolution Ready for PR \[2\] (5 min)
<JoeAndrieu> +1 to considering "strict mode"
<KevinDean> +1, but it's another parameter...
w3c/did-resolution#286
wip: Someone needs to do a spec review with an eye to references to DID document properties like the DID resolution extension.
… Some are extensions to DID resolution, some are extensions to DID document.
ottomorac: I can work on it, but not immediately.
w3c/did-resolution#287
<Wip> https://
wip: I noticed that some of the properties using date/time aren't using the up-to-date definition of date/time.
… Every option we have for a date/time object should point to this definition rather than rehashing it.
… I'll do it when I can.
DID Extensions question - How to handle PR 651 from Jonathan Rayback \[3\] (5 min)
ottomorac: So, I believe that this came about because of the did:webs method that Jonathan is involved with. He's proposing to add this conditional proof 2022 as a type.
… Should he engage with the group and discuss it?
<Wip> This is the PR w3c/
ottomorac: I saw some comments that are beyond me, and I wanted to get guidance from the group here.
wip: I think this is a good discussion to have, as we haven't really discussed a process for DID extensions,
swcurran: My issue is that there's no detail on what this means. It's replacing an existing one with only the change in the year. I don't know what I'm approving. At least with the DID method registry there's a pointer to a specification. This has nothing.
… I don't have the history with this group as to what is supposed to happen.
<manu> https://
<ottomorac> I believe this is related to did:webs
manu: +1. We allow just about anybody to register something as long as there's a spec.
… I note that the spec is very light on detail, but it does exist.
<JoeAndrieu> +1 for this being a VC-related feature
manu: I think this needs to go into the VC extensions repo, not the DID extensions repo. Ultimately, data integrity should be its own thing.
… What we might try is move all of the verification stuff into the VC extensions repo.
<manu> https://
manu: The only thing I'm wondering about is the type. We don't specify the classes of the types in the VC extensions registry, whereas we do that in the DID extensions registry.
… High level, I think we tell them to register in VC extensions.
swcurran: My concern is that I didn't even see the link in the comment. The text in the PR has no link to that spec.
manu: It's there, line 1523.
manu: What they're doing is not wrong. The problem is us. We have some types in the DID extensions registry and the data integrity types in the VC extensions registry.
… Let them register in both places and we'll clean it up.
… Tell them we'll figure out the proper place in time.
<ottomorac> Hello @jrayback
<ottomorac> This should be registered in the VC Extensions Repo: https://
<ottomorac> in addition to here. Apologies we are figuring out the process for this.
<manu> also, allow registration in DID Extensions
ottomorac: I just pasted my potential response in the chat.
DID Resolution Threat Modelling (continuation) \[4\] (20 min)
<Wip> This is the repo - w3c/
joeandrieu: I don't have a lot scheduled as the repo isn't quite there. PA has some time off. We don't have GitHub Pages setup yet, so it's not a functional place to work on the spec.
… Who are the editors? I've volunteered, does anyone else want to join?
<manu> +1 for JoeAndrieu being the lead Editor
wip: Anyone want to help Joe?
ottomorac: I believe that the best person is Steve McCown.
SteveMcCown: I'd be happy to help.
<ottomorac> :-)
<ottomorac> Steve Mccown would be ideal
joeandrieu: We're not ready to go into Echidna. We have published the confidence method.
… So we'll just get the GitHub pages to show the current draft.
… I'd like to do a deep dive once we have a first draft list of threats.
wip: Do you think it's best of have a full call on that?
joeandrieu: We could do a full call, but I think half an hour is better if we want to do it in the main call. It would also justify a special topic call.
… Let's start in the main call until we get a sense of the scope of the work.
… I think we can start next week if Steve McCown has time.
smccown: I'm at a conference all of next week. I can work on the side during that time, but I might not be here at the next meeting.
joeandrieu: We'll do a check-in on next week's call and do a detailed session later.
<Wip> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/