Signed authorization and the permit pattern

Sometimes you need to let someone else act for you on a system you cannot reach right now. You may have no account there, no open session, or no way to pay for the action at the moment it has to happen. Your consent does not require your presence. It can be a message you sign offline, at no cost, that anyone can carry to the system and present alongside the action it permits.

You want a print shop to fetch one photo from your private cloud storage and print it. Normally you would sign in to the storage provider and grant the shop access from inside your account. But the shop's kiosk has no way to open your account, and you are not standing there to log in for it. The permission is yours to give. The one place it has to take effect, your storage account, is a place you cannot act from at the moment the shop needs it.

The move is to separate the consent from the act of using it. You do not have to be the one who performs the action on the target system. What the system needs is proof that you agreed, and that proof can be a message you sign with your private key. The signature is something only you could produce, and anyone can check it against your public key.

So you sign the authorization offline, at no cost, and hand the signed message to whoever will act. That party carries it to the target system and presents it together with the action it permits. The system verifies the signature and, in one step, treats the action as authorized and carries it out. You were never online at that moment. Your agreement arrived ahead of you, inside a message.

Go back to the photo. Instead of granting the shop access to your whole account, you generate a pre-signed URL for that one image, a link to the single object with a signature attached, valid for a limited time. File storage services such as Amazon S3 provide this directly. You hand the link to the shop. The kiosk opens it, and the signature carried in the link is what the storage service checks before releasing the image. The shop never needed an account, and you never needed to be online when the kiosk fetched the file. The authorization was made in advance and traveled inside the URL.

An everyday version, offered only to fix the shape in mind, is a signed cheque. You write it and sign it at home. The person you give it to presents it at the bank days later. The bank does not need you standing there. It verifies your signature on the paper, and that signature is what authorizes the payment. The signer and the moment of use are in different places and different times, joined only by the signed instrument.

A signature by itself only proves who signed. It says nothing about what they meant to allow, and a signature attached to too little can be presented in situations the signer never had in mind. A sound signed authorization binds four things and guards against a fifth problem:

• Who is authorized. The specific party allowed to act, so a message meant for one cannot be used by another.
• What exactly is authorized. The precise action and its limits, so a permission to do one small thing cannot be stretched into a larger one.
• On which system. The exact target, so an authorization for one system cannot be presented on a different one that happens to read the same format.
• Until when. An expiry, so a grant does not stay live forever waiting to be misused.
• Not more than once. A guard against replay, usually a one-time value, so the same signed message cannot be presented again to repeat the action.

Leave one of these out and the gap is concrete. With no expiry, an old authorization still works years later. With no target named, a signature meant for a test system can be replayed against the real one. With no replay guard, a single approval can be spent again and again.

When you build or use a signed authorization, treat the signature as the easy part. The work is in what it commits to. Before you sign, make sure the message names who may act, the exact action, the system it is for, and the time it stops being valid. Make sure it can also be used only once. A signature over all of that is a permission you can hand to a stranger and let them carry across time, without it turning into a permission you never meant to give.

Skip this section if you only want the principle. On many blockchains, letting another party spend your tokens through the standard ERC-20 approval flow takes two transactions: one approve call to grant the allowance, then a transferFrom that spends it. The first has to be sent by the token holder, and sending it requires already holding the chain's native currency to pay for the transaction. EIP-2612, the permit extension, applies signed authorization to remove that burden. The holder signs an approval message offline, and anyone can submit it together with the spend in a single transaction.

EIP-712 gives that message its binding structure, so the approval is human-readable and tied to a specific token contract and chain. That covers the who, what, and where from the list above. Only a token that implements EIP-2612 supports this flow, because the token contract itself has to verify the signature. ERC8009's permit router, examined in depth in the clear signing module, builds on this same mechanism.