@tideorg/mcp 1.4.2 → 1.9.1

package/canon/security-runtime-probes.md

@@ -0,0 +1,177 @@
+# Security Runtime Probes
+
+Turns **INFERRED** static findings into **VERIFIED** ones by observing the live target's actual behavior. This is the second tier of the `tide-security-analyst` workflow: static inspection finds *candidate* gaps in code; runtime probing *confirms* which are real against the running system.
+
+A static finding says "this route appears unprotected." A runtime probe says "this route returned 200 with no credentials — here is the response." The second is evidence; the first is a hypothesis.
+
+---
+
+## Authorization gate — read before probing anything
+
+Runtime probing sends real requests to a real system. It is only permitted when **all** of these hold. If any is unmet, stop and stay in static-only mode.
+
+1. **Explicit authorization.** The operator owns the target or has written authorization to test it. Confirm this in the report's scope line. No probing of third-party systems on a hunch.
+2. **Non-production or agreed window.** Probing production is allowed only with explicit operator consent; prefer staging. Never probe a system you were merely *shown*, only one you were *asked to test*.
+3. **Target is a network endpoint the operator named.** Do not discover-and-probe adjacent hosts, subdomains, or internal services you happened to find in config.
+
+**Absolute limits — these are not "best-effort", they are the boundary of this role:**
+
+- **Non-destructive only.** GET and safe HEAD/OPTIONS. Never send probes that create, modify, or delete data. For write endpoints, confirm the *auth response* (401/403 vs 200) using a request the server rejects *before* it mutates — never complete a mutating call to "see if it works."
+- **No exploitation.** Confirm a gap exists; do not weaponize it. Reaching an unauthorized endpoint and reading one response header confirms SG-05. Dumping the database behind it does not — that is an attack, not an analysis.
+- **No credential attacks.** No brute force, no password spraying, no token cracking, no fuzzing that could lock accounts or trip abuse defenses. Observing that no rate limit exists is a note (out of scope, not a Tide gap); actually exhausting it is not permitted.
+- **Rate-limited and low-volume.** A handful of deliberate requests per finding, not a scan. You are confirming named hypotheses, not enumerating the attack surface.
+- **Stop on the first confirmation.** Once a probe confirms a finding, record it and move on. Do not escalate.
+
+If the operator asks for active exploitation, penetration testing, or load/abuse testing, that is a different engagement with different rules — decline within this role and say so.
+
+---
+
+## How probing upgrades evidence
+
+Each finding carries a confidence tag (`canon/security-gap-mapping.md`). Runtime probes move findings up this ladder:
+
+| Before (static) | Probe | After |
+|---|---|---|
+| INFERRED — route has no visible auth in code | Unauthenticated GET returns 200 with data | **VERIFIED** |
+| INFERRED — bearer tokens, no DPoP handling seen | Replay a captured token from a second client; it is accepted | **VERIFIED** (replayable) |
+| ASSUMED — operator says "we verify JWTs" | Send a token with `alg: none` / tampered payload; it is accepted | **VERIFIED** (SG-13 real) |
+| INFERRED — remote JWKS fetch in code | Observe a JWKS request to the certs endpoint at verification time | **VERIFIED** (SG-10) |
+
+A probe that *fails to confirm* is just as valuable: it downgrades or drops a false positive. Record both outcomes. A finding that survived a probe attempt is far stronger than one that was only read from code.
+
+---
+
+## Probe procedures by gap
+
+Each probe: the observation that confirms the gap, the safe request to make, and how to read the result. `$T` = the operator-named base URL.
+
+### SG-04 / SG-05 — client-only authz / unprotected APIs
+
+**Confirms**: an endpoint enforces nothing server-side.
+
+```bash
+# Enumerate candidate routes from static analysis, then for each sensitive one:
+curl -s -o /dev/null -w "%{http_code}\n" "$T/api/<route>"
+# 200 with no Authorization header on a sensitive route = CONFIRMED unprotected (SG-05)
+# Compare: same route WITH a valid session vs WITHOUT — identical output = no server-side check (SG-04)
+curl -s "$T/api/<route>" | head -c 300   # inspect: is real data returned unauthenticated?
+```
+Read: 401/403 unauthenticated = protected (drop/downgrade the finding). 200 with data = confirmed. 200 with an empty/error body = ambiguous, note it, do not overclaim.
+
+### SG-03 — bearer token replay (no proof-of-possession)
+
+**Confirms**: a stolen token works from anywhere, no key binding.
+
+```bash
+# With operator-provided test token (their own session), replay from a clean client / different IP context:
+curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer $TESTTOKEN" "$T/api/<protected>"
+# 200 with a plain replayed bearer and no DPoP header = CONFIRMED replayable (SG-03)
+# If the server demands a fresh DPoP proof, it will reject the bare bearer.
+```
+Read: acceptance of a bare replayed bearer confirms the gap. Use only a token the operator supplied from their own account.
+
+### SG-13 — JWT algorithm confusion / unverified signature
+
+**Confirms**: the verifier trusts the token's claimed algorithm or skips verification.
+
+```bash
+# Using the operator's own valid token as a base, craft a NON-mutating GET with:
+#  (a) alg swapped to "none" and signature stripped, or
+#  (b) a modified claim (e.g. a role) re-signed with an empty/guessed key
+# Send to a read-only protected route and observe acceptance.
+curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer $FORGED" "$T/api/<protected>"
+# 200 = CONFIRMED the signature is not properly verified (SG-13 / SG-02 exposure)
+```
+Read: this is the one probe that constructs a token — keep it read-only, use the operator's own account as the base, and do not use any elevated claim to perform an action. Acceptance confirms; rejection (401) means the verifier is sound on this vector. Never chain a confirmed forgery into a real privileged operation.
+
+### SG-10 — remote JWKS fetch
+
+**Confirms**: the verifier fetches keys over the network at verification time.
+
+```bash
+# Observe from the operator's own logs/network capture whether a request goes to
+# /.well-known/jwks.json or /protocol/openid-connect/certs during token verification.
+curl -s -o /dev/null -w "%{http_code}\n" "$T/.well-known/jwks.json"
+# Endpoint existing is not proof of use; correlate with a verification-time fetch in the app's egress logs.
+```
+Read: confirmation requires observing the *app* fetch keys during verify, not just that the endpoint responds. If you can only see the endpoint, keep the finding INFERRED.
+
+### SG-06 / SG-17 — server-readable sensitive data / user secrets
+
+**Confirms**: sensitive data is returned in the clear or is app-decryptable.
+
+```bash
+# With the operator's authorization, request a record the authenticated user owns:
+curl -s -H "Authorization: Bearer $TESTTOKEN" "$T/api/<record>" | head -c 500
+# Plaintext sensitive fields in the response = server can read them (SG-06/SG-17 confirmed for data-in-transit-from-server)
+```
+Read: plaintext in the API response proves the server holds readable data. Do NOT attempt to reach other users' records to "prove" IDOR — that is exploitation and a separate (out-of-scope) class. Confirm only against the operator's own test account.
+
+### SG-15 — session lifecycle
+
+**Confirms**: sessions don't rotate / don't expire as claimed.
+
+```bash
+# Non-destructive: capture the session id/cookie before and after login with the operator's test account.
+# Same id after authentication = no rotation (fixation exposure). Operator drives the login; you observe.
+# For expiry: note token exp; re-use after the claimed lifetime in a read-only call.
+```
+Read: an unrotated identifier across a privilege boundary confirms fixation exposure. Observe only; the operator performs the login.
+
+### SG-01 / SG-02 — surface confirmation only
+
+These are confirmed from **artifacts**, not live probing: a schema showing a password-hash column (SG-01), a signing secret visible in the operator-shared config/env (SG-02). Do not attempt to crack hashes or extract keys — possession of the artifact plus its role in the auth path is the confirmation. Keep these static.
+
+---
+
+## Probes that are NOT allowed in this role
+
+- Reaching **other users'** data to demonstrate IDOR/broken-object-level-authz (exploitation; also an out-of-scope class per `canon/security-gap-mapping.md`).
+- Any **write/delete** to confirm a mutating endpoint is unprotected — confirm via the auth-layer response before the mutation, never by completing it.
+- **Injection, XSS, SSRF, traversal** payloads — these confirm out-of-scope classes and constitute active exploitation.
+- **Rate-limit / brute-force / load** testing — a different engagement.
+- Probing anything the operator did not explicitly name as in scope.
+
+Finding one of these classes statically is reportable (in the out-of-scope section); *actively exploiting* it to confirm is not part of this role.
+
+---
+
+## Recording probe results
+
+For every probe, the finding in the report gains a **Runtime confirmation** line:
+
+```
+- Runtime confirmation: <exact request> → <observed response, e.g. "200, JSON with 14 user records, no auth header"> [VERIFIED]
+```
+
+or, when a probe failed to confirm:
+
+```
+- Runtime confirmation: <request> → <e.g. "401 Unauthorized"> — finding NOT confirmed at runtime; downgraded to <INFERRED/dropped>
+```
+
+A report that ran the runtime tier states, in its Method line, `both (static + runtime)` and lists which SG findings were probed. Findings that were *only* inferred and not probed stay tagged INFERRED — never present an unprobed hypothesis as though it were confirmed.
+
+---
+
+## Verification (of this probe pass)
+
+- [ ] Authorization and scope confirmed in writing before any request was sent.
+- [ ] Every probe was non-destructive (no create/update/delete completed).
+- [ ] No probe reached data outside the operator's own test account.
+- [ ] No out-of-scope class was actively exploited to "confirm" it.
+- [ ] Each probed finding has a Runtime confirmation line with the exact request and observed response.
+- [ ] Findings not probed remain tagged at their static confidence level.
+
+## Anti-Patterns
+
+- **AP-SEC-7** — Probing a system the operator showed but did not authorize testing. Authorization is per-target and explicit.
+- **AP-SEC-8** — Completing a mutating request to "check if it's protected." Confirm at the auth layer; never mutate.
+- **AP-SEC-9** — Escalating a confirmed gap into exploitation (dumping data, reaching other accounts, chaining a forged token into a real action). Confirm and stop.
+- **AP-SEC-10** — Presenting an unprobed static hypothesis with runtime-level confidence. Only a probe upgrades the tag.
+
+## Status Legend
+
+- **VERIFIED** — observed directly (static artifact or runtime response)
+- **INFERRED** — strongly implied by code, not yet probed
+- **ASSUMED** — operator statement, unconfirmed

