fix(core): resolve interop failures from did:webvh test suite (issue #2)

[IVIR3zaM]

Summary

Addresses all failures reported in issue #2 ("Problems uncovered by the
did:webvh test suite") against swcurran/didwebvh-test-suite@c11fda3.

Five root-cause categories were investigated; three were genuine bugs, two
were symptoms of the first fix.

---

Fixes

1 — NPE and canonicalization mismatch on witness: {} (Python/TS logs)

Python and TS implementations always serialise an empty "witness": {} object
when no witnesses are configured. Two interop bugs followed:

• NPE on resolve: Gson instantiated WitnessConfig via
  Unsafe.allocateInstance, bypassing the constructor and leaving the
  internal witnesses list null. The first call to isActive() or
  getWitnesses() threw NPE on every Python/TS log.
• SCID, entry hash, and proof verification failed: Java re-serialised
  WitnessConfig as {"threshold":0,"witnesses":[]} instead of {},
  producing a different JCS canonical form used to compute and verify hashes.

Fix: added a no-arg constructor to WitnessConfig (so Gson uses
Constructor.newInstance instead of Unsafe) and a WitnessConfigTypeAdapter
that round-trips the empty-object form.

This also cleared two items in the issue table that were symptoms of this bug:

• nextKeyHashes: [] XFAIL (TS logs): the TS logs validate end-to-end
  once canonicalization is correct; the existing create-side check already
  accepts empty arrays.
• versionTime must be after previous entry failures (java-eecc logs):
  chain validation was aborting at the NPE before reaching the versionTime
  check. All six java-eecc vectors now validate; the spec (§535–536) mandates
  strict > and the existing check is correct.

2 — Pre-rotation entries authorized against wrong key set

Spec §3.7.5 defines two modes for the "active updateKeys" that must authorize
each log entry:

• No pre-rotation: active = previous entry's updateKeys
• Pre-rotation active: active = the current entry's own updateKeys

LogChainValidator unconditionally used the previous entry's keys for i > 0,
causing "signing key not in active updateKeys at entry 2" against every
pre-rotation-consume log (rust and java-eecc). DeactivateDidOperation made
the same mistake when emitting its intermediate pre-rotation-consuming entry.

Fix: branch on whether the previous entry's nextKeyHashes is non-empty;
if so, authorize against the current entry's updateKeys. Update
DeactivateDidOperation to sign the intermediate entry with
nextRotationSigner. Regenerated pre-rotation-log.jsonl under correct rules.

3 — Witness proof pruning and bare-multikey witness ids (Rust logs)

Spec §3.7.8 states that a valid witness proof at versionId V implicitly
approves all prior log entries, and the DID Controller SHOULD prune
did-witness.json to retain only the latest proof per witness.

WitnessValidator required an exact-versionId proof per log entry and failed
with "missing witness proof" when the file was pruned. It also compared
authorized witness ids as did:key:<multikey> against the Rust
implementation's bare-multikey form, yielding 0 authorized proofs.

Fix: rewrite WitnessValidator to pre-verify all published proofs once,
then for each witnessed entry count distinct authorized witnesses whose verified
proof targets a versionId at or after the entry's version number. Match witness
ids by multikey portion to accept both did:key:z6Mk… and bare z6Mk… forms.

---

Test coverage

Interop vectors vendored from swcurran/didwebvh-test-suite@c11fda3 into
didwebvh-core/src/test/resources/interop/
(see README.md there for the full table). New JUnit test classes:

Test class	Vectors
InteropEmptyWitnessObjectTest	basic-create/python
InteropTsBasicUpdateTest	basic-update/ts
InteropJavaEeccLogsTest	basic-update, deactivate, key-rotation, multi-update, services, witness-update (java-eecc)
InteropPreRotationConsumeTest	pre-rotation-consume/rust, /java-eecc
InteropRustWitnessProofsTest	witness-update/rust, witness-threshold/rust

Full repo mvn verify: all tests pass.

---

Closes #2

[swcurran]

Ran the https://github.com/decentralized-identity/didwebvh-test-suite against the new branch and the fixes are working. Remember that the code in the test suite is all AI generated, so you might want to consider them.

We did add some negative tests and some of those are failing -- but seem to work with the existing library. ¯_(ツ)_/¯

Negative scenario	Expected error	Old library (0.2.0)	PR branch (fix/interop-test-suite-issues)
negative-cross-did-witness-replay	invalidDid	✅ PASS	❌ FAIL (resolver accepted invalid log)
negative-portable-scid-swap	invalidDid	✅ PASS	❌ FAIL (resolver accepted invalid log)
negative-pre-rotation-omit-updatekeys	invalidParameters	✅ PASS	❌ FAIL (resolver accepted invalid log)

I'll approve this and you can merge this or take a look at these failures as well.

The merge-base changed after approval.

[IVIR3zaM]

Thanks @swcurran , I made the changes to fix the issues.

[swcurran]

Nice - I'll review, approve and merge. Thanks!! Nce work.

[swcurran]

Ran again and things look even better. Again, I'll approve, but leave to you to tell me to merge or deal with two more things -- one of which is pretty important and I didn't mention last time.

1. One remaining negative test is not passing -- negative-cross-did-witness-replay
2. The library is not adding the implicit "/whois" and "/files" services into the resolved DIDs. This should always be done unless the services are already present in the resolved DID. So the "diff.txt" is showing that these are missing in all resolution tests. See below. As I recall, this was working before the move to DIF, so it's just something simple.

=== basic-create / python — resolutionResult.json ===
--- expected
+++ actual (java resolver)
     "controller": "did:webvh:QmXhVjFG6EBTosDastaaHMRypm2qSv4SMGctADsx878Yux:example.com",
     "id": "did:webvh:QmXhVjFG6EBTosDastaaHMRypm2qSv4SMGctADsx878Yux:example.com",
     "keyAgreement": [],
-    "service": [
-      {
-        "id": "did:webvh:QmXhVjFG6EBTosDastaaHMRypm2qSv4SMGctADsx878Yux:example.com#files",
-        "serviceEndpoint": "https://example.com/",
-        "type": "relativeRef"
-      },
-      {
-        "@context": "https://identity.foundation/linked-vp/contexts/v1",
-        "id": "did:webvh:QmXhVjFG6EBTosDastaaHMRypm2qSv4SMGctADsx878Yux:example.com#whois",
-        "serviceEndpoint": "https://example.com/whois.vp",
-        "type": "LinkedVerifiablePresentation"
-      }
-    ],
     "verificationMethod": [
       {
         "id": "did:webvh:QmXhVjFG6EBTosDastaaHMRypm2qSv4SMGctADsx878Yux:example.com#P5RDjVJG",
...
     "versionId": "1-QmWFwGhwjwRBMcQRzHHSQwpebk7iQ8CKd8rihrzbU1BGRt",
     "versionNumber": 1,
     "versionTime": "2000-01-01T00:00:00Z"
+  },
+  "didResolutionMetadata": {
+    "contentType": "application/did+ld+json"
   }
 }

[IVIR3zaM]

Hey @swcurran,

Thanks for checking it and detailed comments. I fixed both issues and made sure no change to the previous test suites.
Also I made it now ready for the v0.3.0. However still I am waiting for the GPG issue to be resolved, then I would release both versions

[swcurran]

LGTM -- all negative tests now passing, and the implicit services are in the resolution results.