14 standards
A signed statement by one party about another: that this key belongs to someone with this name, or that they passed a check. Standards here cover how a certificate is issued, revealed field by field, and deleted.
Also searched as credential, verifiable credential, attestation.
A digital certificate that attests to facts about a person's or entity's identity, such as name or attributes, signed by a certifier. It allows the holder to selectively prove claims about themselves to others without revealing unnecessary information.
Open in the glossary14 standards, spread across 4 of the 12 topics.
Proving something about yourself online usually means trusting whoever is asking with all of it. This defines a certificate where a third party vouches for your details and you choose which of them any particular verifier gets to see.
Filed under Peer to peer
Certificates is the main subject of these 4.
Proving something about yourself online usually means trusting whoever is asking with all of it. This defines a certificate where a third party vouches for your details and you choose which of them any particular verifier gets to see.
A certificate is only useful if an application can ask for one and later prove you hold it. This defines the requests an application makes to a wallet to obtain a certificate and to reveal selected fields from it.
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.
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.
These are about something else, and deal with certificates on the way.
Two parties talking over a network each want to know who they are dealing with, and neither wants to hand over more about themselves than necessary. This defines a mutual introduction where both sides prove who they are and choose what to reveal.
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.
Anything an application can add to a wallet it should eventually be able to remove, or the wallet fills with things nobody needs. This adds the ability to drop outputs from a group and delete certificates that are no longer wanted.
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.
A peer-to-peer handshake still has to travel over ordinary web requests to work with existing infrastructure. This says exactly which endpoints and headers carry it.
Tokens that must respect real-world rules, such as who is allowed to hold them, have no way to carry that requirement. This attaches identity credentials so the rules travel with the token.
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.
Anyone can sign a digital certificate claiming something about you, like "this email belongs to this person," but a valid signature by itself does not tell you whether the signer actually checked anything, how they handle mistakes, or what happens if the claim turns out to be wrong. Without shared ground rules, two issuers using the same certificate format could have wildly different (or nonexistent) verification practices, leaving anyone relying on the certificate with no way to judge it.
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.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic