Key Rotation

[hkny]

Suppose I am rotating a key due to KMS best practices, how can I reflect those expired keys with the did:web method conform with the method itself as well as did-core spec as mentioned here?

Since we don't have queryable state (or DID history) in did:web method, which kind of additional fields can I use in the verificationMethod to mention that the key is rotated? It might not be very important for a holder (organizational DID) or a verifier but the issue becomes quite crucial in the case of an issuer since the rotated keys should still be resolvable, should a verification of an already issued credential with the rotated key occurs.

Thanks in advance.

[mschmidt-ffstudios]

Is there any life in providing feedback to this issue?

[peacekeeper]

In my opinion, expired/rotated keys should simply not appear in the DID document at all. This is an inherent drawback of the did:web method.

One thing that could potentially be done is extend the did:web method to support history (versionId and versionTime parameters), for example by keeping older versions of the DID document on the web server that can somehow be queried. As far as I know this has been discussed before.

[mschmidt-ffstudios]

But if they should not be in the DID-Document then as an Issuer you have to reissue valid Credential only because you have switched, this would be an drawback in every DID-Method not only did:web.

So they should be in there somehow, for at least a given time period until every issued Credential is expired, if we say we have a reference to some older version, every validation algorithm has to implement the logic and for example if there is an key not found in v5, it would compute all other version also to find out that the key is in version 1 used which is also a performance/energy issue, or do I miss something?

[dlongley]

The DID spec expects key rotation (without revocation) to be a private / confidential activity and the DID document expresses public key material (via verification methods).

To rotate keys, stop using the secret (aka private) key material in new signatures / proofs and, potentially (if appropriate), destroy the secret (aka private) key material. Do not remove the associated verification methods and public key material from the DID document. Generate new key(s) and add their associated verification methods to the DID document. Any signatures / proofs that have already been created will continue to be verifiable, but no new ones using the rotated keys will be generated; this does not impact verifiers in any way.

Key revocation is a different story and the expectation is that the keys will be removed from the DID document. Backing DID ledgers that support historical lookups would allow sufficiently intelligent verifiers to perform audits on previously verified data on keys that used to be valid in the past. A future change to the DID web method specification could add something to enable this sort of historical look up, but it isn't supported (directly via the spec) today. Implementations could keep their own previously trusted and audited lists, but there would be no wide interop for that approach.

[mschmidt-ffstudios]

Wouldn't it be just enough if there is a must field in the authentication/verification method - 'expirationDate | validUntil' which describes the expiration date of a Key, the worst case scenario:
Rotating 10 keys of a DID-Document every month over 100 years would be -

12Months * 10Keys * 100years = 12k entries

which is faster to loop in a indexed list then fetching new historic documents from other resources.

Key Revocation is in my opinion for DID:Web not that interesting, just delete the key or use an expiration date and set it before today or just do an lookup about issued credentials and revoce them manually, so no direct use of Key-Revocation if a DID-Document is not as persistent as it is on a ledger/chain but even there it could just be updated.

[hkny]

We have thought about similar approaches to do so.

Appending the verification method with new keys when a key rotation occurs seems to be a feasible approach and still conform with the current spec.

@dlongley However, with the current spec, in order to have key revocation according to your suggestion, it would mean to deviate from the spec and the universal resolver / standard did:web resolver could not fetch historical state of the DID document.

Maybe we could think of adding two more attributes to the keys in verification method: Status = "Active/Inactive(Rotated)/Revoked" and something like StatusDate that gives a datetime regarding since when the status is in that state. This wouldn't cause any issues with the current resolver, since we would get all the information from the */did.json and the logic of validating the VC according to the information in the DID document would belong to the verification application.

I think this is something that implementors can add while being conform with the spec (correct me if I am wrong). Would you consider also adding these to the spec as optional parameters? Also another question to consider: Would such approach break the conformity with JWS2020 Spec?