archetech / archon / 33009809286

92%

main: 87%

push

github

fix(herald): Trust the manifest key only when the credential names it (#949)

* fix(herald): Trust the manifest key only when the credential names it

The revocation lookup resolved whatever DID the manifest was keyed by,
and that key is controller data. A holder could take a revoked
credential -- genuinely issued, correctly signed, still verifying -- and
file it under a fresh active asset, and the lookup would follow them
there and report it live. Only the pointer lied, and the pointer was the
part nobody signed.

#108 fixed that at the source: a credential now names its own asset as
`id`, covered by the issuer's signature. So the two can be compared, and
a disagreement means the entry sits under an asset the issuer never put
it in, whose revocation state says nothing about this credential.

Absence of `id` means unbound rather than invalid. Credentials issued
before that change keep the behaviour they had, best effort, rather than
being marked down for their age -- the same reasoning that stopped
redacted publications being reported as forgeries.

Revocation is also reported ahead of the signature now. A credential that
is both revoked and unreadable is better described as revoked, and the
id survives redaction where the signature does not: publishing without
revealing strips the claim values and leaves the identifier alone. So a
redacted credential, which can never have its signature checked, can
still be reported as revoked.

Completes the follow-up left in #946.

* fix(herald): Check nothing against a credential that has not verified

Review caught the reordering in the previous commit. I moved revocation
ahead of the signature on the grounds that `id` survives redaction, so a
redacted credential could still be reported as revoked. It does survive,
textually, and that is not the same as surviving verifiably.

The proof covers the whole credential except `proof` itself. Until it
verifies, no field is the issuer's word for anything, and a redacted ... (continued)

3881 of 4464 branches covered (86.94%)

Branch coverage included in aggregate %.

2 of 2 new or added lines in 1 file covered. (100.0%)

8527 of 8952 relevant lines covered (95.25%)

717.63 hits per line