Organizations and sectors

When you build on Sudomimus, your resources live inside an organization. The developer portal at with.sudomimus.com is organization-based and multi-tenant: an organization owns your applications, sectors, adopted domains, and federation connectors, and you collaborate with teammates by giving them a role in that organization. This page defines those pieces and how they relate.

Account ──member-of──> Organization ──owns──> Application
                            │                      (one per sector)
                            └────────owns────────> Sector

Organizations

An organization is the multi-tenant container that owns everything you create as a developer — applications, sectors, adopted domains, and federation connectors.

• You become a developer simply by creating an organization from the With portal; that makes you its first Owner. “Developer” is not a separate kind of account — it is a capability any Sudomimus user picks up by belonging to an organization.
• Every account holder always has the personal Account surface (Profile, sign-in methods, data sharing). The Developer surface — Organizations, Applications, Sectors — simply lists the organizations you belong to. Belonging to none is a normal state, not an error.
• An organization has limits on how many applications and sectors it can hold, and each account has a limit on how many organizations it can own.

Applications

An application is a single integration — a web app, game, CLI, or OIDC relying party. It carries a permanent applicationAnchor, its signing and client-auth keys, and the three layers of rules that decide who can log in and how. Every application belongs to exactly one organization and exactly one sector.

Sectors

A sector is the identity-isolation boundary. Applications in the same sector see the same opaque identifier for a given user; applications in different sectors see unrelated identifiers for the same person. By default each application gets its own fresh sector (maximum isolation); you opt in to shared identity by placing two applications in one sector.

The privacy contract behind sectors — the sector subject, account alias, and why the raw account ID never leaves the system — is covered in Privacy & pairwise identity.

Roles and membership

Collaboration is managed at the organization level — there is no per-application or per-sector membership. Each member holds one role, and the three roles form a rank:

Viewer < Admin < Owner

What you can do	Minimum role
View applications, sectors, rules, and organization settings	Viewer
Create and edit applications, configure rules, rotate keys, set the claim policy	Admin
Manage members — invite, change a role, remove	Owner
Retire (disable) an application, a sector, or the organization	Sole Owner

Members are invited by their account alias (the user-visible handle, never the internal account ID). An organization can have more than one Owner; the portal refuses to remove or demote the last remaining Owner, so a developer cannot accidentally orphan their own organization.

Retiring resources

There is no hard delete on the developer surface. To take a resource out of service you retire it by disabling it:

• Retiring an application immediately makes every login to it fail, but already-issued tokens keep working until they expire.
• Retiring a sector requires that every application in it is already disabled.
• Retiring an organization requires that every application and sector it owns is already disabled. A retired organization is frozen — no member, rename, or create operation works on it until you re-enable it.

Each of these retire operations requires you to be the organization’s sole Owner, so one co-owner cannot unilaterally pull a shared resource out from under the others.

How this interacts with account deletion

Because retiring is the only way to wind a resource down, account deletion has a guard rail: you cannot erase your account while you are the sole Owner of an organization that still holds a live resource (an enabled application or a non-disabled sector). Retire those first. A co-owned organization never blocks deletion — another Owner remains. See Account deletion for the full erasure flow.

Where this lives

Everything above is managed in the With portal at with.sudomimus.com. A resource that belongs to no organization is platform-managed and never appears in a developer’s dashboard.