What an organization gains when it stops owning the identity

A passport is not issued by an employer

A passport is issued to a person. Employers, landlords, banks, and border officers each decide what it entitles the holder to with them, and each can withdraw that entitlement without touching the passport. Nobody expects a person to cease to exist when a job ends.

In the identity providers most organizations run, it is the other way round. The user is created by the organization, lives inside the organization’s tenant, and is deleted by the organization. A person who works with three organizations is three users, three credential enrolments, and three offboardings — or one user and two projections of it, kept in step by nobody.

We built Trustaige ID so that the person and the organization are different things. An organization grants access, sets the conditions, and can revoke it. It does not issue the person. This note explains how the industry ended up with the tenant-scoped user, what a passkey changes that makes the alternative possible, and what an organization gets from the difference.

How the user came to belong to the tenant

The credential lived in the directory. From LDAP and Kerberos onward,¹² the directory was where a secret was verified, so the user object had to live where the secret lived. The cloud identity providers inherited the shape, and the shape has a reason: a password needs an owner. Someone sets its policy, resets it when it is forgotten, expires it, and answers for it when it leaks. That someone is the organization. So the thing that holds the password — the user — belongs to the organization, and every later decision follows. The user identifier is a tenant identifier. Multi-factor authentication is enrolled per tenant. An outsider is a copy.

The copy takes two shapes in practice. In the first, the outsider is represented in your directory as a separate user object of type “guest”³, with a mangled sign-in name, and is redirected to their home organization to authenticate; if the home organization removes them, you still own a guest object that can no longer sign in. In the second, the outsider gets a fresh user in your tenant with whatever email you like — and a fresh passkey, because the credential is scoped to your tenant’s own domain and works nowhere else.⁴ Enterprises that run several tenants stitch them together with hub-and-spoke federation between them.⁵

In fairness, the business-to-business application platforms do separate a user from the organizations they belong to.⁶ They do it inside one application’s tenant, for that application’s customers. It is the right idea in the wrong place for the directory an enterprise runs its workforce on.

What a passkey changes

WebAuthn moves the secret from the directory to the person.⁷ The private key is generated on the person’s authenticator and never leaves it; the relying party holds only the public key. Four consequences follow, and together they dissolve the reason the user had to belong to the tenant.

Nobody sets or resets it. There is no policy an organization can apply to the secret, because the organization never holds it. What an organization can govern is posture: which authenticators it accepts, whether hardware-bound keys are required, how many credentials a person must hold. Those are conditions on entry, not ownership of the key.

It is scoped to a relying party, not to an organization. A credential is bound to the domain that registered it and cannot be used anywhere else.⁸ If the relying party is the identity platform itself rather than any one tenant, a single credential serves every organization the person ever joins, and none of them can see the others through it.

A discoverable credential names the person. The authenticator returns an opaque user handle that the relying party chose at registration.⁹ We chose the person, and we chose to put nothing else in the credential — no email, no display name that could tie it to an employer. A sign-in therefore begins with no username, no email, and no organization. The platform learns who is present before it asks where they work.

Possession is the proof. An email address is a string anyone can type into an invitation. A passkey ceremony is a proof that only the holder of the key can perform. That difference lets us refuse, as a rule, to ever link a person to an identity by matching an email.

Remove the password, and the coupling between user and tenant has no reason left to exist.

The model

Three things, each with one job.

One rule holds it together: everything an organization owns refers to the organization user, never to the person. Isolation between organizations is therefore structural rather than a policy someone has to remember, and duplicate identities can be merged without anything an organization owns changing.

We did not start here. Our first version scoped credentials to the membership, the way the industry does, and it produced exactly the failures the industry has: re-enrolment for every organization, offboarding that destroyed the person, and no honest way to reconcile duplicates. We moved the credential to the person and rebuilt the layers beneath it. The rest of this note is what that bought.

What it makes possible for an organization

Any domain, no special product. Invitations are not gated by email domain, and the role is the administrator’s choice. A guest is a membership that must carry an expiry date and may hold custom roles such as Auditor. Founding an organization requires a real organizational domain; joining one does not. The asymmetry is deliberate.

Admission without enrolment. The invitation offers two equal choices: create a new identity, or prove an existing one with a passkey ceremony. Either way the organization admits a proven person and runs no credential programme of its own, and its posture policy is still applied at its door. A synced passkey that fails a hardware-key requirement is refused for that organization alone.

Offboarding is revocation. Removing someone revokes the membership. Nothing is deleted, audit records still resolve to a person, and re-invitation is a click. A deprovisioning request from an upstream HR or directory system through SCIM maps to the same revocation.¹⁰

