Better than anything you’ll read below on the subject:
@@ The below is a mixture of half-baked, foolish and incomplete. Just sos you know. @
Why do you need to authenticate? For authorization. So traditionally, we thinkperson <- (ath’n token) <- identity <- (policy) <- actions
That is, actions are attached to an identity by security policy, identity is
attached to a person by their authentication token.
The problem is that we cannot authenticate a /person/, only the token they
present: password, ATM card+PIN number, etc.
“The Doors of Durin, Lord of Moria. Speak friend, and enter” — Tolkien
Anyone who presents that card+PIN, Elvish catchphrase, or voice print will be
authenticated to act as the corresponding identity (account holder, friend of
the elves, nerdy scientist), and we have no control over those tokens.
The solution is to not care, or rather to reframe our goals.
What we actually want is not to /control/ users’ actions, but to /predict/ them.
When Mr. Blonde helps Mr. White rob a jewelry store it’s a security failure for
the store but a success for the crime gang. When Mr. Orange (an undercover cop)
shoots Mr. Blonde it’s a security failure for the crime gang and a success for
the police. We want to know how to use
If you can predict someone is a vandal or troll, don’t let them change pages, or
only let them post to Ye Flaming Pitte of Flamage.
We can to reasonable satisfaction authenticate a token: only grant that
identity to visitors who bear that token. So this part is fine:
But we have no control over authentication token – identity correspondence.
This part is broken:
The only one who does have that control is the person behind that identity.
They can reasonably guarantee
If that person is going to be in your community, they have an interest in their
identity: they want to be known as someone who isn’t a punk, or doesn’t troll,
or does troll and better than anyone, or won’t rat you out to the cops. The
actions of a person are moderated by their interest in maintaining their
So give up authorization in favor of auditing and recoverability, and authorize
based on reputation — on the past behavior and vouchsafes offered by the
They want to know that they have full control of their identity; among other
things, privacy and an understanding that nobody can act without permission on
their behalf. In fact, we can assure that only a token-holder can assume the
So we need to
Instead ofauthorization → user → token → identity
we assign roles based onauthorization <- trust <- reputation <- identity <- token <- person