Signing validation is not defined.

[TomCJones]

As i understand signing, the only way to validate a signature is to resolve the did at the exact (with in a few seconds) time that the signature was made. The did resolution times are already at least 10% of a minute and that time will undoubtably climb as the methods become more popular. I would suggest that the only way for signature validation to be feasible is to create some sort of caching of the did (and/or did doc). Another way to put this is that did should have a validity period of (say) one week. Otherwise every signature validation will require another did resolution.

[TomCJones]

I thought of a better way to do that so that the user could revoke at any time. When the resolver gets a did the validity period can be specified for the time that it was created/rotated to the present. That claim (what i am calling the did resolution structure) could then be cached and used for the specified period.

[jandrieu]

What signature are you talking about?

[TomCJones]

could be any document at all, including a verified claim or even a revocation, which must be signed by a valid did key after all.

[jandrieu]

DID Documents aren't necessarily signed. The only way to validate them is through resolution. Signing of other documents are out of scope for this spec, so we should take that issue of the table.

For an external resolver, it may be appropriate to sign the returned data and it makes sense to include how to do that here.

However, I don't understand your claim that "As i understand signing, the only way to validate a signature is to resolve the did at the exact (with in a few seconds) time that the signature was made."

A signature can be validated at any time using math. That's a separate issue from how long you should cache the result from a resolver. I expect I'm not understanding your concern.

[TomCJones]

right - if a key is revoked/rotated, it should not be a valid signature after that given date. So it is no longer simple math, but a trust decision as well. If the use of dids are outside the scope of the committee, who will determine if they are good for any purpose?

[jandrieu]

A key isn't a signature.

Ah... you're talking about using a DID to sign something else.

That's a valid use case, and there are tons of ways to do it. But it is out of scope for both DID-Resolution and DID-Spec. It probably goes into a new spec, e.g., DID-Signing.

The DID spec defines how DIDs represent the information necessary for resolving to a DID Document. DID resolution defines how that you resolve a DID to a DID Document.

These are just two small steps towards a full flow using DIDs for any number of things. We have intentionally adopted a divide and conquer approach to work through these in a step-wise fashion so we can build out what works and standardize as we go. Think of it as defining the IP datagram before UDP and TCP, which in turn were defined before HTTP, SMTP, and SSH.

Yes, the IP datagram spec by itself doesn't do much. That's the point. It's a concrete, minimalistic specification upon which later specifications build. DIDs are like IP, DID resolution is like TCP (or perhaps DNS). Each minimalistic to help move things forward without analysis paralysis of trying to solve everything all at once.

It would be a non-starter to suggest a monolithic end-to-end DID-based identity stack as a single specification.

[TomCJones]

If this problem is not solved there is not a single use case of any interest to me where the did can be used.

[jandrieu]

It will be. Just not in this spec. It's like you're saying because the IP spec doesn't include http, ftp, telnet, etc., that it isn't of interest.

That may be true and perhaps you'd be better served waiting to focus on the specification higher in the stack.

HOWEVER, the use cases driving these specifications do include the entire ecosystem, because that's the point of the use cases. They describe how it will ultimately be used and, in particular, what you can do with DIDs that are unique that you can't do with other technology.

So, the use cases you care about are worth considering in the use case document(s), but each individual spec is intentionally limited in scope to address it's particular slice of the emergent solution.

[peacekeeper]

I agree with @jandrieu that signing is out of scope here. However the topics Caching and Versioning are probably relevant, when it comes to the question of verifying a signature that was created at a certain point in time. (Keep in mind that the work on DID Resolution is only beginning now, so nothing has been decided yet.)

The did resolution times are already at least 10% of a minute

I'm very surprised by this assertion. Duration of DID resolution will depend on the DID method and many other factors, and probably vary extremely.

[TomCJones]

I based the time on my experience with the currently available one. It gave results from 10 to 17 seconds. Further experience could easily give different results, but until they do I will stick with my current experience. I have no interesting use cases that do not involve signing. I do not expect that to change. YMMV. Peace ..tom

…

