Signing In With a Wallet Address, With an Identifier, or the Third Thing We Actually Do
Two approaches get compared constantly in this category. We implement neither, and the honest version of this page says that before it explains them.
A search across this wallet for address-signing vocabulary returns zero files, and a search for the presentation-request vocabulary a challenge-based identifier login would use returns zero as well. A search for the protocol we do use returns four files in the same application, so the searches find sign-in mechanisms when they are there.
Signing in with a wallet address
You prove control of a blockchain address by signing a structured message the site gave you. The site checks the signature against the address and treats the address as your account.
What it is good at: no passwords, no account creation, no third party, and it works with wallets people already have.
What it is not: an identity. The address says nothing about you and the site learns nothing beyond the fact that the same key came back. It is a persistent pseudonym, and a very public one, since everything that address has ever done is readable.
Signing in with an identifier and a challenge
You prove control of a decentralised identifier by signing a challenge, and the verifier resolves your identifier's document to get the key.
What it adds: the identifier can carry more than a key. It can be updated, it can have a recovery policy, and it can be the subject of credentials, so the same login can be extended into "and here is something an issuer said about me".
What it costs: the verifier has to resolve the document, which means depending on whatever infrastructure the method requires. Ours needs the chain, which runs four validators under one operator.
What this wallet actually does
Ordinary OpenID Connect, against our own authorisation service, with an authorisation code and a proof-key exchange. The client is careful about it, and that is a fact about the client rather than about the approach.
Which means: for signing in, this wallet is a conventional application. The identifier matters inside the product, for credentials and recovery, and not for getting through the front door.
That will read as a let-down to anybody expecting the decentralised option. It is what the code does, and describing it as anything else would be the kind of claim this estate exists to prevent.
How to choose between the two, if you are building
Do your users already hold an address? If yes, address signing is the shortest path and needs no new infrastructure.
Do you need the login to carry claims later? If yes, an identifier is the substrate that extends; an address is not.
Can you depend on resolution? An identifier login is only as available as its resolution method, and that dependency is easy to underestimate until it fails.
And if the honest answer is that you need neither, which is the common case because most applications need continuity rather than identity, then conventional sign-in is the right answer and nothing in this category improves on it.