The key stays with the holder

What happened

Nothing broke on a single morning. The standing fact on this desk is a distinction the public documents already draw. NIST Special Publication 800-63B describes authenticators a subscriber possesses or controls, as opposed to a secret that only a server can check. The W3C Decentralized Identifiers specification describes an identifier whose controller can prove control without that proof living only in one company's account database. This brief files that distinction. It is not a report that two blogs posted it this week. The paper's front is Futureweb.

A session is not a key

A session is a record a service keeps that says this browser, for now, is allowed in. The service can delete the record. The person cannot open the account on a machine the service refuses. That is a useful design for a website, and it is a poor description of identity the person holds. A key the holder carries can be checked by anyone who has the public half, including a program that is not the vendor's login page. NIST's authenticator types put "something you have" in that second group. A password the vendor stores a hash of is closer to the first, because the check still happens at the vendor.

What the identifier standard actually says

DID Core does not say every login on the internet must change. It defines a scheme: a decentralized identifier resolves to a document, and the controller of the identifier can be verified from material in that document. The registry that resolves the name is not automatically the landlord of the session. Readers collapse those. A company can still run a resolver. The standard's point is that control of the identifier is a cryptographic fact, not only a row the company can drop. This page does not implement the specification. It says what a reader should not confuse it with.

Why it matters on this desk

The privacy desk files tracking, identity a vendor can revoke, and data that left the room. A story about a breach of a session database is this desk when the question is who could delete or copy the sign-in. If that incident is also a bug CISA has placed on the Known Exploited Vulnerabilities catalog, the catalog is the evidence that exploitation is claimed, and it is listed with the sources. The same incident is the security desk when the question is the product version and who can reach the bug, filed as the advisory.

Revocation is the whole argument

The feature people like in a vendor account is the kill switch: lose the phone, the vendor invalidates the session. The cost is that the vendor can use the same switch when the person did not lose the phone. A key the holder carries needs a different revocation story, usually a list the holder or a chosen set of witnesses updates. Pretending those are the same convenience is how a product page hides the dependency. This desk will say which revocation is on offer. It will not call both of them "you are in control." Later pieces on the distinction stay on Privacy.

Where the documents disagree

NIST 800-63B is written for federal login and for proofing a person. It assumes an agency, or a company playing that role, is the relying party. DID Core is written so the identifier does not require that agency to be the only source of truth. They are not opposing press releases about one product. They answer different questions: how a formal login should check an authenticator, and how a name can be proven without one registry. A brief that says NIST "endorsed" decentralized identity, or that the W3C "replaced" passwords, is putting words in both documents. Neither sentence is in them.

What to watch next

Watch for a sign-in change that moves the check off the vendor's session table, and for a sign-in change that only renames the session. The test is boring. Can a second piece of software, not written by the account vendor, verify the holder without calling home? If the answer is no, the key is still a session with a new label. If the answer is yes, the desk has a fact worth a follow-up. The software desk's neighboring question, about code that reads untrusted bytes, is memory safety in the release notes.

When the key is the mechanism

If a later story is about a key the person holds, checked in process, rather than a session a landlord deletes, the network that brief may cite is MATA.NETWORK.

What is still unknown

Most consumer products have not published a clear account of which authenticator type they use in NIST's terms. Marketing that says "passwordless" often still means a vendor-mediated prompt on a device the vendor can still unpair. Until the vendor says where the private key sits, and who can wipe it, the desk records the claim as a claim and waits for the next note that names the location. Asking that of each new sign-in is how the desk stays repeatable across the later briefs. The security desk remains the place for the bug itself, Security.