13 standards
Both ends of a connection prove their identity to each other, rather than only the server proving its own. Standards here define the handshake, how it rides over HTTP, and how a single request can carry its own proof.
Also searched as Authrite, pairwise authentication, handshake, mutual auth.
13 standards, spread across 7 of the 12 topics.
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.
Filed under Peer to peer
Mutual authentication is the main subject of these 4.
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.
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.
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.
These are about something else, and deal with mutual authentication on the way.
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
Charging a small amount for a single web request is impractical with cards, where the fee can exceed the payment. This describes paying per request with Bitcoin, so an interface can be metered by use rather than sold by subscription.
Some funds should not be movable by one person acting alone. This documents the direct way to require several signatures before an output can be spent, and is honest about what it costs in privacy.
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.
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.
Charging a small amount for a single web request has no standard shape, so every service invents one and no client can be written once. This defines how a server states its price and how a client pays it in the same exchange.
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.
A new arrival meeting a sign-in screen that assumes they already have a wallet simply leaves. This organises the options so the familiar route is offered first and the wallet route is there for those who have one.
Apps that talk to overlay services had no standard way to ask a host "what can you actually do, and on what terms" before sending data. Without that, a client either guesses a URL and hopes, or every integration invents its own private handshake for things like private lookups or proposing a transaction that isn't finished yet. This makes it possible for a client to discover exactly which services and payment or auth rules a host supports, and to safely work with draft transactions that are not yet final.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic