How it works
Five steps, and the interesting part is step four.
1 · You click “Continue with IntraID” on their site
Their site sends you to us. It never sees your password, and it cannot pre-fill, skip or style this step — the consent screen is ours and it refuses to load inside a frame.
2 · You see exactly what is being asked, and what for
Each line is one field for one purpose, in the company's own registered words. Nothing is bundled. You untick anything you do not want and approve the rest.
3 · They get a code name, not a person
Their app receives an identifier like usr_9f21c8… that is derived from you and them. The same you at another company is a completely different string, so two companies comparing databases cannot find the overlap.
4 · To email you, they ask us to do it
This is the part that is not like anything else. A company holds a handle such as eml_4a1f…. It posts a subject, a body and a purpose. We decrypt your address, send the message, write the ledger row, and drop the address. It was never in their request and it is not in our response. The same goes for one-time codes: we generate it, we send it, and when they ask “did the code match?” they learn yes or no.
5 · You watch, and you can stop it
Every read, every message, every refusal appears in your ledger with the app, the field, the purpose and the time. One click revokes — their live tokens die in that instant, not at the end of some session.
What a company can never do
| Read your email address or phone number | No endpoint exists. |
| Market to you | The platform refuses that purpose outright. |
| Keep using data after you revoke | Tokens are checked against the live grant on every call. |
| Match you with another company's records | Your identifier is different for each of them. |
| Look up someone who never used their button | There is no search, no list, no export. |
| Quietly erase what it did | The ledger is hash-chained; tampering shows. |