feat(did-webvh): backdate + space the VTA's webvh versionTime - #600
Merged
Conversation
The VTA creates its did:webvh at setup and updates it moments later (e.g.
'services didcomm enable'). versionTime serialises at second granularity and must
be strictly increasing and not in the future, so two entries minted in the same
second serialise identically and make the DID unresolvable — surfacing as a
resolution failure ("versionTime must be greater than previous") only once a
client fetches did.jsonl.
Set an explicit versionTime on the genesis-create and standard-update log
entries: backdated a day and spaced a minute apart by entry index
(backdated_version_time). The wall-clock value is irrelevant to did:webvh; this
keeps the log strictly increasing and in the past regardless of how fast the
entries are minted. Requires didwebvh-rs 0.5.6, which exposes version_time on
CreateDIDConfig/UpdateDIDConfig (decentralized-identity/didwebvh-rs#48).
Validated end-to-end: a fresh VTA set up and didcomm-enabled back-to-back with no
delay now resolves and completes a containerised did:peer agent round-trip.
Signed-off-by: Glenn Gore <glenn@affinidi.com>
stormer78
added a commit
that referenced
this pull request
Jul 2, 2026
…on (#600) (#605) The VTA creates its did:webvh at `vta setup` and updates it moments later (e.g. `services didcomm enable` patching in the DIDComm mediator service). did:webvh serialises versionTime at second granularity and requires each entry to be strictly later than the previous, so two entries minted in the same wall-clock second serialise identically and the DID resolves back to the genesis (REST-only) entry — the operator sees `services didcomm enable` report success and write config.toml, yet the published DID document still advertises REST only at version 1. PR #600 fixed this by backdating + index-spacing versionTime on the genesis-create and standard-update entries (`backdated_version_time`), but shipped with only manual end-to-end validation. This adds automated guards: - A did_webvh e2e test driving create -> didcomm-enable *back-to-back with no sleep* (every other e2e test dodges the bug by sleeping past the second boundary), asserting the chain still validates and advertises DIDCommMessaging at version 2. Neutering `backdated_version_time` makes it fail with the exact didwebvh-rs error ("Current versionTime must be greater than previous versionTime ... Log truncated at 2-..."). - A unit test pinning `backdated_version_time`'s contract: timestamps are in the past and strictly increasing by entry index at second precision. Reuses the shared `with_didcomm_service` patcher rather than hand-rolling a service-array edit. Bumps vta-service 0.10.18 -> 0.10.19. Claude-Session: https://claude.ai/code/session_01HoRff8BDqXuSfQ7RNjm3ic Signed-off-by: Glenn Gore <glenn@affinidi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Sets an explicit, backdated, index-spaced
versionTimeon the VTA'sdid:webvhlog entries (genesis create + standard update), instead of letting the library default each tonow().Why
The VTA mints its
did:webvhatsetupand updates it moments later (e.g.services didcomm enable, or any service-management change).versionTimeserialises at second granularity and must be strictly increasing and not in the future, so two entries minted in the same second serialise identically and make the DID unresolvable. It bites late and confusingly — the entries look fine in memory, then a client fetchingdid.jsonlfails with"versionTime must be greater than previous".backdated_version_time(entry_index)returnsnow − 1 day + index·1 min. The wall-clock value is irrelevant to did:webvh (it's just a monotonic ordering marker), so backdating keeps the chain strictly increasing and in the past no matter how fast entries are minted — a day of headroom at one-minute spacing. Applied to the single-entry operations (genesis create, standard update). The multi-entry deactivation path keeps per-entrynow()(a single value can't space its two entries).Dependency
Requires
didwebvh-rs0.5.6, which exposesversion_timeonCreateDIDConfig/UpdateDIDConfig(decentralized-identity/didwebvh-rs#48). Bumped here + lockfile refreshed.Validation
A fresh VTA
setup+services didcomm enableback-to-back with no delay now resolves cleanly and completes a containeriseddid:peeragent → live-VTA round-trip (previously this required an artificial ≥1s pause between the two commands).did_webvhtest suite green (73 + 24 + 1), fmt/clippy clean.