-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss how to treat deactivated DIDs #5
Comments
I think it would be better to be explicit between "DID does not exist" and "DID has been revoked". @ChristopherA responded to the above email thread with how BTCR handles this, which highlights the three (really two) revocation scenarios we should describe. I formatted it for clarity.
|
+1 I also agree it makes sense to distinguish between a DID that has been revoked, and one that doesn't exist. (At least if a method supports this, I could also imagine methods where a revoked DID is actually completely deleted everywhere - I think this should also be allowed). As for locating the "latest version", yes I am certain that in a simple "resolve" request, the latest DID document must be returned. That's the meaning of "update" - it updates what the latest version is. So I think a BTCR resolver must follow all the tip transactions to the end in order to locate the latest version. Returning earlier versions of a DID document could be an additional optional feature, if both the DID method and the resolver implementation support it. |
@peacekeeper, regarding:
I think this question deserves a little more discussion. Could allowing this inadvertently create a situation where compromised private keys might be reused? Regarding the versioning issue, if we don't plan on formally requiring a "request version history" on a DID (I don't think we should), we could loosely agree to add it as meta information to the DID Document in the same way. |
Good points, I agree with both. We can have a warning in the spec about security implications of "revoked" vs "deleted", and we could add versioning information to the DID document in a similar way as revocation information. (But resolver implementations should also try as much as possible to protect developers from accidentally using a revoked/outdated DID document). |
there was another discussion on m/l that a DID that was valid on a given date needs to be continue to be valid on that date to allow validation of signature. I feel strongly that a subject should not be permitted to revoke a commitment made (ie a signature) at a earlier date. That capability would invalidate the entire chain, including key rolling and even the revocation itself. That means that requests to the resolver need to allow the request to include the date on which the DID is being queried. In general it would be most useful for the resolver to always included status, which could be (for example) that this DID was revoked on this date. Anyway, that is how i am constructing a resolver. If a method does not support that, i would simply ignore the method. |
Good points, versioning (and the ability to resolve earlier versions of a DID Document) is definitely one of the features that needs to be addressed in the DID Resolution spec. |
I'm concerned about revocation vs. spending for a prescription. A prescription can be coded as a Verifiable Credential and it's subject to revocation and spending. |
@peacekeeper Resurrecting this thread since the DID-Linked Resources use case might signal that this question should be treated in a different fashion than it is currently... Why I think deactivated DIDs should still be resolvableMy view is that a deactivated DID can still be read and should be resolved. It’s up to the client app/API request sender to then decide what to do with this. For example:
Relation to DID Core specificationI’m going with the spirit of what DID Core’s production specification implies:
This does not state a DID production shouldn't be made. If it was the case, this would be entirely unique out of all the other DIDDoc metadata in the effect that it has on production. Also, since it's optional/may be set to Proposed solutionBased on the above, I'd suggest that deactivated DIDDocs should return a resolution response. The change I'd make is to set Resolution metadataCurrent specification
Proposed modification
DIDs may be deactivated with a replacement DID created, or without a replacement DID created. If the DID method supports it (perhaps via the
HTTP Status codeThe current HTTP status code of 410 implies "Gone", so returning an actual response is syntactically weird. I propose that status codes should be:
|
@ankurdotb Thanks for sharing detailed thoughts on this! Personally I don't have a strong opinion here and could live with either approach. I think DID Core supports your arguments, since it says that if the resolution was successful, a didDocument must be returned. At some point in the past, "deactivated" was an error code, but then we changed that, since a deactivated DID isn't really an error, so we just made it another metadata property (see w3c/did-core#691). And you're right that it would be unique as a metadata property if the didDocument was null. It also feels strange to return DID document metadata without returning a DID document :) Having said that, let me present some arguments for the current approach:
Here are two potential ideas for a middle ground:
What do you think? In any case, it feels like we have to clarify more what deactivating a DID actually means. |
I don't really understand what you mean here. According to DID Core, |
Also pinging @fabianekc since he also had some thoughts about DID rotation, forwarding, redirecting. |
I don't mean the DID Document Metadata, which is defined in DID Core specification, but the values returned under DID Resolution Metadata - which as far as I understand is purely in the DID Resolution specification and not in DID Core. For example, the other values mentioned here are
I agree with you that non-ledger VDRs such as
While I do agree that in an ideal scenario either replacements should be created or new as well as legacy kept alive, in reality, I suspect that this will be hard to achieve. Sometimes, companies/entities just straight up go bankrupt and not acquired, or just plain not interested in maintaining "legacy" technology. I would consider verifying a credential linked to a deactivated DID as being interpreted as "It is a cryptographically verifiable fact that this credential is untampered, but it's issued by a defunct entity". E.g., think of a KYC credential issued by Silicon Valley Bank or FTX, utility bill credentials issued by a bankrupt energy provider in the UK etc. More importantly, with paper/plastic credentials issued by defunct entities, or in defunct formats, I can still use them and are considered valid documents. (My birth certificate is on paper filled in with pen, which is no longer a valid format where I was born, but that doesn't make it any less of a "genuine" document although whoever I may show it to could ask me to show other documents stating my birthplace since they don't trust this legacy format as much.) Also, I suspect legacy/un-maintained service endpoints are only truly critical in some DID methods, but perhaps not all. A JWT VC is pretty standalone.
I do agree strongly with you on this point. Logically, I think this is how it should work but I suspect a lot of people wouldn't, and this could become a real issue if this best practice isn't followed.
I really like this idea and I think this is the ideal answer. By asking the requester to explicitly acknowledge and re-send the request a deactivated DID, it's more likely that they'll understand and account for it in their logic. It's like a dialog prompt going "Are you REALLY sure?" before continuing. Also, if an underlying VDR like So maybe the steps could be:
What do you think? |
Yes.
The deactivated state can be due to
In most VDR, DID keys are self-managed, meaning that the keys can be self-suspended or self-revoked. Depending on the use case, deactivation may require to signal
All this is independent of whether the DID R. supports the resolution of historical information or not. Why is the distinction between non-existent and deactivated important? There's a difference between whether a key has been revoked/suspended or does not belong to the DID controller. First signals that a given DID issues the VC, but the DID has been revoked/suspended for some reason, second signals that the VC has not been issued by the DID, which is an attack. |
Glad you agree @alenhorvat! (BTW, everything that follows is me agreeing with you, rather than disputing any of your points.) This is the reason why I think there should be some way of resolving deactivated DIDs vs DIDs that never existed/don't exist, even if it's by using an additional query parameter to make the client app developer 'opt-in' if necessary to make sure they truly understand what they're doing.
The scenarios you've mentioned are excellent examples of intentional DID/key deactivation. I also add the following scenarios for why a DID/key may be in deactivated state, as unintentional or non-recoverable scenarios:
These non-recoverable scenarios, IMO, should not cause a holder to lose the ability to use their credentials entirely. |
See this thread:
https://lists.w3.org/Archives/Public/public-credentials/2018Jun/0078.html
Should DID resolution distinguish between a "DID that does not exist because it has never been created" and a "DID that has been revoked"? What results should be returned in each case by a DID resolver?
The text was updated successfully, but these errors were encountered: