12 standards
Somebody has to issue certificates, and an application has to decide which issuers to believe. Standards here cover how an issuer publishes what it certifies and how it operates, and how a reader tracks whose word they accept.
Also searched as trust anchor, issuer, trust network, reputation.
The party that issues an identity certificate. Anyone relying on the certificate is trusting the certifier, not the site showing it.
Open in the glossary12 standards, spread across 4 of the 12 topics.
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.
Filed under Peer to peer
Certifiers and trust is the main subject of these 2.
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.
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.
These are about something else, and deal with certifiers and trust 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.
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.
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.
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.
Shared systems like a village granary or a blockchain network need someone to actually do the maintenance work, but whoever does that work can start to confuse running the thing with owning what it is for. Without a way to separate the rules of a system from whoever currently claims to enforce them, cooperation ends up depending on trusting one person or group forever, and the whole system becomes fragile the moment that keeper disagrees, retires, or goes bad.
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.
Letting people into a group chat or forum usually means keeping a list of names someone approved, and whoever approves them isn't the one who pays if a bad actor gets in or a good one gets shut out. Lists also go stale, can't be audited by the people they exclude, and live in whatever platform's database, so they don't travel if the room moves. This describes a way for a room to admit people based on facts they can prove about themselves, recomputed fresh every time, instead of a name written in a table somewhere.
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.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic