21 standards
How one party proves who they are to another without a username or a password. Identity here is a public key the holder can prove control of, plus optional certificates that say something about them.
Also searched as identity key, DID, decentralized identifier, handle, authentication.
The master public key that identifies a wallet, and by extension its user. It is safe to share, and other standards derive per-purpose keys from it rather than using it directly.
Open in the glossary21 standards, spread across 6 of the 12 topics.
Reaching someone online means knowing which service they are on, which stops being true the moment they move. This gives each person a readable handle that resolves wherever they actually are.
Filed under Peer to peer
Identity is the main subject of these 8.
Proving who you are online generally means trusting a company to vouch for you. This explores building identity from family records instead, tying genealogical documents to keys so the claim rests on evidence rather than an authority.
Reaching someone online means knowing which service they are on, which stops being true the moment they move. This gives each person a readable handle that resolves wherever they actually are.
A BSV wallet normally logs into every website using the same permanent public key. That means any two sites that compare notes can tell their visitor is the same person, and the user has no way to stop it or start fresh. This makes it hard to build sites where users want separate, unlinkable accounts, like a different presence on each service.
Apps that want to know who a user is usually force them into yet another signup, hand their identity to a central provider, or trust whatever name a person types into a form. There was no good way for a person to prove a single cryptographic identity across many apps, selectively reveal only the attributes they choose, and let each app apply the trust decisions the user has actually made. This makes it possible for an app to recognize a person by their key, pull up attributes they published, and ask them directly for more proof, all without building an account system or an identity bureau.
Right now, proving who you are online usually means handing over a company's whole account system, your transaction history, or a permanent public record just to buy something or prove a right. If your phone breaks or your provider goes bad, you can lose both your money and years of accumulated app data and relationships, with no clear way to get them back or take them elsewhere.
If an app wants to treat a user's public key as a standard identity identifier that other DID-aware tools understand, there's no agreed way to turn that key into such an identifier without inventing something ad hoc or pulling in a name, serial number, or external registry that doesn't actually represent the key itself. This leaves apps unable to plug a BSV identity key into generic decentralized-identity tooling, or tempted to fake metadata that isn't really known.
A wallet that wants to pay someone usually has just a long string of random-looking characters, a public key, with no way to know if it really belongs to the person named by an email-like address such as alice@example.com. Flipping it around is just as broken: a wallet that just received a payment has no name to show for the sender, only that string of characters. There was no safe way to look a name up and get back a key you could trust, or to look up a key and get back a name.
When a wallet shows you who issued an item, all it usually has is a public key, a string of letters nobody recognizes. Getting a real name and picture for that key has meant trusting a web link that can rot or change, or calling out to a server every time you want to show it, which fails the moment that server is down or lying. This makes it possible to show a trustworthy name and image for an issuer using only data the wallet already has, with no live lookup required.
These are about something else, and deal with identity on the way.
Reusing one key for everything links all your activity together, and agreeing a fresh key for every interaction is impractical. This lets two parties generate an unlimited supply of keys for each other, where the sender can produce a key only the recipient can later unlock.
Bitcoin addresses were meant to be temporary scaffolding and instead became the thing users are asked to handle. This argues that showing an address to a person is a failure of design, and looks at what ought to replace it.
Developers building on Bitcoin keep designing the same flows from scratch. This collects the user experiences worth getting right, as a reference to work from rather than a specification to implement.
Every application wanting to use a wallet otherwise integrates with each one separately, making every wallet vendor a dependency. This proposes a single interface covering transactions, keys, encryption and identity, so either side can be replaced without rewriting the other.
Deciding whether to trust a certificate means knowing which keys an organisation actually vouches with. This publishes that at the organisation's own domain, so it can be looked up the same way any other website detail is.
When a token carries compliance rules, two wallets checking it must reach the same answer or transfers will be accepted by one and refused by the other. This pins the check down step by step so the outcome is never in doubt.
Proving you hold a key normally takes a back-and-forth, which is more than a single request should need. This lets one request carry its own proof, usable once and no more.
A wallet holding ordinary money, collectibles, credentials and regulated assets at once has to treat them very differently, and nothing says how. This works through what a developer should do so the strict cases stay strict.
Typing a name into a send box only works safely if that name provably belongs to one person and cannot be hijacked, forged, or silently reassigned by whoever runs the lookup service. Before this, uniqueness and identity for human-readable names depended on trusting a registrar or domain operator rather than on something a client could check for itself. This makes it possible to resolve a name to a payment-ready identity key and know the answer is correct without trusting whoever served it.
Losing a password usually means losing an account forever, but trusting one login service with everything makes that service a single point of failure it can abuse or lose. People need a way to open the same wallet account on a new device or recover it after losing a password, a phone, or a service provider, without any single party being able to lock them out or hold their funds hostage.
An app wants to show that a user controls a particular email address or X/Discord account, tied to their wallet identity key, without building its own account verification system from scratch. Different apps and wallets could easily disagree about what that badge actually proves, or quietly start treating a historical "we checked this once" observation as proof of current account control or legal identity. This spec pins down exactly what three widely used social certificate types mean, so wallets and apps interpret them the same way.
Someone running a wallet app for several separate purposes, a personal account, a shop, a brand, normally ends up juggling a different seed phrase or backup for each one, which is tedious to secure and easy to lose track of. This describes a way for one single backed-up secret to safely produce as many separate, unlinkable accounts as needed, each behaving like its own independent wallet, and for all of them to be found again from that one secret alone.
Signing in to a self-custodial wallet on a new phone is normally stuck between two bad options: either some server holds enough of your secret to log you in (so it can also be hacked or coerced into logging someone else in), or you have to manually copy a long recovery phrase between devices every time. This makes it hard to offer a simple "sign in with your email" experience without quietly giving a company the power to open your wallet.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic