archetech / archon / 32895986652

87%

push

github

feat(keymaster): Let a credential name the asset that holds it (#948)

* feat(keymaster): Let a credential name the asset that holds it

A credential said nothing about where it lived. The manifest a profile
publishes is a map of asset DID to credential, and only the credential
was signed -- so a holder could take a revoked one, genuinely issued and
still verifying, and write it under a fresh asset DID. Signature, issuer
and subject all check out, because the credential is authentic. Only the
pointer lies, and the pointer was the part nobody signed.

issueCredential now embeds the DID as the credential's `id` and re-signs,
so the binding is the issuer's statement rather than something a later
holder could have added. `id` is a standard optional property of a W3C
Verifiable Credential, so this is not an Archon extension and a foreign
verifier reads it as the credential's identifier.

Two operations rather than one. The DID is the CID of the operation that
creates the asset, so it cannot be known before the asset exists -- but
that is only true of the create operation, and updateDID appends to the
same chain without moving the identifier. The visible consequence is that
a credential now starts at version 2, which one test asserted directly
and now records the reason for.

The DIDComm test carried a comment saying the DID belongs in the message
body and not inside the credential, because an `id` added after signing
would break the proof. That was right about the approach it was warning
against and does not hold for re-signing: the same test still asserts
verifyProof passes on the attachment. The body keeps `credential_did`,
which the issue-credential protocol asks for, and the credential now also
carries its own.

Chosen over comparing the asset's cipher_hash against a hash of the
published copy, which works today and needs no issuance change. That
binding is incidental rather than asserted, depends on JSON.stringify
being byte-stable across a parse roun... (continued)

3876 of 4460 branches covered (86.91%)

Branch coverage included in aggregate %.

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

8525 of 8950 relevant lines covered (95.25%)

717.65 hits per line