archetech / archon / 32545848637

87%

push

github

feat(didcomm): Credential exchange over DIDComm (issue-credential 3.0) (#919)

* feat(didcomm): Credential exchange over DIDComm (issue-credential 3.0)

Sends a verifiable credential to any DIDComm agent, and accepts one on
the receiving side.

The wire format is forced by the use case -- a VC to a non-Archon DID.
`issueCredential` encrypts to the ISSUER when the subject is not a
`did:cid`, and `sendCredential` returns null for such subjects, so there
is no delivery path to a foreign DID today. The attachment therefore
carries the signed credential itself rather than a credential DID that
only this network can resolve, plus `id: <credentialDid>` -- a W3C VC
property, and a DID is a URI. A foreign agent reads the credential; an
Archon holder still has the DID to `acceptCredential`.

Present-proof 3.0 is deliberately out of scope: it overlaps Archon's
existing challenge/response presentation flow, and whether DIDComm
replaces or supplements that is a separate question this use case does
not settle.

Parity across every surface: library, KeymasterInterface, KeymasterClient,
REST + Swagger, all three CLIs, MCP tools, Python core and SDK. The
wallets get a Send button on issued credentials, and the DIDComm inbox
names a credential, shows what it asserts instead of raw JSON, and offers
Accept.

Closes #905

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(didcomm): Send the credential exactly as signed, and check what arrives

Review caught a real defect: `id` was added to the VC when building the
message, and `verifyProof` hashes every field except `proof`. So the
credential this PR exists to deliver did not verify -- for precisely the
foreign recipient it was meant to reach.

The credential DID now rides in the message body as `credential_did` and
the attachment travels byte-for-byte as issued. The test asserted only
that a proof was PRESENT, which passed happily while the credential was
unverifiable; it now verifies it, and fails... (continued)

3806 of 4293 branches covered (88.66%)

Branch coverage included in aggregate %.

28 of 37 new or added lines in 4 files covered. (75.68%)

8465 of 8776 relevant lines covered (96.46%)

689.48 hits per line