JWE envelopes: authcrypt vs anoncrypt
DIDComm v2 encrypts messages as JWE, JSON Web Encryption, the same JOSE family as JWT and JWS. Within that there are two modes, and choosing between them is a real decision that most integrations make by accident, by inheriting a library default.
anoncrypt, encrypted to someone, from nobody
The message is encrypted to the recipient's public key. Anyone can produce one, because encrypting to a public key requires no secret of your own.
The recipient learns: someone sent this, and only I can read it. Not who.
Use it when the sender should be anonymous to the recipient, or when identity is established inside the message rather than by the envelope.
authcrypt, encrypted to someone, from a known key
The message is encrypted so that the recipient can also verify which sender key produced it, using authenticated key agreement between the two DIDs.
The recipient learns: this came from that DID, and nobody tampered with it.
Use it when the recipient must act on who sent the message, which, for most agent-to-agent protocols, is always. A credential presentation from an unauthenticated sender is usually meaningless.
The distinction people get wrong
Authcrypt authenticates the sender to the recipient. It does not hide the sender from the network, and, crucially, neither mode changes what a mediator observes about routing.
The outer forward envelope exists so a mediator can route without reading the inner message. That
outer layer necessarily carries a destination, and the connection carrying it necessarily has an
origin. So:
- anoncrypt means the recipient does not learn the sender's DID from the envelope.
- It does not mean the mediator, or a network observer, learns nothing about where traffic came from.
Conflating "the recipient cannot identify me" with "nobody can correlate me" is the most common privacy error in this area. The full enumeration of what routing itself reveals is what a mediator can and cannot see, read that before choosing a mode for privacy reasons.
Nesting, and why the mediator sees only the outside
A mediated message is two envelopes deep:
| Layer | Encrypted for | Mode | Who opens it |
|---|---|---|---|
Outer forward |
the mediator | typically anoncrypt | the mediator, reads a destination only |
| Inner message | the recipient | your choice | the recipient only |
The mediator holds no key that opens the inner envelope. That is structural, not a policy, see the forward message and routing keys.
Practical guidance
- Know which mode your library defaults to. Do not assume; check. This is one line of verification that prevents a whole class of wrong assumption.
- Use authcrypt for anything acted upon, instructions, presentations, state changes.
- Use anoncrypt deliberately, not accidentally, and only where sender anonymity is a genuine requirement rather than a vague preference.
- Do not use anoncrypt as a substitute for pairwise identifiers. Distinct keys per correspondent do far more against correlation than hiding the sender from one recipient does. See pairwise DID.
What Solidus Relay does with either
Routes it. The mediator processes the outer envelope and never the inner one, so your choice of mode is entirely between you and your correspondent, we neither require nor observe it.
Solidus Relay implements Coordinate Mediation 2.0 and Pickup 3.0 over DIDComm v2. No independent conformance suite has been run, so "implements" is the claim and "conformant" is not. Use a DIDComm v2 library for the JWE work, hand-rolled key agreement is where this fails silently.