You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the 2024-11-21 the topic of the use of "old" keys from early versions of the DIDDoc.
Should the DID Method take a position on their use?
Is anything needed in the spec to enable making access to "old keys" easy in implementations of the resolver?
For example, should a fragment like <did>#key1 deliberately return a key from the not-current version of the DIDDoc, including metadata to indicate that the key is not in the current DIDDoc? What guidance can we get from the DID Core spec to provide useful support? With a mechanism like that, implementers could use key reference fragments in long-lasting verifiable credentials, confident that the signature is verifiable after a key rotation, without having to reissue all of the VCs.
To be discussed at the next Work Item meeting.
The text was updated successfully, but these errors were encountered:
At the 2024-11-21 the topic of the use of "old" keys from early versions of the DIDDoc.
For example, should a fragment like
<did>#key1
deliberately return a key from the not-current version of the DIDDoc, including metadata to indicate that the key is not in the current DIDDoc? What guidance can we get from the DID Core spec to provide useful support? With a mechanism like that, implementers could use key reference fragments in long-lasting verifiable credentials, confident that the signature is verifiable after a key rotation, without having to reissue all of the VCs.To be discussed at the next Work Item meeting.
The text was updated successfully, but these errors were encountered: