archetech / archon / 32887966504

87%

push

github

fix(herald): Verify published credentials before showing them (#946)

* fix(herald): Verify published credentials before showing them

The public profile rendered every entry of didDocumentData.manifest under
a "Credentials" heading without checking any of them. A manifest holds
whatever its subject published there: publishCredential checks the shape
and that the caller is the subject, never the proof, and a controller can
write didDocumentData directly regardless. So a self-asserted object
naming any issuer looked exactly like a credential that issuer had
signed, to a reader with no other way to tell.

Comparing the issuer against the signer is the part that matters.
verifyProof validates a signature against whoever the proof names, which
is not necessarily whoever the credential claims issued it. A credential
saying issuer: did:cid:bank, signed with the subject's own key, verifies
happily -- so checking only the signature would have laundered the
forgery rather than caught it, and put a green tick on it.

Revocation is reported separately because the manifest keeps its own copy
of the credential; revoking the asset leaves that copy looking healthy.

Invalid and unverifiable are also kept apart. A credential whose
signature or issuer does not check out has been examined and failed, and
"Invalid" is what a reader needs to see. One whose issuer cannot be
resolved has not been examined at all, and saying so is honest where
calling it invalid would not be. Failing entries are marked rather than
dropped: hiding them tells the reader nothing and leaves the subject
unaware that something in their manifest does not check out.

Verified on the server, which already holds the keymaster and the
gatekeeper access this needs; the client carries neither. The result is
returned as a sibling of the resolved document rather than a field inside
it, since annotating a DID document with members of our own is the
conformance fault #676 removed.

KeymasterClient had no ve... (continued)

3875 of 4459 branches covered (86.9%)

Branch coverage included in aggregate %.

41 of 42 new or added lines in 2 files covered. (97.62%)

8525 of 8950 relevant lines covered (95.25%)

685.03 hits per line