20 standards
An application asks, a wallet decides, and the person holding the wallet is the one who said yes. Standards here cover how a request is phrased, how consent is remembered, when it expires, and how an autonomous agent is given a budget rather than a blank cheque.
Also searched as consent, allowance, spend policy, authorization, prompt, grant.
A component that implements the logic for a particular permission scheme, evaluating whether a requested action should be allowed. It can be plugged into a system to enforce a specific set of access rules.
Open in the glossary20 standards, spread across 3 of the 12 topics.
Wallets each decide in their own way what an application is allowed to do and how long consent lasts, so the same application behaves differently depending on the wallet. This specifies the whole lifecycle of a permission, without ambiguity.
Filed under Wallet
Permissions is the main subject of these 7.
An application asking the user for one permission at a time, over and over, teaches them to click yes without reading. This lets an application declare everything it needs up front, in one place, so the user makes one informed decision.
If applications are free to use any protocol name they like, a future standard cannot claim one without breaking somebody. This reserves a range of names so later permission schemes have room to exist.
Wallets each decide in their own way what an application is allowed to do and how long consent lasts, so the same application behaves differently depending on the wallet. This specifies the whole lifecycle of a permission, without ambiguity.
Apps that want to show or move collectable items (like NFTs) in a wallet face a bad choice: either dump everything into one basket where any app that gets access sees the user's whole collection, or invent a separate storage bucket for every collection, creator, or app. There was also no clean way to ask a wallet "let me spend this one specific item" without accidentally granting access to spend anything in the collectables basket. This leaves users exposing more than intended, or developers building fragile one-off storage schemes.
A wallet or AI-agent tool server ends up with a long list of callable methods, and once a new method is registered it is simply live, with no signed record of exactly what was turned on and no way for anyone reviewing the build afterward to tell whether the exposed surface quietly grew. This makes it hard to trust that a wallet used by autonomous software, where a rogue or newly-added method could move funds or sign things, has actually been reviewed and locked down rather than just shipped.
A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.
An application asking a wallet for permission gets an error if the person does not answer straight away, which is unfair to anyone who stepped away. This says the request waits for them rather than timing out.
These are about something else, and deal with permissions on the way.
Generating unlimited keys is only safe if software can tell what each one is for and how much the user has agreed to. This defines the naming scheme that separates keys by purpose and sets how much permission each use requires.
If applications and the wallet itself draw keys from the same pool, an application can trample on the wallet's own records. This sets aside a range of names for the wallet's internal use and puts them beyond application reach.
An application keeping things on chain has to track which outputs are its own, and leaving that bookkeeping to the application invites mistakes. This lets the wallet group outputs by application and hand them back on request.
A wallet holding hundreds of transactions with no way to tell them apart is hard to make sense of. This lets an application attach its own labels when a transaction is made, and later list transactions by those labels.
Granting an application access to a group of assets is currently all or nothing. This reserves naming space for future schemes that can be more precise about what an application may touch.
Every wallet historically had its own way of being talked to, so an application had to pick one and be locked to it. This defines a single interface every wallet can implement, so applications work with whichever wallet the user already has.
Labels attached to wallet activity are used both for organising and for deciding what an application may see, which means new labelling ideas cannot be added safely. This reserves label space so they can.
An application that only wants to know how much is in a group has to fetch every item and add them up. This lets it ask for the total directly, using a form older wallets still handle correctly.
Reserving a naming space for future permission schemes is only half the job: somebody still has to decide who gets which name. This sets out how a scheme is registered and who maintains the list.
An AI agent or automated script that holds a wallet's keys can be tricked or malfunction into sending money to the wrong place, and the usual safeguard, a human approving every transaction, defeats the whole point of letting software act on its own. Before this, a wallet could only grant a monthly spending ceiling to an app, which limits how much but says nothing about to whom, how fast, or under what conditions, so a single bad request could still drain the budget to an attacker.
When an app asks a wallet to approve something, the wallet often shows a cryptic code, a raw protocol string, an unfamiliar basket name, or a block of certificate bytes. Users cannot tell what is actually being requested, and there has been no shared, trustworthy place to look up a human-readable name or description for these identifiers. This makes it possible to publish and consult optional, attributed descriptions, without letting those descriptions ever decide whether the underlying operation is allowed.
When an AI agent spends money on your behalf, it usually does so with a password-like credential that can drain whatever account sits behind it, and if something goes wrong you have to notice, log in, and revoke that credential while the agent keeps spending in the meantime. There was no way to hand an autonomous agent a fixed amount of money it could use on its own, anywhere, while guaranteeing the owner could never lose more than that amount and could always take the rest back in a single action.
A web app can only find the Bitcoin wallet running on a user's own computer by poking a handful of local addresses, and newer browsers treat that poke as suspicious and interrupt the user with a security dialog that never mentions the word "wallet". If the user clicks the wrong button, nothing explains what just happened, and the browser locks out that discovery permanently for that site. This leaves developers needing a way to prepare the user before that dialog appears, so a refusal is recoverable instead of final.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic