A new issuer against an old verifier reports a broken chain, not a version skew

[stormer78]

0.7.0 and 0.8.0 are both breaking on the wire, and the CHANGELOGs cover them well in one
direction: an old credential reaching a new verifier fails loudly and on purpose —
"an old digest reaching a new verifier fails with InvalidDigest rather than as a silent
mismatch, which is the intended outcome."

The other direction is not covered, and it is the one a mixed deployment actually hits
first.

What it looks like

A 0.7+ attenuate writes authority.parent as a multibase multihash. A 0.6
verify_chain compares that field against the parent's id:

// 0.6
match (&grant.parent, parent.id()) {
    (Some(named), Some(presented)) if named == presented => {}

so it refuses with:

chain link 0 names parent `zQmPvoSXm7pYriaeeE3DRWVybmhYDkMt1UtNrxiRdFfRcrT`,
but was presented after `urn:uuid:064710ef-90ab-4013-9f95-f224af758754`

Both values are printed, and nothing says they are different kinds of identifier. It
reads as a tampered or interleaved chain — which is exactly what BrokenLink means the
rest of the time — so the first hour goes into the chain and none of it into the
dependency graph. That is where it cost me an hour; I only found it by diffing 0.6 and 0.7
side by side.

Why this direction rather than the documented one

Clients upgrade before servers. A browser member picking up the newest crate and talking to
a host built from a workspace that pins an older one is not an unusual deployment, it is
the normal one — and it is how I hit this, building a wasm room member against room-host.

What would have saved it

Either would have:

1. A line in the migration notes saying which end moves first — verifiers before
   issuers, or both together — for 0.7's parent digest and 0.8's presenter rule alike.
2. A hint in BrokenLink when named decodes as a multibase digest and presented
   does not (or vice versa): "these are different kinds of identifier — the credential was
   issued by a newer dtg-credentials than this verifier". Cheap, and it only fires in the
   case that is already an error.

(1) alone is probably enough. (2) helps whoever skips the notes, which is most people
debugging at the point they see this.

The consumer this is about

verifiable-trust-infrastructure pins dtg-credentials = "0.6", so it is now two breaking
releases behind on the library its room authorization rests on. Worth saying because the
upgrade has a correctness payoff rather than just currency: per the 0.8 notes, both
hand-written presenter re-checks go away. vti-rooms-dtg::nomination currently carries

// `verify_chain` uses `claimant` only for the audience check; it does not require the
// grant to name them. Without this a nomination would be a bearer token, and anyone who
// ever observed one could take the room the moment it went dormant.

which is precisely the gap 0.8 closes in the library. Two copies of a check is one place
for it to be forgotten — the changelog says so, and this is the code it is talking about.

Happy to do the VTI-side bump if the ordering guidance lands here first.

[stormer78]

Shipped in #26 (1912c61), for 0.9.1.

The ordering guidance is in the README, in a new Upgrading section: verifiers
before issuers, with a table covering every breaking release so far.

Release	What changed	Ordering
0.7.0	parent became a digestMultibase; digest → digestMultibase	Verifiers first
0.8.0	authority::verify_chain requires the leaf to grant to presenter	Verifiers first
0.9.1	delegation::verify_chain requires the leaf to appoint presenter	Verifiers first

Same answer every time, and for the same reason: each release made a verifier stricter or
changed what it reads, so a verifier that moves first still accepts everything it did
before and is ready for what issuers send next. Your diagnosis of the failure mode is
reproduced there more or less as you wrote it, including the two-values-one-message
problem — it was the clearest part of the report.

On suggestion (2), the BrokenLink hint — not done, deliberately. It cannot help the
case you hit. The confusing message is emitted by the 0.6 verifier, so nothing shipped
in 0.9.1 changes what it prints; a hint added now would only fire in some future skew
where this code is the old end. The direction this crate does control was already correct:
an old credential reaching a new verifier fails with InvalidDigest, which names the
Working Draft 01 sha256:<hex> form explicitly rather than reporting a mismatch. So (1)
is the whole of the fix, which is what you expected.

One thing your report led to that neither suggestion covered. Checking (2) turned up
that AuthorityError::BrokenLink documented both its fields as identifiers — "the id
the link points at", "the id of the credential actually presented" — when both have
carried digests since 0.7.0. That stale wording is plausibly part of why the error reads
as a mismatched chain to whoever goes looking: it prints two values, and the documentation
told you they were ids. Both now say digestMultibase, and the variant points at the
upgrade ordering. DelegationError::BrokenLink documented its fields not at all, and now
matches. Fixed in the same PR.

On the VTI bump. #26 also closed #23, so the upgrade from 0.6 now crosses three
breaking releases: 0.7.0's digest encoding, 0.8.0's VAC presenter rule, and 0.9.1's VDC
presenter rule. Both hand-written presenter re-checks you pointed at should come out —
vti-rooms-dtg::nomination's comment describes precisely what the library now does for
the VAC, and the VDC half is no longer missing either. Note 0.9.1 is a patch version
carrying an API break, chosen because 0.9.0 was hours old with no known consumers; it will
surface as a compile error naming the new parameter, not a silent change.

Thanks for both reports — the ordering question was the right one to ask, and it had no
answer written down anywhere before you asked it.