Skip to content
Saphira Linux

Resources ยท Saphira security

What is an AIE?

An AIE (Application Identity Envelope) is Saphira's explicit encrypted web identity and transport model. It lets your browser present account state deliberately and protect sensitive application data without relying on ambient cookies, PHP sessions, or third-party SaaS.

Saphira Linux dragon mascot

AIE in plain language

AIE stands for Application Identity Envelope. It is a special encrypted web token used by Saphira. It is not a normal cookie, not a PHP session, and not a password. It is also not a standard JWE: the AIE format is Saphira's own envelope for identity and transport.

The token itself is both signed and encrypted. Inside it sits a signed set of claims, and that is wrapped in an encrypted envelope before it ever leaves the browser. So the identity Saphira checks cannot simply be read or altered in transit.

When you use a Saphira page, your browser asks Saphira for an identity it can present. It then carries that identity explicitly with each protected request, instead of quietly attaching a cookie to everything. That makes the account relationship visible in the request, which is easier to understand and easier to control.

In everyday terms, AIE is how your browser says 'this is me, talking to Saphira' and how it locks away the private details in a form before they leave your device. You mostly never see it, but it is working every time you sign up, recover an account, edit your profile, or fetch a download.

Two states: guest and signed in

There are two flavours of AIE, and you have already met both. Before you sign in, the page asks Saphira for a short-lived guest identity. That guest AIE lets you do protected things as a visitor, such as requesting a download, without needing an account.

Once you sign in with your passkey, Saphira gives your browser an authenticated AIE instead. That is the token that proves your signed-in state when you open account pages and change account details.

Both are kept in your browser's session storage for the life of the tab, not in cookies and not in a server-side PHP session. The token also carries its own expiry and is rotated as you move through protected account pages, then revoked when you sign out. Close the tab and the browser forgets what it held.

What keeps an AIE tied to you

Every AIE is bound to the page it came from. If a token were somehow copied, it could not be replayed from another website, because Saphira checks the origin on each request.

Once you are signed in, your authenticated AIE is also bound to your browser itself. Saphira rotates it as you move through protected account pages and revokes it the moment you sign out, so an old token has a very short useful life.

On your side, the browser keeps only the encrypted bearer and a non-identifying label. No email address or personal detail is stored in your browser. What little is held there is gone when the tab closes.

What protects a sensitive form submission

When a form contains something private, the browser does not simply post the text. It first obtains a short-lived, one-time challenge tied to the exact action it is about to perform.

It then creates a fresh, throwaway key on the spot, agrees a secret with Saphira's transport key, and encrypts the actual payload with that secret. Your email address, profile details, recovery data, and WebAuthn data are never sent as ordinary readable text. HTTPS still protects the connection, and AIE adds a second layer of encryption inside it.

That challenge is only good for about three minutes and can be used a single time. If anyone intercepted the encrypted message and tried to resend it later, Saphira would reject it, because the challenge would already be spent.

  1. 01The browser obtains a short-lived guest or authenticated AIE.
  2. 02The browser requests a one-time challenge for the specific action it is performing.
  3. 03The browser creates a fresh ECDH P-256 key and encrypts the payload.
  4. 04Saphira checks the action binding, origin, expiry, and bearer state before decrypting.
  5. 05The one-time challenge is consumed, so the encrypted submission cannot simply be replayed.

Where you already meet AIE

AIE is not a separate feature you opt into. It is the quiet machinery behind the account area and a few public actions, and it is why those submissions stay private in transit.

Account signup: your display name and email are encrypted before they reach Saphira.

Email verification and AIP-56 recovery: the recovery key and mailbox details travel inside an AIE envelope.

Profile edits: changes to your display name, about text, and listing choices are encrypted on the way to Saphira.

Downloads: even a visitor's download request is wrapped in a guest AIE envelope before it leaves the page.

Why Saphira uses it

AIE gives the browser explicit control over account state. There is no ambient account cookie to attach to unrelated requests, and no PHP session is needed to remember the browser's account state.

It also means Saphira does not have to hand sensitive account form data to a third-party SaaS transport or identity service. Authenticated state can still be checked and revoked by the server when necessary.

The short version

AIE is how Saphira carries identity and protects sensitive web actions without cookies, PHP sessions, or third-party SaaS. The browser encrypts the form data before it leaves the page, and Saphira accepts it only when the matching short-lived challenge and explicit AIE state are valid.

Further reading