Lonnie VanZandt (@lonniev) on X

What it is

Secure Courier is a consent flow in Tollbooth DPYC, a monetization network for paid MCP services. It lets an AI agent act for a Nostr npub (public key) at an MCP service without holding the user's nsec (private key). Lonnie VanZandt's thread, posted by the Excalibur-MCP service, presents it as an alternative to central identity providers and to CIBA (Client-Initiated Backchannel Authentication). Tollbooth DPYC is open source under Apache 2.0, and the thread notes a patent is pending (US Prov. App. No. 64/045,999).

How it works

1. The agent asks an MCP service to act for an npub. The service has never heard from that user, so it sends a direct message asking for approval.
2. The service signs the request with its own Nostr key pair, which is listed under its name in the Tollbooth DPYC community registry. The user can check the request really comes from that service.
3. The message is sealed so only the user can open it. Public Nostr relays carry it to the user's Nostr app and cannot read it.
4. The user sees who is asking and why, replies, and sets how long the permission lasts. The app signs the reply with the nsec.
5. The service verifies the signature and issues its own grant.

The grant stays inside the service. It is stored encrypted in a wallet behind the agent's connection, bound to the npub, and expires on the chosen day or when the user revokes it. It records the user's signature, so consent can be checked and does not rest on the service's word.

The agent's connection uses ordinary OAuth plumbing, with no login page and no consent screen. The connection proves nothing about the user until the reply arrives. A code word in the request identifies which reply belongs to it and never unlocks anything.

Preconditions

• The user needs a Nostr app that holds the nsec and can receive and sign direct messages.
• Each service needs a key pair published in the Tollbooth DPYC registry.
• The agent must know the user's npub.

Caveats

The thread argues that a breached service exposes only the grants it issued, until they expire or are revoked. It also says there are no passwords to crack and that the nsec cannot be used elsewhere. These are the author's design claims, and the thread gives no audit or test results. It says CIBA depends on one central authorization server that holds accounts, relays requests and mints tokens. It does not say how revocation is delivered or how the registry is secured. The full technical write-up is linked on cafe.tollbooth-dpyc.com but was not part of the fetched text.