Access control and the application resource catalog

A common platform mistake is to make the identity provider decide everything a user may do. Authentication and authorization are related, but they are not the same responsibility.

Ireti Identity establishes who is present. Ireti Platform determines what that principal may do, for which organization, workspace, application, and resource, using current platform state.

Identity answers who; the control plane answers what

Identity tokens carry trusted authentication context: issuer, subject, client, session, and selected organization context. They do not permanently encode every platform assignment or product entitlement.

Ireti Platform keeps assignments in its control plane and evaluates them at the time of the request. This supports immediate revocation: removing a grant can deny the next request even if the bearer token was issued earlier.

The approach resembles mature cloud control planes:

Cloud control-plane concept	Ireti equivalent
Identity directory	Ireti Identity
Resource manager	Ireti Platform
Resource scope	Organization, workspace, application
Role definition	Platform or application role
Role assignment	Principal to role at an exact scope
Resource provider	First-party or approved partner application
Runtime policy decision	Current Platform authorization decision

The analogy is useful because it keeps identity context separate from scoped, revocable authorization.

Applications are resources

Every application in the catalog has a stable identity and explicit lifecycle. Its definition can describe:

• provider ownership;
• presentation and discovery metadata;
• launch mode;
• workspace and provisioning behavior;
• declared permissions and roles;
• entitlement and seat requirements;
• support policy; and
• approved release stage.

These fields do not all carry the same authority. A logo cannot grant access. Catalog approval does not activate an application for a tenant. Activation does not assign a seat. A seat does not create product-domain permission.

The platform preserves those distinctions so each change is intentional and auditable.

Scope is part of the decision

Authorization is evaluated for an exact resource scope:

principal
  @ organization
  @ workspace
  @ application
  @ operation

The same person may administer one workspace, contribute in another, and have no access to a third. An application assignment in one workspace does not grant access to another workspace or another product.

URLs, hostnames, aliases, display names, and token-selected tenants are selectors. They are not authorization evidence.

Products consume decisions

Products own their domain data and domain rules. They do not need direct access to identity administration, platform databases, or the authorization store.

Instead, a product receives or requests a bounded decision containing the stable principal, organization, workspace, application, and approved capabilities relevant to that interaction.

The product then applies its own final domain rules. A platform role cannot invent financial ownership, a school relationship, document permission, or CRM record access.

Partner applications use the same boundary

A partner joins as an independent resource provider rather than as code copied into an existing product.

The partner:

• registers its application definition;
• declares its scoped capabilities;
• uses public Platform contracts;
• receives only tenant-bounded decisions;
• owns its product runtime and data; and
• cannot grant platform-wide or cross-application authority.

It never receives identity-provider administration, billing-engine administration, platform secrets, or direct data-store access.

For tenant administrators, first-party and partner applications follow the same mental model: discover, adopt, provision, assign, launch, audit, and revoke.

Why current-state authorization matters

Putting all permissions in a long-lived token creates stale authority. A user can lose a seat, an application can be suspended, a subscription can end, or a provider binding can become invalid while the token remains cryptographically valid.

Ireti treats token validity as necessary but insufficient. The runtime decision also checks the current resource state. This makes revocation behavior predictable and prevents identity configuration from becoming an accidental authorization database.

The result is a reusable control plane: one identity foundation, one scoped access model, one application catalog, and independently owned products.