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 @jandrieuhttps://github.com/jandrieu that signing is out of scope here. However the topics Cachinghttps://w3c-ccg.github.io/did-resolution/#caching and Versioninghttps://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 GitHubhttps://github.com/w3c-ccg/did-resolution/issues/22#issuecomment-462172619, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKxq1rN6KjhtjM_UMhLlsMp4DoH00fX9ks5vMInHgaJpZM4arKcB.

[peacekeeper]

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