Suspension is confined. Suspending a membership ends that organization’s sessions and no others. Membership status is re-checked on every request, so the suspension holds at once, and a failed check fails closed.

Applications never see the person. The subject an application receives through OIDC, SAML, or SCIM identifies the organization user,¹¹ so the same human carries a different subject in every organization, and the value does not change when identities merge. SAML persistent identifiers go further and are pairwise per service provider.¹² For a group with subsidiaries in several countries, or a regulator applying data minimisation, this is the property that matters: one person, and no way to correlate them across the organizations they belong to.

Merge without disruption. When one person turns out to hold two identities, the merge moves credentials and history to one of them and touches nothing the organization owns, because no organization ever referred to the person directly. Memberships, roles, groups, devices, and audit records stay exactly where they were. The merge is refused if both identities belong to the same organization.

Authority is intact, and bounded. Roles, groups, devices, policies, provisioning, and sessions inside the organization belong to its administrators. Device trust is per organization: a laptop trusted by one is not trusted by another. What the organization does not hold is the credential itself, and that is the point rather than a concession: the organization governs access, not the person.

What the person gains

The same model, seen from the other side of the border.

One identity, one passkey, everywhere. A person enrols once. Every organization they join, as an employee, a contractor, or a guest, is a membership on the same identity, entered with the same passkey, and no organization can see the others through it.

Nothing is lost when access ends. Leaving an organization, or having a guest membership expire, revokes access and nothing else. The identity, its passkeys, and its history remain, and the person is told so in plain words. They can enter another organization, or found a new one, without starting over.

Privacy across memberships. Suspension or revocation in one organization is invisible to the rest, and the person’s own identity page lists only the organizations that currently admit them.

The credential is theirs. No administrator can see, add, or remove a person’s passkeys, and recovery stays in the person’s hands, never sent by SMS or email. The person can see every session their identity holds, in any organization, and end any they do not recognise.

Duplicates are theirs to resolve. A person who ends up with two identities merges them with a passkey from each, on their own authority. Nothing changes on any organization’s side.

How a sign-in goes

sequenceDiagram
    participant P as Person
    participant A as Authenticator
    participant T as Trustaige ID
    participant O as Organization policy
    P->>T: Open sign-in (no username, no email, no organization)
    T->>A: Request a discoverable assertion
    A-->>T: Signed assertion carrying the person's user handle
    T->>T: Credential resolves to one identity
    T->>T: Which organizations is this person an active member of?
    alt none
        T-->>P: Identity page: passkeys, recovery codes, sessions
    else one
        T->>O: Evaluate entry policy (posture, device, risk)
        O-->>T: Admit or refuse
        T-->>P: Session scoped to that organization
    else several
        T-->>P: Choose an organization
        P->>T: Choice
        T->>O: Evaluate entry policy
        O-->>T: Admit or refuse
        T-->>P: Session scoped to that organization
    end

Two details are worth noticing. The organization is chosen after the person is proven, never before, which is why no organization needs to be told about the others. And switching organizations later needs no new ceremony — the person is already proven — but never skips the target organization’s own entry policy.

What this does not solve

One identity, one blast radius. A compromised passkey is a compromised person in every organization at once. Our answer is posture at the door, where each organization decides what it will admit, and a single place where a person can see and end every session they hold anywhere. What we will not add is a switch by which one organization can lock a person out of another.

Recovery is personal. Recovery codes belong to the person and are never sent by SMS or email, and a successful recovery restores the person everywhere. Organizations cannot approve or veto it. A per-organization recovery path would recreate the tenant-owned credential we removed.

We do not accept a password from somewhere else. There is no inbound federation; every person authenticates to the platform with a passkey. An enterprise that requires its existing password-based provider to sit in front of employee sign-in cannot put it in front of ours. We consider that a feature, and we know it is a real cost for an enterprise that has standardised on a password-based provider.

Provisioning can create duplicates. When an upstream directory provisions a person into a second organization, we create a second identity rather than match on email, because an email is an attribute another system asserted, not a proof the person performed. The person links the two with a passkey from each. That is friction we chose over silent, wrong linking.

Subjects are pairwise per organization, not per application. Two applications inside one organization can correlate a user. Persistent SAML identifiers are the exception.

Security signals stay inside the organization. Impossible travel seen by one organization is not shared with another. That is a privacy decision, and a security team may reasonably call it a gap.

The visa, not the passport

The organization issues the visa. It sets the conditions, checks them at the border every time, and can cancel it without notice. It does not issue the person, and it cannot. What an organization gets from this model is a directory that can say exactly who someone is, and exactly what they may do here, without ever having to own them.

References