package/canon/tidecloak-bootstrap.md

@@ -61,12 +61,12 @@ For projects that do not use the init script, follow the manual sequence below.
 
 ## Docker Images
 
-| Image | Use when | Forseti support | `tide-roles-mapper` | ORK env vars required |
-|-------|----------|----------------|---------------------|-----------------------|
-| `tideorg/tidecloak-dev:latest` | Standard development, full Tide protocol | Yes | **Yes** | **No** — built-in defaults |
-| `tideorg/tidecloak-stg-dev:latest` | Staging, testing pre-release features | Yes | **No** — silently dropped on import | **Yes** — must be provided |
+| Image | Use when | Forseti support | ORK env vars required |
+|-------|----------|----------------|-----------------------|
+| `tideorg/tidecloak-dev:latest` | Standard development, full Tide protocol | Yes | **No** — built-in defaults |
+| `tideorg/tidecloak-stg-dev:latest` | Staging, testing pre-release features | Yes | **Yes** — must be provided |
 
-**Staging mapper gap**: The `tide-roles-mapper` protocolMapper provider exists on the production image (`tidecloak-dev`) but not staging (`tidecloak-stg-dev`). Realm import silently drops the mapper with no warning. Include standard Keycloak role mappers (`realm roles`, `client roles`) as fallback in the template alongside the Tide-specific mapper. VERIFIED (learning-batch-004, L-06).
+**Role mapper fallback (defensive)**: The Tide role/claim mappers in the shipped realm templates use **stock Keycloak mapper types** — `oidc-usermodel-attribute-mapper` (for `tideUserKey`/`vuid`) and `oidc-hardcoded-claim-mapper` (for `t.uho`). There is no distinct `tide-roles-mapper` provider in the extension repos on `main`; a mapper by that instance name only appears in some external app realm.json files. A prior note claimed a `tide-roles-mapper` protocolMapper provider exists on the prod image but is silently dropped on the staging image — this could not be confirmed against source and image contents were not inspected. Treat it as unverified. As a defensive measure, include standard Keycloak role mappers (`realm roles`, `client roles`) in the template so token role claims survive regardless of image.
 
 Use `tidecloak-dev` for standard development. It has built-in ORK/threshold defaults and does not need `KC_HOSTNAME`, `SYSTEM_HOME_ORK`, `USER_HOME_ORK`, `THRESHOLD_T`, `THRESHOLD_N`, or `PAYER_PUBLIC`. Use `tidecloak-stg-dev` only when testing against pre-release Tide features.
 
@@ -140,13 +140,13 @@ Order matters. Do not skip or reorder steps.
 | 4 | Get master admin token | `POST /realms/master/protocol/openid-connect/token` | Bearer token |
 | 5 | Create realm | `POST /admin/realms` with realm.json template | Realm + client |
 | 6 | Initialize Tide + enable IGA | `POST /admin/realms/{realm}/vendorResources/setUpTideRealm` then `POST /admin/realms/{realm}/tide-admin/toggle-iga` | License activated, VRK generated, IGA enabled |
-| 7 | Approve client + role change requests | `sign` + `commit` on `/tide-admin/change-set/clients/requests` AND `/roles/requests`. **Roles must be approved here** — `setUpTideRealm` creates `tide-realm-admin` as a draft when IGA is enabled. Without approval, role lookups in Step 8c fail. | Client config + roles committed |
-| 8 | Create admin user | `POST /admin/realms/{realm}/users` | User creation change request created |
-| 8b | Approve user creation | `sign` + `commit` on `/tide-admin/change-set/users/requests` | User queryable. **Must happen before role assignment.** |
+| 7 | Approve client + role change requests | `authorize` + `commit` on `/iga/change-requests` (bulk-authorize then commit ready CRs; see `canon/iga-change-requests-api.md`). **Roles must be approved here** — with IGA enabled, change requests are created in `PENDING` status (there is no `DRAFT` status token); `setUpTideRealm` creates `tide-realm-admin` as a draft. `tide-realm-admin` is a client role on `realm-management`; it is granted to the first admin via firstAdmin auto-commit during the login-closure converge, after which a `REGEN_ADMIN_POLICY` change request flips the authorizer from `firstAdmin` to `multiAdmin`. Without approving the pending role CRs here, role lookups in Step 8c fail. | Client config + roles committed |
+| 8 | Create admin user | `POST /admin/realms/{realm}/users` (returns 202 → user-creation change request) | User creation change request created |
+| 8b | Approve user creation | `authorize` + `commit` on `/iga/change-requests` | User queryable. **Must happen before role assignment.** |
 | 8c | Assign tide-realm-admin role | Assign `tide-realm-admin` client role on `realm-management`. Validate role lookup returns a role, not an error. | Admin user has role |
 | 9 | Generate invite link | `POST /tideAdminResources/get-required-action-link` with `["link-tide-account-action"]` | URL for admin to link Tide account |
 | 10 | Wait for account linking | Poll user `tideUserKey` attribute until non-empty | Admin has Tide identity |
-| 11 | Approve role assignment change requests | `sign` + `commit` on `/tide-admin/change-set/users/requests` and `/roles/requests` | Admin roles committed |
+| 11 | Approve role assignment change requests | `authorize` + `commit` on `/iga/change-requests` | Admin roles committed |
 | 12 | Update CustomAdminUIDomain | `PUT /identity-provider/instances/tide` then `POST /vendorResources/sign-idp-settings` | Enclave approval popups work from app origin |
 | 13 | Export adapter JSON | `GET /vendorResources/get-installations-provider?clientId={uuid}&providerId=keycloak-oidc-keycloak-json` | `tidecloak.json` with `jwk`, `vendorId`, `homeOrkUrl` |
 
@@ -163,7 +163,7 @@ Order matters. Do not skip or reorder steps.
 
 **Anti-pattern:** Using `/tide-admin/setUpTideRealm`. Wrong path. Returns 404. VERIFIED.
 
-**Anti-pattern:** Sending JSON to this endpoint. Causes "Could not create tide realm" (`email is null or empty`). VERIFIED.
+**Anti-pattern:** Sending JSON to this endpoint (instead of `x-www-form-urlencoded`). Causes the setup to fail with "Tide realm setup failed" / "Could not set up the Tide realm". VERIFIED.
 
 ### toggle-iga
 
@@ -173,16 +173,21 @@ Order matters. Do not skip or reorder steps.
 
 ### Approve/commit change requests
 
-- Sign: `POST /admin/realms/{realm}/tide-admin/change-set/sign`
-- Commit: `POST /admin/realms/{realm}/tide-admin/change-set/commit`
-- Both accept JSON: `{ "changeSetId": "...", "changeSetType": "...", "actionType": "..." }`
-- For batch: use `/sign/batch` and `/commit/batch` with `{ "changeSets": [...] }`
+Current `/iga/change-requests/...` surface (replaces legacy `/tide-admin/change-set/...`, GAP-065). **Full spec + bootstrap loop: `canon/iga-change-requests-api.md`.**
+- List pending: `GET /admin/realms/{realm}/iga/change-requests?status=PENDING` (objects keyed by `id`)
+- Authorize (sign): `POST /admin/realms/{realm}/iga/change-requests/{id}/authorize` (body `{}` optional; records an approval, does **not** commit; simple firstAdmin/Tideless lane — refuses multiAdmin CRs)
+- Batch authorize (bootstrap): `POST /admin/realms/{realm}/iga/change-requests/bulk-authorize` with `{ "actionTypeIn": ["CREATE","DELETE"], "limit": 100 }`
+- Approve (multiAdmin): `POST /admin/realms/{realm}/iga/change-requests/{id}/approve` (enclave lane; approves AND auto-commits once quorum met — the console "Authorize" button)
+- Commit: `POST /admin/realms/{realm}/iga/change-requests/{id}/commit` (explicit apply-only; 412 if under threshold / unmet dependency)
+- FirstAdmin/Tideless: authorize signs server-side. Tide MultiAdmin: use the `{id}/approval-model` enclave exchange, then `approve`.
+
+> **Legacy-bootstrap note.** The bootstrap init script (`init_tidecloak.sh`) on the keycloak-IGA fork still drives the **legacy** `/tide-admin/change-set/*` surface (`sign`/`commit`, and `/sign/batch` + `/commit/batch` with `{ "changeSets": [...] }`). That surface is stale — it is kept here only to explain what the existing script calls; reach for `/iga/change-requests/*` in new integration code.
 
 ### Adapter config export
 
 - Path: `GET /admin/realms/{realm}/vendorResources/get-installations-provider`
 - Query: `clientId={uuid}&providerId=keycloak-oidc-keycloak-json`
-- The `jwk` field is only present when IGA is enabled.
+- The `jwk` field is injected only when a `tide-vendor-key` component and its EdDSA signing key exist on the realm. `setUpTideRealm` creates both, so `jwk` appears once licensing has run. It is **not** gated on IGA. If `jwk` is missing, the remedy is to ensure `setUpTideRealm` ran successfully (not to enable IGA).
 
 ---
 
@@ -249,7 +254,7 @@ When bootstrapping realms programmatically on a hosted TideCloak instance (e.g.,
 
 ### Two-Phase Provisioning
 
-Role assignment MUST happen after the admin user links their Tide account. IGA change requests require a Tide doken to be signable. Without a linked identity, the sign endpoint returns 200 but the change-set remains in DRAFT permanently.
+Role assignment MUST happen after the admin user links their Tide account. IGA change requests require a Tide doken to be signable. Without a linked identity, the authorize endpoint returns 200 but the change request remains unsigned/uncommitted permanently.
 
 **Phase A** (automated, before user interaction):
 Steps 1–9 from the standard sequence, EXCEPT step 8c (role assignment). Generate the invite link at the end.

package/canon/tidecloak-endpoints.md

@@ -35,21 +35,16 @@ GET /realms/{realm}/public/get-tide-config?clientId={clientId}
 
 Public endpoint. Returns `vendorId`, `homeOrkUrl`, client auth origins, and branding URLs for a client. No auth required.
 
-### Admin Policy (for E2EE)
+### Role / Encryption Policies
 
-```
-GET /realms/{realm}/tide-policy-resources/admin-policy
-```
-
-Public endpoint. Returns the base64-encoded admin policy needed for policy-based encryption operations. Also available as `/admin-policy/bytes` (raw) and `/admin-policy/display` (human-readable).
-
-### Role Policy
+Signed role/encryption policies are managed through the admin IGA surface:
 
 ```
-GET /realms/{realm}/tide-policy-resources/policy?roleId={id}&clientId={id}
+GET /admin/realms/{realm}/iga/role-policies
+GET /admin/realms/{realm}/iga/role-policies/name/{name}
 ```
 
-Public endpoint. Returns the Midgard policy for a specific role on a client.
+Each role-policy record carries the signed `policy` bytes and `policySig` used by policy-based encryption/decryption. The older public `tide-policy-resources/admin-policy` and `.../policy` endpoints are not present on current main (`tidecloak-iga-extensions`); see `canon/custom-contracts.md`.
 
 ### Vouchers
 
@@ -73,20 +68,18 @@ GET /realms/{realm}/tide-idp-resources/clientIframe/iss/{iss}/aud/{aud}/tide_dpo
 
 Serves the DPoP authentication iframe HTML. `iss` and `aud` are hex-encoded. The SDK uses this internally.
 
-### Token Exchange (Delegation)
+### Token Exchange (RFC 8693)
 
 ```
 POST /realms/{realm}/protocol/openid-connect/token
 ```
 
-Standard OIDC token endpoint used for delegation token exchange:
+Standard OIDC token endpoint used for RFC 8693 token exchange (server-to-server, e.g. a backend calling a downstream protected service on behalf of the user):
 - `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`
 - `subject_token=<user access token>`
-- `actor_token=<browser-signed delegation request>`
-- `dpop_approval=<session key approval>`
-- `DPoP` header: server's DPoP proof
+- `actor_token=<acting-party token>` (optional)
 
-See `canon/delegation.md` for full flow.
+For the shipped .NET wiring, see `playbooks/protect-aspnet-core-asgard.md` (Step 5). Browser-driven server-side delegation (the asgard-tide Node SDK, the same one keylessh uses) is unmerged and intentionally not documented here.
 
 ---
 
@@ -134,113 +127,82 @@ Generates a link for the admin user to link their Tide account. Time-limited (de
 
 ---
 
-## IGA Change-Set Endpoints
+## IGA Change-Request Endpoints
 
-Used for multi-admin governance approval flows.
+Used for multi-admin governance approval flows. **Current surface: `/iga/change-requests/...`** (iga-core), confirmed by Tide 2026-07-07 (GAP-065). This **replaces** the legacy `/tide-admin/change-set/...` surface. Full spec, payloads, status codes, and the bootstrap approve/commit loop: **`canon/iga-change-requests-api.md`**.
 
-### List Pending Changes
+### List / get change requests
 
 ```
-GET /admin/realms/{realm}/tide-admin/change-set/users/requests
-GET /admin/realms/{realm}/tide-admin/change-set/roles/requests
-GET /admin/realms/{realm}/tide-admin/change-set/clients/requests
-GET /admin/realms/{realm}/tide-admin/change-set/groups/requests
-GET /admin/realms/{realm}/tide-admin/change-set/all/requests
-GET /admin/realms/{realm}/tide-admin/change-set/counts
+GET /admin/realms/{realm}/iga/change-requests?status=PENDING   # PENDING|APPROVED|DENIED|CANCELLED
+GET /admin/realms/{realm}/iga/change-requests/{id}
 ```
 
-### Sign and Commit
+Each CR object is keyed by `id` (replaces legacy `draftRecordId`), with `entityType`, `actionType`, `status`, `readyToCommit`, `threshold`, `authorizers[]`, `dependsOn`/`blocked`.
 
-```
-POST /admin/realms/{realm}/tide-admin/change-set/sign
-Body: { "changeSetId": "...", "changeSetType": "...", "actionType": "..." }
+### Authorize (sign) and Commit
 
-POST /admin/realms/{realm}/tide-admin/change-set/commit
-Body: { "changeSetId": "...", "changeSetType": "...", "actionType": "..." }
+```
+POST /admin/realms/{realm}/iga/change-requests/{id}/authorize    Body: {} (optional)   → 200/403/409
+POST /admin/realms/{realm}/iga/change-requests/{id}/commit                              → 200/412
 ```
 
-Batch variants: `/sign/batch` and `/commit/batch` with `{ "changeSets": [...] }`.
+Batch approve (bootstrap): `POST /admin/realms/{realm}/iga/change-requests/bulk-authorize` with `{ "actionTypeIn": ["CREATE","DELETE"], "limit": 100 }` (429 if a bulk run is already in progress). Bulk authorizes but does not commit — commit the CRs that become `readyToCommit`.
 
-### Cancel
+### Deny
 
 ```
-POST /admin/realms/{realm}/tide-admin/change-set/cancel
-Body: { "changeSetId": "...", "changeSetType": "...", "actionType": "..." }
+POST /admin/realms/{realm}/iga/change-requests/{id}/deny         → 204
 ```
 
-### Approve/Reject (multi-admin)
+### Two-phase approval (Tide MultiAdmin, enclave)
 
 ```
-POST /admin/realms/{realm}/tideAdminResources/add-review
-Content-Type: multipart/form-data
-Fields: changeSetId, changeSetType, actionType, requests
-
-POST /admin/realms/{realm}/tide-admin/add-rejection
-Content-Type: multipart/form-data
-Fields: changeSetId, actionType, changeSetType
+GET  /admin/realms/{realm}/iga/change-requests/{id}/approval-model   → { changeRequestId, requestModel(base64) }
+POST /admin/realms/{realm}/iga/change-requests/{id}/approval-model   Body: { "requestModel": "<base64 doken>" }
+                                                                     → { recorded, authCount, threshold }
 ```
 
-Note: `add-review` and `add-rejection` use `multipart/form-data`. All other change-set endpoints use JSON.
-
-### Activity and Comments
+### Comments and ADOPT
 
 ```
-GET  /admin/realms/{realm}/tide-admin/change-set/{id}/activity
-POST /admin/realms/{realm}/tide-admin/change-set/{id}/comments
-Body: { "comment": "..." }
+GET/POST /admin/realms/{realm}/iga/change-requests/{id}/comments        Body: { "comment": "..." } (≤2000)
+PUT/DELETE /admin/realms/{realm}/iga/change-requests/{id}/comments/{commentId}
+POST /admin/realms/{realm}/iga/adopt   Body: { "entityType": "USER", "entityId": "..." }   → 201/409
+GET  /admin/realms/{realm}/iga/change-requests/{id}/diagnostic-bundle
 ```
 
+**Legacy → current:** `change-set/{type}/requests` → `iga/change-requests?status=PENDING`; `change-set/sign[/batch]` → `iga/change-requests/{id}/authorize` (+ `bulk-authorize`); `change-set/commit[/batch]` → `iga/change-requests/{id}/commit`; `change-set/cancel` → `.../{id}/deny`; `tideAdminResources/add-review` → `.../{id}/approval-model`; field `draftRecordId` → `id`. Enabling IGA is unchanged: `POST /admin/realms/{realm}/tide-admin/toggle-iga`.
+
 ---
 
 ## Policy and Contract Endpoints
 
-### Policy Templates
+Served under `@Path("iga")`. (The older `tide-admin/policy-templates`, `tide-admin/ssh-policies`, `tide-admin/realm-policy`, and `role-policy/{id}/init-cert` endpoints no longer exist on main.)
 
-```
-POST   /admin/realms/{realm}/tide-admin/policy-templates
-GET    /admin/realms/{realm}/tide-admin/policy-templates
-PUT    /admin/realms/{realm}/tide-admin/policy-templates/{id}
-DELETE /admin/realms/{realm}/tide-admin/policy-templates/{id}
-```
-
-Body: `{ name, description, contractCode, modelId, parameters }`
-
-### Realm Policy
+### Role Policies
 
 ```
-GET    /admin/realms/{realm}/tide-admin/realm-policy
-POST   /admin/realms/{realm}/tide-admin/realm-policy/pending
-POST   /admin/realms/{realm}/tide-admin/realm-policy/commit
-POST   /admin/realms/{realm}/tide-admin/realm-policy/request-delete
-POST   /admin/realms/{realm}/tide-admin/realm-policy/commit-delete
-DELETE /admin/realms/{realm}/tide-admin/realm-policy
+GET    /admin/realms/{realm}/iga/role-policies
+GET    /admin/realms/{realm}/iga/role-policies/{id}
+GET    /admin/realms/{realm}/iga/role-policies/name/{name}
+POST   /admin/realms/{realm}/iga/role-policies
+DELETE /admin/realms/{realm}/iga/role-policies/{id}
+DELETE /admin/realms/{realm}/iga/role-policies/name/{name}
 ```
 
-### SSH Policies (per-role)
-
-```
-PUT    /admin/realms/{realm}/tide-admin/ssh-policies
-GET    /admin/realms/{realm}/tide-admin/ssh-policies
-DELETE /admin/realms/{realm}/tide-admin/ssh-policies?roleId={id}
-```
-
-Body: `{ roleId, contractCode, approvalType, executionType, threshold, policyData }`
+POST body (`IgaRolePolicyRepresentation`): `{ name, policy, policySig, contractId, approvalType, executionType, threshold, policyData }`. `name`, `policy`, and `policySig` are required (`policySig` ≤ 512 chars).
 
 ### Forseti Contracts
 
 ```
-PUT /admin/realms/{realm}/tide-admin/forseti-contracts
-GET /admin/realms/{realm}/tide-admin/forseti-contracts
+GET    /admin/realms/{realm}/iga/forseti-contracts
+GET    /admin/realms/{realm}/iga/forseti-contracts/{id}
+POST   /admin/realms/{realm}/iga/forseti-contracts
+DELETE /admin/realms/{realm}/iga/forseti-contracts/{id}
 ```
 
-Body: `{ contractCode, name }`
-
-### Role Init Cert
-
-```
-POST /admin/realms/{realm}/tide-admin/role-policy/{roleId}/init-cert
-Body: { initCert, initCertSig }
-```
+POST body (`IgaForsetiContractRepresentation`): `{ contractCode, name }`. Returns the stored contract with its `contractHash` (SHA-512 of the source).
 
 ---
 
@@ -250,34 +212,34 @@ Infrastructure-level. Used during initial setup and license rotation.
 
 ```
 POST /admin/realms/{realm}/vendorResources/generate-initial-key
-POST /admin/realms/{realm}/vendorResources/generate-initial-vrk-v1
-POST /admin/realms/{realm}/vendorResources/confirm-initial-vrk
-POST /admin/realms/{realm}/vendorResources/rotate-vrk
 POST /admin/realms/{realm}/vendorResources/switch-vrk
-POST /admin/realms/{realm}/vendorResources/requestFreeTierLicense
 GET  /admin/realms/{realm}/vendorResources/isPendingLicenseActive
 GET  /admin/realms/{realm}/vendorResources/getLicenseDetails
 GET  /admin/realms/{realm}/vendorResources/licenseHistory
 ```
 
+Initial license issuance is driven by `setUpTideRealm` (free-tier); ongoing license drafts/trigger/history are handled by the IGA licensing endpoints (`/iga/licensing/*`).
+
 ---
 
 ## Utility Endpoints
 
 ```
-POST /admin/realms/{realm}/vendorResources/sign-message
-  FormParam: data
-
 GET /admin/realms/{realm}/vendorResources/get-tide-jwk
+```
 
-POST /admin/realms/{realm}/tide-admin/generate-default-user-context
-  Body: [clientId1, clientId2, ...]
+---
+
+## Other IGA Endpoints
 
-POST /admin/realms/{realm}/tide-admin/what-if-token
-  Body: { changeSetType, actionType, userId, clientId }
+Also served under `@Path("iga")` / `@Path("iga-tve")` (plus a `tide-admin` user-context read):
 
-GET /admin/realms/{realm}/tide-admin/user-context/{userId}/{clientId}
-GET /admin/realms/{realm}/tide-admin/change-set/{changeSetId}/user-context
+```
+GET|POST|DELETE /admin/realms/{realm}/iga/authorizers[/{id}]     # realm authorizer (firstAdmin/multiAdmin) config
+GET|POST        /admin/realms/{realm}/iga/server-certs[...]      # server-identity / mTLS cert issuance (request/issue/revoke/active/instance)
+GET|POST        /admin/realms/{realm}/iga/licensing/[...]        # license drafts / trigger / history
+POST            /admin/realms/{realm}/iga-tve/tve-bundle         # TVE attestation-unit bundle export (CBOR/JSON)
+GET             /admin/realms/{realm}/tide-admin/user-context/{userId}/{clientId}   # effective user context (roles/claims) for a client
 ```
 
 ---