<divclass="wrap"><header><divclass="eyebrow"><span>netkingdom-iam-profile-v0.3</span><spanclass="stat">accepted · accepted-1</span><span>net-kingdom</span><span>reviewed 2026-08-22</span><span>generated from canonical source — do not edit</span></div><h1>NetKingdom IAM Profile v0.3</h1><pclass="sub">Source: <code>net-kingdom · canon/standards/iam-profile_v0.3.md · 9781102e2971d762ae42fdd5085a6647afd1cd66</code></p><pclass="sub">Review due: 2027-02-22</p></header><divclass="layout"><navclass="rail"aria-label="Sections"><ol><li><ahref="#purpose"><spanclass="n">·</span>Purpose</a></li><li><ahref="#ownership"><spanclass="n">·</span>Ownership</a></li><li><ahref="#design-principles"><spanclass="n">·</span>Design Principles</a></li><li><ahref="#discovery-contract"><spanclass="n">·</span>Discovery Contract</a></li><li><ahref="#required-flows"><spanclass="n">·</span>Required Flows</a></li><li><ahref="#core-claims"><spanclass="n">·</span>Core Claims</a></li><li><ahref="#tenant-claim"><spanclass="n">·</span>Tenant Claim</a></li><li><ahref="#tenant-roles"><spanclass="n">·</span>Tenant Roles</a></li><li><ahref="#assurance-evidence"><spanclass="n">·</span>Assurance Evidence</a></li><li><ahref="#identity-to-authorization-contract"><spanclass="n">·</span>Identity To Authorization Contract</a></li><li><ahref="#token-lifecycle"><spanclass="n">·</span>Token Lifecycle</a></li><li><ahref="#local-development-profile"><spanclass="n">·</span>Local Development Profile</a></li><li><ahref="#emergency-and-break-glass-access"><spanclass="n">·</span>Emergency And Break-Glass Access</a></li><li><ahref="#conformance"><spanclass="n">·</span>Conformance</a></li><li><ahref="#validation-checklist"><spanclass="n">·</span>Validation Checklist</a></li></ol></nav><main><divclass="rule-quote"><p>Minor version. Per ADR-0011's versioning rule, this adds an optional claim and clarifies non-normative guidance — no required claim, validation rule, or previously-issued token is invalidated. Existing v0.2 implementations remain conformant; <code>tenant_roles</code> and the revised Tenant Claim guidance are additive.</p></div>
<p>The NetKingdom IAM Profile is the provider-neutral OIDC contract that identity implementations issue and applications consume.</p>
<p>It defines:</p>
<ul><li>OIDC discovery and endpoint requirements;</li><li>Authorization Code + PKCE for human login;</li><li>service-account and workload identity token requirements;</li><li>human, service, and agent principal representation;</li><li>tenant, tenant-grouping, and platform-boundary claims;</li><li>tenant capability roles and their carrying mechanism;</li><li>explicit assurance evidence;</li><li>the identity-to-authorization claim contract consumed by flex-auth;</li><li>local-development and emergency-access behavior;</li><li>executable conformance expectations.</li></ul>
<p>Applications target this profile, not a concrete identity provider. key-cape is the lightweight implementation. Keycloak is the expanded-mode implementation. Both are interchangeable at the application and authorization boundary when they conform to this document.</p>
</section>
<sectionid="ownership"><h2>Ownership</h2>
<p>NetKingdom owns the core/platform profile. See ADR-0011.</p>
<p>Downstream systems may define extension scopes, roles, resource names, and tenant policy vocabularies. Those extensions are not part of the core profile unless a future version explicitly adopts them. Extension vocabularies must map back to the core claims in this document before flex-auth or applications consume them.</p>
<ul><li>Consumers trust signed OIDC tokens, not provider-specific sessions.</li><li>Identity providers assert identity and authentication evidence; they do not make final resource authorization decisions.</li><li>The same profile works in lightweight key-cape mode and expanded Keycloak mode.</li><li>Tenancy is explicit. <code>tenant:platform</code> is distinct from tenant planes such as <code>tenant:coulomb</code> and from later tenants grouped per ADR-0013.</li><li>A tenant's onboarding <strong>grouping</strong> (ADR-0013) and its <strong>capability roles</strong> (ADR-0014) are independent axes. Neither is encoded in the other; a tenant's roles may change without renaming its identifier.</li><li>Human, service, and agent principals are distinguishable.</li><li>Assurance evidence is explicit enough for flex-auth policy.</li><li>Local-development issuers are useful but never accepted by production.</li><li>Emergency access is auditable, time-bounded, and reviewable.</li></ul>
<divclass="scroll"><table><thead><tr><th>Field</th><th>Requirement</th></tr></thead><tbody><tr><td><code>issuer</code></td><td>Exact issuer identifier used in tokens</td></tr><tr><td><code>authorization_endpoint</code></td><td>Required for human Authorization Code + PKCE</td></tr><tr><td><code>token_endpoint</code></td><td>Required for token exchange and service accounts</td></tr><tr><td><code>jwks_uri</code></td><td>Required for signature validation</td></tr><tr><td><code>userinfo_endpoint</code></td><td>Required when userinfo is supported by the flow</td></tr><tr><td><code>scopes_supported</code></td><td>MUST include <code>openid</code>; SHOULD include <code>profile</code> and <code>email</code></td></tr><tr><td><code>response_types_supported</code></td><td>MUST include <code>code</code></td></tr><tr><td><code>grant_types_supported</code></td><td>MUST include <code>authorization_code</code>; MUST include <code>client_credentials</code> or a documented workload-token exchange for service identities</td></tr><tr><td><code>id_token_signing_alg_values_supported</code></td><td>MUST include the implementation signing algorithm; RS256 is required for v0.2+ conformance</td></tr><tr><td><code>code_challenge_methods_supported</code></td><td>MUST include <code>S256</code></td></tr></tbody></table></div>
<p>The response SHOULD include <code>end_session_endpoint</code> where logout is supported and <code>claims_supported</code> listing the core claims below.</p>
<p>Consumers MUST discover endpoints and key material from the issuer metadata instead of hardcoding provider-specific paths.</p>
<p>Human users authenticate with Authorization Code + PKCE.</p>
<p>Required properties:</p>
<ul><li>PKCE with <code>S256</code> is mandatory for browser and CLI clients.</li><li>Implicit flow is not part of the profile.</li><li>MFA or equivalent strong assurance is mandatory for privileged, destructive, platform-root, and emergency access in production.</li><li>Access tokens are short-lived.</li><li>Refresh tokens are allowed only for trusted clients with explicit rotation and revocation.</li></ul>
<h3>Service Account Flow</h3>
<p>Service-to-service traffic uses client credentials or a deployment's documented workload identity token-exchange equivalent.</p>
<p>Required properties:</p>
<ul><li>Service subjects are stable and named for service plus environment.</li><li>Secrets or workload credentials are delivered through the credential-management standard, not plaintext configuration.</li><li>Tokens include an audience that identifies the target service.</li><li>Tokens carry <code>principal_type: service</code>.</li><li>Service accounts receive only required scopes and roles.</li><li>Credentials are rotated and never shared between environments.</li></ul>
<h3>Agent Principal Flow</h3>
<p>Agents are automation principals that may act autonomously or under delegated authority.</p>
<p>Required properties:</p>
<ul><li>Tokens carry <code>principal_type: agent</code>.</li><li>Tokens include an <code>agent</code> object with <code>id</code> and <code>mode</code>.</li><li><code>agent.mode</code> is <code>autonomous</code> or <code>delegated</code>.</li><li>Delegated agents MUST identify the delegating actor using <code>actor_sub</code> or an equivalent <code>act.sub</code> claim.</li><li>Agent tokens MUST carry the tenant they operate within.</li><li>Agent tokens MUST include assurance evidence for both the agent credential and any delegated human authority when policy needs it.</li></ul>
</section>
<sectionid="core-claims"><h2>Core Claims</h2>
<p>Access tokens accepted by production consumers MUST provide the following claims after provider mapping or normalization:</p>
<divclass="scroll"><table><thead><tr><th>Claim</th><th>Type</th><th>Meaning</th></tr></thead><tbody><tr><td><code>iss</code></td><td>string</td><td>OIDC issuer URL or issuer identifier</td></tr><tr><td><code>sub</code></td><td>string</td><td>Stable subject identifier unique within <code>iss</code></td></tr><tr><td><code>aud</code></td><td>string or array</td><td>Intended audience; MUST include the receiving service</td></tr><tr><td><code>exp</code></td><td>number</td><td>Expiry timestamp</td></tr><tr><td><code>iat</code></td><td>number</td><td>Issued-at timestamp</td></tr><tr><td><code>nbf</code></td><td>number</td><td>Not-before timestamp, recommended for production tokens</td></tr><tr><td><code>jti</code></td><td>string</td><td>Token identifier, recommended for audit and replay controls</td></tr><tr><td><code>tenant</code></td><td>string</td><td>Tenant identifier such as <code>tenant:platform</code> or <code>tenant:friendly:binky</code></td></tr><tr><td><code>principal_type</code></td><td>string</td><td><code>human</code>, <code>service</code>, or <code>agent</code></td></tr><tr><td><code>groups</code></td><td>array</td><td>Group memberships, possibly empty</td></tr><tr><td><code>roles</code></td><td>array</td><td>Coarse <strong>identity</strong> roles for the subject, possibly empty</td></tr><tr><td><code>scope</code> or <code>scp</code></td><td>string or array</td><td>Granted OAuth scopes</td></tr><tr><td><code>assurance</code></td><td>object</td><td>Authentication and credential assurance evidence</td></tr></tbody></table></div>
<divclass="scroll"><table><thead><tr><th>Claim</th><th>Meaning</th></tr></thead><tbody><tr><td><code>azp</code> or <code>client_id</code></td><td>Authorized client/service identifier</td></tr><tr><td><code>service</code></td><td>Object naming the service and environment</td></tr></tbody></table></div>
<p>Recommended agent claims:</p>
<divclass="scroll"><table><thead><tr><th>Claim</th><th>Meaning</th></tr></thead><tbody><tr><td><code>agent.id</code></td><td>Stable agent identifier</td></tr><tr><td><code>agent.mode</code></td><td><code>autonomous</code> or <code>delegated</code></td></tr><tr><td><code>actor_sub</code> or <code>act.sub</code></td><td>Delegating subject for delegated agents</td></tr></tbody></table></div>
<p>Optional claims (new in v0.3):</p>
<divclass="scroll"><table><thead><tr><th>Claim</th><th>Type</th><th>Meaning</th></tr></thead><tbody><tr><td><code>tenant_roles</code></td><td>array</td><td>Cached tenant <strong>capability</strong> roles (<code>PLTF</code>/<code>IAM</code>/<code>VEN</code>/<code>CUS</code>), possibly empty. See "Tenant Roles" below — this is a point-in-time cache, not the authoritative source.</td></tr></tbody></table></div>
<h3>Role Claim</h3>
<p>The canonical <strong>subject</strong>-level role claim is <code>roles</code>, an array of strings. This is distinct from <code>tenant_roles</code> (below) — a subject's own coarse identity roles are not the same fact as which capability roles the subject's tenant holds.</p>
<p>Expanded-mode Keycloak deployments may also expose provider-native roles such as <code>realm_access.roles</code>, but conforming tokens consumed by flex-auth or applications MUST either emit <code>roles</code> directly or pass through a normalizing adapter that produces <code>roles</code>.</p>
<h3>Scope Vocabulary</h3>
<p>The core profile defines only OAuth/OIDC base scopes:</p>
<divclass="scroll"><table><thead><tr><th>Scope</th><th>Meaning</th></tr></thead><tbody><tr><td><code>openid</code></td><td>Required for OIDC login</td></tr><tr><td><code>profile</code></td><td>Basic profile claims</td></tr><tr><td><code>email</code></td><td>Email claim where appropriate</td></tr><tr><td><code>offline_access</code></td><td>Refresh-token capable access where explicitly allowed</td></tr></tbody></table></div>
<p>Hub-, application-, and resource-specific scopes such as <code>hub:*</code>, <code>ops:*</code>, <code>fin:*</code>, or storage actions are downstream extensions. They are valid only when the consuming system defines them and maps them to flex-auth resource/action semantics.</p>
</section>
<sectionid="tenant-claim"><h2>Tenant Claim</h2>
<p><code>tenant</code> is required for every token accepted by profile consumers.</p>
<p>Tenant identifiers follow <code>tenant:<grouping>:<name></code>, where <code><grouping></code> is one of the taxonomy ratified by ADR-0013 at identifier creation:</p>
friendly - known, easily reached, tolerant of experimentation/instability
single - one-person business entities (freelance consultants)
small - up to 10 employees at time of onboarding (attoo)
medium - up to 100 employees (attoo)
large - up to 1000 employees (attoo)
enterprise - 1001+ employees (attoo)
consumer - private individuals
family - a legal family
community - a non-legal group of people
association - a legal association of people
agentic - financially enabled AI entities</pre>
<p><code>tenant:platform</code> and <code>tenant:coulomb</code> remain <strong>reserved, ungrouped</strong> identifiers outside this taxonomy: <code>tenant:platform</code> is the platform control-plane tenant, not a business entity being onboarded; <code>tenant:coulomb</code> is the first internal/reference tenant established by ADR-0006, predating this taxonomy. Tenant administration for <code>tenant:coulomb</code> or any grouped tenant must never imply platform-root authority.</p>
<p>Subjects may have access to multiple tenants, but a token used for a request MUST identify the tenant context for that request. If a client needs to switch tenant context, it obtains a new token or uses an approved token-exchange flow that records the target tenant.</p>
<p>The grouping segment is an immutable record of the tenant's <strong>onboarding-time</strong> onboarding-risk / entity-shape classification. It remains vocabulary-valid but becomes historical if the tenant's classification later changes. The authoritative current grouping is the <code>grouping</code> field held by <code>tenant-engine</code>; consumers MUST NOT split <code>tenant</code> and treat its middle segment as current policy input. Changing current grouping never renames the tenant. Neither the historical segment nor current grouping gates which capability roles (below) a tenant may hold — see Tenant Roles.</p>
<p>Tenant <strong>capability roles</strong> are a separate fact from the grouping above and from the subject-level <code>roles</code> claim: <code>PLTF</code>, <code>IAM</code>, <code>VEN</code>, <code>CUS</code> (ratified by ADR-0014), non-exclusive — a tenant may hold several simultaneously, and holding one does not require or restrict any grouping.</p>
<p><strong>Source of truth:</strong><code>tenant-engine</code> (<code>canon/standards/tenant-engine-boundary-contract_v0.1.md</code>), not this profile and not any token. <code>tenant-engine</code> records role grants/revocations, their link (if any) to a plan/subscription, and emits domain events on change.</p>
<p><strong>Carrying mechanism — hybrid, not claim-only:</strong></p>
<ul><li><code>key-cape</code> (or Keycloak) MAY stamp a cached <code>tenant_roles</code> claim onto an issued token at issuance time, sourced from <code>tenant-engine</code>.</li><li>Consumers MAY trust the cached claim for ordinary, non-privileged decisions.</li><li>Consumers <strong>MUST NOT</strong> trust the cached claim for privileged, destructive, platform-root, secret, credential-vending, or otherwise <code>assurance.level >= aal2</code>-class decisions. Those decisions <strong>MUST</strong> query <code>tenant-engine</code> live for current role state before authorizing the action.</li><li>This bounds staleness for ordinary actions to the issuing token's lifetime (5-30 minutes for service/agent tokens, see Token Lifecycle) while guaranteeing freshness exactly where a stale grant (e.g. <code>VEN</code> surviving a plan cancellation) would matter most.</li></ul>
<p><code>trial</code>-grouped tenants may hold any capability role without restriction — the grouping exists to showcase, test, and explore every role. Safety for <code>trial</code> tenants is enforced through <code>tenant-engine</code>-owned resource guardrails (spend limits, entity/action counts — reserved, not yet specified), not through role gating.</p>
<p>The canonical assurance claim is <code>assurance</code>.</p>
<p>It is an object with these fields:</p>
<divclass="scroll"><table><thead><tr><th>Field</th><th>Type</th><th>Meaning</th></tr></thead><tbody><tr><td><code>level</code></td><td>string</td><td><code>aal0</code>, <code>aal1</code>, <code>aal2</code>, <code>aal3</code>, or <code>break_glass</code></td></tr><tr><td><code>methods</code></td><td>array</td><td>Authentication methods, e.g. <code>pwd</code>, <code>otp</code>, <code>webauthn</code>, <code>client_secret</code>, <code>workload_identity</code>, <code>upstream_mfa</code></td></tr><tr><td><code>mfa</code></td><td>boolean</td><td>Whether the authentication included multiple factors or equivalent upstream evidence</td></tr><tr><td><code>source</code></td><td>string</td><td>Provider of the evidence, e.g. <code>key-cape</code>, <code>keycloak</code>, <code>privacyidea</code>, <code>entra</code>, <code>local-identity</code></td></tr><tr><td><code>at</code></td><td>number</td><td>Authentication time, recommended</td></tr></tbody></table></div>
<p>Level meanings:</p>
<divclass="scroll"><table><thead><tr><th>Level</th><th>Meaning</th></tr></thead><tbody><tr><td><code>aal0</code></td><td>Local/dev or unauthenticated bootstrap evidence; never production privileged</td></tr><tr><td><code>aal1</code></td><td>Single-factor or service credential evidence</td></tr><tr><td><code>aal2</code></td><td>MFA or equivalent strong upstream assurance</td></tr><tr><td><code>aal3</code></td><td>Phishing-resistant or hardware-backed assurance</td></tr><tr><td><code>break_glass</code></td><td>Time-bounded emergency access with post-event review</td></tr></tbody></table></div>
<p>Privileged, destructive, platform-root, secret, credential-vending, and emergency flows require <code>aal2</code> or stronger unless a policy explicitly permits a narrower service or workload identity path. Emergency access MUST use <code>break_glass</code> and short token lifetimes. This is the same threshold class that gates when <code>tenant_roles</code> MUST be re-validated live against <code>tenant-engine</code> rather than trusted from the token — see Tenant Roles.</p>
<p>Provider-native claims such as <code>acr</code> and <code>amr</code> may be present, but consumers use <code>assurance</code> as the normalized profile claim.</p>
</section>
<sectionid="identity-to-authorization-contract"><h2>Identity To Authorization Contract</h2>
<p>flex-auth consumes IAM Profile tokens as normative identity input. flex-auth MUST NOT re-derive identity, tenant, group, role, or assurance facts from provider-specific session state.</p>
<p>The profile guarantees these inputs for authorization decision envelopes:</p>
<divclass="scroll"><table><thead><tr><th>Decision input</th><th>Source claim</th></tr></thead><tbody><tr><td>Subject</td><td><code>sub</code></td></tr><tr><td>Issuer</td><td><code>iss</code></td></tr><tr><td>Audience</td><td><code>aud</code></td></tr><tr><td>Tenant</td><td><code>tenant</code></td></tr><tr><td>Principal type</td><td><code>principal_type</code></td></tr><tr><td>Groups</td><td><code>groups</code></td></tr><tr><td>Subject roles</td><td><code>roles</code></td></tr><tr><td>Tenant capability roles</td><td><code>tenant_roles</code> (cached); <code>tenant-engine</code> live lookup required for high-stakes decisions</td></tr><tr><td>Scopes</td><td><code>scope</code> or <code>scp</code></td></tr><tr><td>Assurance</td><td><code>assurance</code></td></tr><tr><td>Authorized client</td><td><code>azp</code> or <code>client_id</code>, where present</td></tr><tr><td>Agent/delegation context</td><td><code>agent</code>, <code>actor_sub</code>, or <code>act</code>, where present</td></tr><tr><td>Token lifetime/audit ids</td><td><code>iat</code>, <code>nbf</code>, <code>exp</code>, <code>jti</code>, where present</td></tr></tbody></table></div>
<p>Authorization decisions are made by flex-auth and its delegated PDP adapters. Identity providers may assert roles or scopes, but those claims are inputs to policy, not final permission to act on a resource.</p>
<divclass="scroll"><table><thead><tr><th>Token</th><th>Lifetime</th><th>Notes</th></tr></thead><tbody><tr><td>Human access token</td><td>5-15 minutes</td><td>Short-lived bearer token</td></tr><tr><td>Refresh token</td><td>8-12 hours</td><td>Rotated and revoked on logout or suspicion</td></tr><tr><td>Service token</td><td>5-30 minutes</td><td>Reissued by client credentials or workload identity</td></tr><tr><td>Agent token</td><td>5-30 minutes</td><td>Shorter when delegated or platform-scoped</td></tr><tr><td>Emergency token</td><td>5-15 minutes</td><td>Requires incident/review record</td></tr></tbody></table></div>
<p>Consumers MUST reject expired tokens and tokens with invalid issuer, audience, signature, <code>nbf</code>, or algorithm. Clock skew tolerance SHOULD be small, normally no more than 60 seconds.</p>
<p>JWKS material may be cached, but consumers MUST tolerate key rotation by refreshing JWKS when a token uses an unknown <code>kid</code>.</p>
</section>
<sectionid="local-development-profile"><h2>Local Development Profile</h2>
<p>A local file-backed provider may be used for development, tests, and bootstrap contexts where the full platform is unavailable.</p>
<p>It MUST:</p>
<ul><li>expose OIDC discovery;</li><li>issue signed JWTs;</li><li>support deterministic test users and service accounts;</li><li>use local-only issuer URLs or a clearly local issuer identifier;</li><li>mark tokens as local/development through issuer, audience, or assurance evidence;</li><li>be rejected by production consumers.</li></ul>
<p>Production consumers MUST reject:</p>
<ul><li>issuer <code>local-identity</code>;</li><li><code>http://</code> issuers;</li><li>loopback issuers such as <code>localhost</code> or <code>127.0.0.1</code>;</li><li>tokens with <code>assurance.level: aal0</code>;</li><li>tokens where the environment marks the issuer as local/dev.</li></ul>
</section>
<sectionid="emergency-and-break-glass-access"><h2>Emergency And Break-Glass Access</h2>
<p>Emergency access is allowed only as a break-glass path.</p>
<p>Requirements:</p>
<ul><li>Emergency identities are disabled by default.</li><li>Activation requires an incident, decision, or human-recorded review reference.</li><li>Tokens are short-lived and carry the <code>emergency</code> role.</li><li>Tokens carry <code>assurance.level: break_glass</code>.</li><li>Every emergency action emits an audit/progress/incident event.</li><li>Emergency access is reviewed after use and then disabled again.</li></ul>
<p>Emergency access MUST NOT bypass audit logging or flex-auth policy.</p>
</section>
<sectionid="conformance"><h2>Conformance</h2>
<p>An implementation conforms to IAM Profile v0.3 when it passes the executable conformance suite in:</p>
<pre>tools/iam-profile-conformance/</pre>
<p>The suite validates:</p>
<ul><li>discovery document completeness;</li><li>PKCE <code>S256</code> advertisement and rejection of authorization requests that omit a code challenge;</li><li>JWKS structure and key ids;</li><li>token issuer, audience, expiry, <code>nbf</code>, <code>iat</code>, and RS256 signature;</li><li>tenant, principal type, groups, roles, scopes, and assurance claim shape;</li><li><code>tenant_roles</code> claim shape when present (array of ratified role strings);</li><li>agent and delegated-agent claim shape;</li><li>local-development issuer rejection in production mode.</li></ul>
<p>Conformance must be runnable against both key-cape lightweight issuers and Keycloak expanded-mode issuers. Implementations may add provider adapters, but the token consumed by applications and flex-auth must match the core claim contract above. <code>tenant_roles</code> conformance does not require an implementation to emit the claim (it is optional); when emitted, it must match the ratified vocabulary.</p>
<p>A service or implementation is profile-ready when:</p>
<ul><li>it reads OIDC discovery rather than hardcoding endpoints;</li><li>it validates issuer, audience, expiry, <code>nbf</code>, algorithm, and signature;</li><li>it refreshes JWKS on unknown <code>kid</code>;</li><li>it supports Authorization Code + PKCE for human login;</li><li>it supports service-account or workload identity tokens;</li><li>it emits <code>tenant</code>, <code>principal_type</code>, <code>groups</code>, <code>roles</code>, <code>scope</code>/<code>scp</code>, and <code>assurance</code>;</li><li>it uses the ADR-0013 grouping vocabulary for new tenant identifiers;</li><li>if it consumes <code>tenant_roles</code>, it treats the claim as a cache and re-validates live against <code>tenant-engine</code> before any <code>aal2</code>-class decision;</li><li>it maps provider-native claims into the canonical core claims;</li><li>it rejects local-development issuers in production;</li><li>it logs emergency access with a durable audit trail;</li><li>flex-auth receives identity facts from the profile, not from provider-specific sessions.</li></ul>
