Custom delegations

Where company delegations come from the national company registry, custom delegations are types your team defines for itself. They let users grant other users application-specific authority — "Finance Portal Access", "Server Admin", "School Guardian" — without those relationships needing to exist anywhere outside Kenni.

A custom delegation is a Kenni-managed grant from one person to another (or to themselves), scoped to your team. The grant can be created either inside your application (via the delegation admin prompt) or out-of-band by an administrator, and it stays valid until it expires or is revoked.

Plan setup

Custom delegations are gated by your plan tier. When supported, the Delegations page in the developer portal is where you define types and inspect existing grants.

Defining a delegation type

A custom delegation type is just a named slot. Open Delegations and click New delegation type. Each type has:

• Name — alphanumerics, underscores, and dashes. Kenni prefixes the type with your team domain at runtime, so finance-portal becomes @my-app.is:finance-portal in the token.
• Title (English / Icelandic) — what the user sees in the delegation picker and on the delegation admin screen.
• Description (English / Icelandic) — explanation of what the type grants. Shown on the same screens.
• Access control — optional rules for who can grant the type to others (see below).

A new type is inert until at least one application is authorized to use it. Open the application's Delegations tab and tick the type to add it to Allowed custom delegation types.

Granting a delegation

There are two ways an end user becomes a delegate:

1. Through the developer portal. A team administrator opens the type, picks delegate users, and saves. The grant takes effect immediately.
2. Through your application. Your application sends an authorization request with prompt=delegation_admin. Kenni shows the user a "manage delegates" UI where they can add or remove delegations themselves.

The second path is the typical pattern for self-service delegation: an admin signs in, hits a "Manage access" button in your UI, and Kenni handles the entire grant flow.

Signing in as a delegate

Once a delegation exists, the delegate can authenticate against any application that has the type allowed. Add prompt=delegation to the authorization request:

GET /oidc/auth?prompt=delegation&scope=openid%20display_name&...

Kenni shows the delegation picker. The user picks the delegating account, and your application receives a token whose subject is the delegating account, with the actor's identity nested under actor.*. The delegation_type claim lists the custom types the actor holds for this subject (e.g. ["@my-app.is:finance-portal"]).

The same prompt=delegation request handles both company delegations and custom delegations — the picker shows whatever's available to the user across both.

Access control

Each type has two access-control fields that decide who can grant it:

• Allow personal granting (default on) — when on, any user managing their own delegations can grant the type. Turn it off if the type should only flow through sub-delegation chains.
• Required delegation types (default empty) — when populated, the type is grantable through sub-delegation only when the actor holds at least one of the listed types. The relationship is OR: any one match unlocks granting.

The two fields combine to model real authority chains. Example:

"Finance Portal Access" should only be granted by a procurator or CEO of the company.

• Personal granting: off.
• Required delegation types: c:procurator, c:ceo.

A regular employee opening the delegation admin sees no grantable types and gets access_denied. A procurator opening the same screen, while signed in on behalf of the company, can grant "Finance Portal Access" to others.

Including a custom type in its own required list is also valid — it means "holders of this type can grant it to sub-delegates", which is how multi-level chains are built.

Expiry and revocation

Each individual grant has an expiry date (default: one year from creation). Grants can be revoked at any time from the delegation admin or the developer portal. Revoking is immediate — the next authorization request from the affected actor will no longer offer the delegation.

Next steps