Add DIDComm v2 messaging support to Gatekeeper

[macterra]

Summary

Evolve the Gatekeeper service into a DIDComm v2 messaging endpoint, formalizing the existing notice system into a standards-based protocol for credential exchange and agent messaging across DID methods.

Motivation

Currently, credential delivery relies on a proprietary notice system that only works between did:cid agents polling the same gatekeeper. External DID methods (did:key, did:web, etc.) cannot receive credentials because there's no interoperable delivery channel. DIDComm v2 solves this with a standard messaging protocol built on DID documents and JWE encryption — both of which we already support.

Architecture advantage

Any gatekeeper can resolve any did:cid — DIDs are stored on IPFS and are not tied to a specific gatekeeper instance. Gatekeepers are stateless with respect to DIDs; they simply follow the IPFS history chain. This means:

• The DIDComm service endpoint in a DID document is a routing preference, not a home binding
• Agents can use any gatekeeper as their DIDComm endpoint
• Agents can switch gatekeepers by updating their DID document (any gatekeeper can publish the update)
• Agents can use a dedicated DIDComm mediator that isn't a gatekeeper at all

This gives us DIDComm portability by default, without the mediator lock-in that plagues other DID methods.

What the Gatekeeper already provides

• DID resolution across methods (did:cid natively, others via universal resolver)
• DID document storage on IPFS (would carry service endpoints)
• Message relay via the notice system (create notice → poll for notices)
• HTTP API for all operations
• JWE encryption (ECDH-ES + A256GCM)

Proposed changes

1. DIDComm service endpoint

Add a /didcomm endpoint to the gatekeeper that accepts DIDComm v2 messages (JWE envelopes) and routes them to recipients based on the to field.

2. DID document service blocks

Include a DIDCommMessaging service entry in did:cid documents pointing at the agent's preferred gatekeeper:

{
  "service": [{
    "id": "#didcomm",
    "type": "DIDCommMessaging",
    "serviceEndpoint": "https://any-gatekeeper.example.com/didcomm"
  }]
}

3. Outbound messaging

Enable agents to send DIDComm messages to external service endpoints discovered from the subject's DID document.

4. Credential exchange protocol

Implement the Issue Credential v3 protocol over DIDComm for standards-based credential delivery, replacing sendCredential's notice mechanism when a service endpoint is available.

Design decisions to resolve

• Key agreement: DIDComm v2 typically uses X25519, we use secp256k1 — support both or negotiate via keyAgreement?
• Migration path: run DIDComm alongside the existing notice system, or replace it?

References

• DIDComm v2 spec
• Issue Credential Protocol 3.0