DID Document – Handling Multiple Public Keys & VC Verification

Hi everyone,

While debugging Certify service with DID documents, we noticed the following behavior:

  1. Starting the Certify service, generating did.json, and issuing a VC works as expected — the VC verifies successfully.

  2. If we truncate the key_alias table, restart the service, and generate a new did.json, the public key changes. With this new DID, newly issued VCs verify correctly, but older ones fail verification.

  3. If we only restart the service (without truncating the table), the public key remains the same, and both existing and new VCs verify successfully.

We also tried including multiple public keys in did.json (example below), but in this case only VCs signed with the first key are verified — the verifier seems to ignore subsequent keys.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:shubhm-m.github.io:certify:local",
  "verificationMethod": [
    {
      "id": "did:web:shubhm-m.github.io:certify:local#key-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:shubhm-m.github.io:certify:local",
      "publicKeyMultibase": "z6Mks2s729nhPsKVCgcX8YrMfhN2X2xQRnqHV5EQUUzS7sR8",
      "@context": "https://w3id.org/security/suites/ed25519-2020/v1"
    },
    {
      "id": "did:web:shubhm-m.github.io:certify:local#key-3",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:shubhm-m.github.io:certify:local",
      "publicKeyMultibase": "z6Mkrrtw1bw5vaNXjZw3bsfMMt4VECHP3VqT6SkUxTJyN3en",
      "@context": "https://w3id.org/security/suites/ed25519-2020/v1"
    }
  ],
  "assertionMethod": [
    "did:web:shubhm-m.github.io:certify:local#key-2",
    "did:web:shubhm-m.github.io:certify:local#key-3"
  ],
  "authentication": [
    "did:web:shubhm-m.github.io:certify:local#key-2",
    "did:web:shubhm-m.github.io:certify:local#key-3"
  ],
  "service": [],
  "alsoKnownAs": []
}

:backhand_index_pointing_right: Use case: We are exploring key rotation while ensuring backward compatibility so that older VCs can still be verified after new keys are introduced.

Is this the expected behavior, or is there a recommended approach/best practice for managing multiple public keys and supporting verification of older VCs after key rotation?

Hi @Shubham6818 ,

Thank you for reaching out to us.

Team is checking on your query. will revert back to you as soon as possible

Rregards,

Varaniya S
Team MOSIP

Hello @Shubham6818

We are currently looking into this and would request you to allow us some more time to complete the necessary checks. We will share an update shortly.

Thank you for your patience and understanding.

Regards,

Likhitha R L

Team MOSIP

Hi @Shubham6818

From the description you shared, we understand that you are making changes in the key alias table and restarting the service. As a result, the old data gets removed by default, which means previously issued VCs will no longer be supported since the old did.json is removed and replaced with a new one.

To better assist you, could you please share more details about the use case that requires changes in the key alias table? Understanding the problem statement in detail will help us provide more relevant guidance or suggestions

Regards,

Varaniya S

On behalf of Team MOSIP

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.