Case Study 1: Translating a Jargon-Dense Paragraph for the Public

A composite, fictional-but-realistic example. The technical content is accurate; the scenario and the author ("Priya Sharma," a security engineer asked to write for her company's blog) are illustrative.

The situation

Priya Sharma is a security engineer. Her company just shipped support for passkeys, and marketing asks her to write a blog post explaining "what passkeys are and why they're safer than passwords" for ordinary customers—people who reuse one password across six sites and have never heard the word "phishing-resistant." Priya, like most experts handed this task, writes the first draft the way she'd explain it to another engineer. Here is her opening paragraph.

❌ The expert draft (accurate, and opaque to the reader):

Passkeys are a passwordless authentication mechanism based on public-key cryptography (the WebAuthn/FIDO2 standard). Instead of a shared secret, your device generates an asymmetric key pair: the private key never leaves your device's secure enclave, while the public key is registered with the service. Authentication is performed via a cryptographic challenge-response signed by the private key, which makes passkeys inherently phishing-resistant, since there is no credential to intercept or replay and the signature is bound to the origin.

Every word is correct. To the customer, it is a wall. Let's count the bricks: passwordless authentication mechanism, public-key cryptography, WebAuthn/FIDO2, shared secret, asymmetric key pair, private key, secure enclave, public key, cryptographic challenge-response, phishing-resistant, credential, replay, signature, origin. That's fourteen technical terms in three sentences—a jargon budget blown roughly five times over (§28.3). A reader who arrived from a search for "are passkeys safe" is gone by the second comma.

The finding Priya actually needs to convey is simple and worth conveying: with a password, you and the website share the same secret, so anyone who steals it (or tricks you into typing it on a fake site) can log in as you; with a passkey, your device keeps a secret it never shares with anyone, and only proves it has the secret—so there's nothing to steal and nothing to trick out of you. That's the idea. Now watch the translation.

The translation

The move is the one from §28.2: find the one relationship that matters (a shared secret can be stolen or phished; an unshared secret can't), then map it onto a source the reader already owns. Priya tries a few sources and picks the one that maps cleanest.

✅ The translated version (one analogy, jargon within budget):

Think about how a password works. You and the website both know the same secret word. Every time you log in, you hand over the secret, and the site checks it against its copy. That's the problem: because you both have the same secret, anyone who steals the site's copy—or tricks you into typing your secret on a fake lookalike site—can now log in as you. A reused password is one stolen secret away from unlocking your whole life.

A passkey works completely differently, and the difference is easiest to see with a wax seal.

Imagine you have a signet ring—a ring that stamps a unique seal into wax. You can press your seal onto a letter, and anyone can look at it and confirm "yes, that's really her seal." But here's the thing: they can confirm the seal without ever holding the ring. The ring never leaves your finger. So even if someone photographs your sealed letter, they can't forge a new one, because they don't have the ring—and you never have to hand it over to prove it's yours.

A passkey is that ring. Your phone or laptop holds a secret it never gives to anyone—not even to the website you're logging into. When you sign in, your device just "stamps the seal": it proves it holds the secret without revealing it. The website checks the stamp and lets you in. There's no shared secret sitting on a server to be stolen, and there's nothing for a fake site to trick out of you, because you never type or send the secret at all. That's why a passkey can't be phished the way a password can.

The fourteen terms became, effectively, one that the reader needs to walk away with—"passkey"—plus "phished," which the first paragraph already defined in passing (tricked into typing your secret on a fake site). Everything else—public-key cryptography, asymmetric key pair, secure enclave, challenge-response, signature, origin—is gone, its meaning carried by the ring instead. The reader finishes understanding the actual security property (the secret is never shared, so it can't be stolen or phished), which is the thing that was worth conveying. Nothing was dumbed down; the real idea is fully intact. It was translated.

Where the analogy breaks (and why Priya flags it)

The signet ring is a strong analogy, and like every analogy it breaks somewhere (§28.3). Priya runs the two-step check.

Step 1 — list the divergences. A real signet seal can be forged by a skilled enough copyist; a passkey's cryptographic proof can't be forged without the secret. A ring can be physically stolen off your finger; a passkey is protected by your device's lock (your fingerprint or face). And a wax seal proves who sent a letter, while a passkey proves to a specific site that you're you.

Step 2 — does any break sit on her point? Her point is "the secret is never shared, so there's nothing to steal from the server or phish out of you." The forgeability of wax seals sits uncomfortably close to that point—a reader might think "but seals can be faked, so can't passkeys?" So Priya flags exactly that break, and lets the rest go:

(One way the ring analogy isn't perfect: a real wax seal could be forged by a clever artist, but a passkey's "stamp" can't be copied without the secret itself, which never leaves your device. And if you're worried about someone stealing your phone—your passkey is still locked behind your fingerprint or face.)

That parenthetical does the §28.3 job: it names the one break that sits on her point (forgery), pre-empts the smart reader's objection, and—per the "Why Does This Work?" box in the chapter—raises her credibility rather than lowering it, because it shows she knows precisely where her own simplification stops matching. The divergence about who vs. which site is off to the side of her point, so she leaves it unflagged.

The lesson

Three moves turned a wall into an explanation, and they're the chapter in miniature:

1. Find the one relationship that matters. Not "explain public-key cryptography"—explain the secret is never shared, so it can't be stolen or phished. Everything else is apparatus the reader doesn't need.
2. Map it onto a source the reader already owns. The signet ring carries the whole idea—prove you hold a secret without revealing it—using something the reader can already picture, so no vocabulary has to be taught first.
3. Find the break and flag the load-bearing one. The ring can be forged; that break sits on the point, so Priya names it. The rest she lets go.

And note the discipline that made it possible: Priya didn't write the analogy first. She first asked what is the one thing this reader must walk away understanding?—and only then went looking for the source that maps it. The expert draft failed not because Priya can't write, but because she wrote for the reader in her own head (another engineer) instead of the reader on the other end of the search bar. That's the curse of knowledge (Chapter 2), and the cure is the same as always: name the jargon, map it to something familiar, and test it on someone who doesn't already know.

Back to: Chapter 28 · Exercises · Case Study 2 · Key Takeaways