17 standards
Keys derived for one counterparty look unrelated to everybody else, which is the point. Sometimes a holder needs to prove to an auditor that two of them really are theirs, and these standards cover how that revelation works and what it cannot prove.
Also searched as linkage revelation, audit, disclosure.
17 standards, spread across 5 of the 12 topics.
Keys derived between two parties are deliberately unlinkable, which is usually the point and occasionally a problem when someone has to audit a relationship. This describes two ways to deliberately reveal that link, and is clear about how much each one gives away.
Filed under Key derivation
Key linkage is the main subject of these 5.
Keys derived between two parties are deliberately unlinkable, which is usually the point and occasionally a problem when someone has to audit a relationship. This describes two ways to deliberately reveal that link, and is clear about how much each one gives away.
Revealing how two parties' keys are linked hands over something genuinely sensitive, and sending it in the clear defeats the purpose. This adds encryption around that revelation so only the intended recipient learns it.
Two people who want to transact need each other's public key, and sending it over a channel someone could tamper with is a real risk. This uses a short code shared out of band to confirm the key really came from the right person.
An earlier way of revealing how two parties' keys are linked asks the recipient to take the claim on faith. This sets out plainly what a verifier cannot check for themselves, as the case for something better.
Different proof systems will be used to back up key-linkage claims, and hard-coding one of them makes the format a dead end. This defines a container that names which proof type it carries, so new ones can be added later.
These are about something else, and deal with key linkage on the way.
An index that watches part of the blockchain is only useful if you can find one, and relying on a single index is a single point of failure. This describes how such services announce what they track, so clients can discover several and survive one going offline.
Knowing which services track which data is not the same as knowing which ones will answer questions about it. This extends the discovery mechanism so a service can advertise the specific queries it is willing to serve.
A message relay is only dependable if there is more than one of them, and clients need some way to find them. This describes how relay servers announce themselves, so no single one has to stay up forever.
Deriving a shared key normally needs one party's private key, which rules out cases where neither side can act. This extends the derivation so a key can be worked out from both parties' public keys alone.
Two parties can derive private keys between themselves, but neither can prove to an outsider that they did it correctly. This adds a way for a third party to check the derivation without being given the ability to spend.
Revealing a shared secret is only useful if the recipient can confirm it is the right one, and handing over the key that proves it defeats the point. This lets the prover demonstrate correctness without revealing anything more.
Two parties talking directly each need to know the other is who they claim, and neither wants to route through a server to find out. This defines a handshake using challenges and signatures, with credentials exchanged along the way.
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 developer holding an existing Bitcoin certificate has no way to show it to tools built for the W3C verifiable credential world without either faking a new signature or exposing more than the subject agreed to. This gives a safe, read-only way to describe that certificate in credential terms while keeping the original signature and encrypted fields exactly as issued.
A service can get cut off from its users when a domain registrar suspends a name, a host is seized, or an app store delists it, even though the service itself is still running fine. Normally there is no way for a client to find a service again once the one path it knew about disappears, short of shipping a brand new app update. This gives a client a way to rediscover the service through a record nobody can take down, because it lives on the blockchain.
If you inscribe content onto a Bitcoin satoshi, anyone can copy the exact bytes into a new output and claim they made it, because the inscription itself proves content existed but not who put it there. Meanwhile, naive ways of adding a signature or label to that output can accidentally make the coin permanently unspendable, freezing the token forever. This standard fixes the layout so you can prove authorship and still move the token.
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