________________________________ From: Markus Sabadello <notifications@github.com> Sent: Sunday, February 10, 2019 1:06 PM To: w3c-ccg/did-resolution Cc: tom jones; Author Subject: Re: [w3c-ccg/did-resolution] Signing validation is not defined. (#22) I agree with @jandrieu<https://github.com/jandrieu> that signing is out of scope here. However the topics Caching<https://w3c-ccg.github.io/did-resolution/#caching> and Versioning<https://w3c-ccg.github.io/did-resolution/#versioning> are probably relevant here, when it comes to the question of verifying a signature that was created at a certain point in time. (Keep in mind that the work on DID Resolution is only beginning now, so nothing has been decided yet.) The did resolution times are already at least 10% of a minute I'm very surprised by this assertion. Duration of DID resolution will depend on the DID method and many other factors, and probably vary extremely. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#22 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKxq1rN6KjhtjM_UMhLlsMp4DoH00fX9ks5vMInHgaJpZM4arKcB>.

[peacekeeper]

@TomCJones can you please join the Credentials Community Group, otherwise we can't consider your contributions.

[pchampin]

This was discussed during the did meeting on 17 October 2024.

View the transcript

w3c/did-resolution#22

markus_sabadello: This is about signing a DID Document, feel like it's covered by DID Core... section on signing DID Documents.

markus_sabadello: I asked them for further input through CCG, don't really know what it's asking from DID Resolution.

manu: I don't remember anything about signing. Where is it?
… Found it. There is a note.

https://www.w3.org/TR/did-core/#proving-control-of-a-did-and-or-did-document

manu: I agree with you. I don't know what's expected from Resolution for this.
… A future DID methods WG would look into that.
… Some canadian people are working on multi-factor authentication.
… We need to put something in DID Resolution, but something generic, as this is very method specific.

Wip: I put myself on the queue to respond to something you said, Manu -- some DID Methods might be signing their DID Documents, but it's only for their DID Method resolution processes which require those signatures. DID Resolution could probably only say "if there are signatures you should verify them".

markus_sabadello: Then add a comment to the issue to what we just discussed and leave it open, at some point DID Resolution could do something w/ signed DID Documents.

---

[peacekeeper]

To summarize the discussion on this issue so far, how to verify signatures of VCs or other documents is out of scope here, but we could potentially add a few sentences in DID Resolution about how signed DID documents or other signed data could play a role in specific DID methods.

[w3cbot]

This was discussed during the #did meeting on 15 May 2025.

View the transcript

w3c/did-resolution#22

Signing validation is not defined. #22

wip: the comment from markus is probably valid as a general summary..

markus_sabadello: yes we can still address this to add some comments....

markus_sabadello: this is also related to trust in resolution and how to check if the results from resolvers are valid.....

markus_sabadello: this will require a PR to add some language in the section about architectures or some other place.... this probably also related to Christopher Allens comments ....

---

[w3cbot]

This was discussed during the #did meeting on 31 July 2025.

View the transcript

w3c/did-resolution#22

Wip: Signing validation is not defined... should we address or close the issue?

manu: One thing we could is not to define signing validation for now until we see a firm need in the ecosystem. Not sure if we have a strong need for signed resolution responses, we should allow vendors to create their own solutions and then we can standardize it....

manu: The other approach is to define one way of how signing validation is done, which would require a detailed discussion on how it should be done....

<Wip> w3c/did-resolution#160

Wip: Chair hat off, I like option 1 -- feels like it should be an extension, at moment I don't think any resolvers do signing validation -- validation of series of updates on signatures. There is another issue 160, document the extension, how do resolvers attest to sign resolution responses they provide.

Wip: One thing I'm hearing is this is future work.

Wip: We have talked about it multiple times, we could move on at this point.

manu: One thing we could do is say we define a constrained method for instance data integrity JCS using ECDSA which is supported by most HSMs, and we are using that same mechanism already for did:webvh....

ivan: Maybe what I'm saying is naive, isn't it simpler to say you can create a VC on the data?

manu: yes we could say that, but then it just postpones the problem to later....

manu: We have interoperability problems and there are many different ways to define VCs....

manu: it gets into discussions around the structure and where the data is stored in the VC....

manu: if we want something truly interoperable we should be very specific of how it works...

<Zakim> JoeAndrieu, you wanted to mention about substantive input

manu: we need to be very specific about the structure of the VC and around the signature

<Wip> That is w3c/did-resolution#160 fyi I think

JoeAndrieu: I think we should close this, Manu has some good points, but it's not this issue. I'd like you to create an issue to sign resolution results. This issue isn't what Manu's talking about.

JoeAndrieu: We should close this issue and have Manu restate the issue.

Wip: My read is signing validation of resolution as it goes through process other than what Manu was talking about. How do you verify a resolution result is very DID Method specific, each one does it in a different way.

<ottomorac> +1 yes it is a did method specific issue...

markus_sabadello: I agree with Will and Joe, this issue isn't what Manu was talking about... I also agree with what Manu was talking about, we do talk about it in the section of architecture. The resolution results could be signed, not elaborated, means to do it -- I thought the only thing we may want to do is add a sentence -- DID Methods could use signatures, signed documents, but that's all method specific.

markus_sabadello: That's what I remember from this issue.

markus_sabadello: I think we can close this issue.

---