Two Parties Who Have Never Met Need a Way to Talk, and Email Is Not It

The transport described here runs as a hosted service and is not installable as a package, which the section on where we stand covers.

The problem that appears the moment credentials move

An issuer needs to send a credential to a holder. A verifier needs to send a request. A holder needs to respond, later, from a device that was offline when the request arrived.

None of those parties necessarily has an account with the others, which rules out the usual answer of putting everyone on one platform.

So you need messaging between parties whose only shared context is an identifier, where the message is encrypted to a key rather than to an inbox, and where being offline is normal rather than an error.

Why the obvious substitutes fail

Email and webhooks assume a stable endpoint. A person's phone is not one. Anything requiring the recipient to be reachable at a fixed address pushes identity back toward accounts on somebody's server.

Push notifications belong to two platform vendors, terminate there, and are a wake-up signal rather than a transport for authenticated messages.

And a plain API assumes a prior relationship. Somebody issued a key, somebody registered, and that registration is exactly the thing a portable credential is trying to avoid needing.

What is left is a message protocol keyed to identifiers rather than to addresses, with a mailbox somebody holds for you while you are offline.

The uncomfortable part of that design

Whoever holds the mailbox sees the metadata.

They cannot read the message bodies, which are encrypted end to end. They can see who connects, when, how often, the size of what passes through, and the timing. Over months that is an activity picture about a person, assembled by an intermediary.

This is inherent rather than an implementation flaw. A mailbox that could not tell which mailbox a message was for could not deliver it. Anyone claiming a mediated transport with no metadata exposure has not thought about it or is not saying.

Why that last gap is the one to weigh

Because a transport you cannot self-host is an availability and a privacy dependency at the same time.

If we are unreachable, mediated delivery stops. If we are careless, the metadata is ours to be careless with. Neither is fixed by the protocol being open, and both are fixed by somebody other than us running a mediator, which needs the package that does not exist yet.

What to ask any project offering agent or wallet messaging

"Can I run my own mediator, today, from a published package?" For us the answer is no, and that is the honest state.

"What does the mediator see?" The correct answer is metadata, specifically enumerated. A vendor answering "nothing, it is encrypted" has conflated content with traffic.

"Is it the standard protocol or a variant?" A proprietary variant with standard vocabulary is a lock-in with a friendly name.

"What happens when the mediator is down?" Store-and-forward has a failure mode and it should be described rather than discovered.

Where this leaves a decision

If you need messaging infrastructure you can operate yourself, we do not offer that today because the package is unpublished, and that is a shipping gap rather than a design one.