fix(auth): disable ROPC and propose product-rendered passkey ceremonies

ARCHITECTURE.md

@@ -71,6 +71,14 @@ Product extensions are isolated behind `ProductAdminApi`; relying-party client
 CRUD is further narrowed behind `RelyingPartyAdminApi`. Deterministic preflight
 modules require neither protocol nor any network client.
 
+### Proposed product-rendered ceremonies
+
+Product-rendered login, signup, and recovery remain a proposed owner extension
+in [ADR 0019](docs/adr/0019-product-owned-passkey-ceremonies.md), not a current
+service capability. It keeps credential verification and token issuance in
+Keyverse and requires a pinned-engine experiment and origin/RP-ID migration
+before any product consumes the released ceremony contract.
+
 ### Deployment controller
 
 - resolves every `{{placeholder}}` from KV or a secret manager;

CHANGELOG.md

@@ -5,6 +5,10 @@ Keep a Changelog, and releases use semantic versioning.
 
 ## [Unreleased]
 
+- Documented the work required for products to present their own passkey
+  login, signup, and recovery forms. These forms remain proposed, and the
+  existing password-signup route remains unavailable.
+
 ### Added
 
 - ADR-0008 and the non-fork RP authorization matrix, requiring explicit
@@ -111,6 +115,17 @@ Keep a Changelog, and releases use semantic versioning.
 
 ### Fixed
 
+- Disabled `naruon-web`'s Direct Access Grants (ADR-0017) and the
+  `POST /registration/accounts/password` signup endpoint that depended on it
+  (ADR-0018): RFC 9700 §2.4 (BCP 240) and RFC 10017 §7.3 prohibit the OAuth
+  2.0 Resource Owner Password Credentials grant, and disabling it in isolation
+  had left password-only signups with no way to authenticate at all -- the
+  bound `browser-passwordless` flow accepts only passkeys. The endpoint now
+  fails closed (`503`) rather than create dead accounts, the shared runtime
+  adapter no longer carries dormant password-reset authority, and
+  `scripts/validate_realm.py` rejects a silent re-enable of the grant. See
+  `docs/doctoring/2026-09-03-naruon-password-ropc-standards-correction.md`
+  for the full evidence trail.
 - Prevented relying-party inventory from silently accepting a KV key/body
   identity mismatch, rejected unsafe live or `Location`-derived client UUIDs,
   and aligned exact client discovery with Keycloak's documented

deploy/keycloak/README.md

@@ -70,6 +70,26 @@ and `role`/`org`/`workspace` claims required by the current Naruon session
 contract. Its access tokens last 300 seconds; the longer SSO session is serviced
 through normal token refresh/reissue rather than a twelve-hour bearer token.
 
+`naruon-web`'s `directAccessGrantsEnabled` is currently `false`. It was
+briefly `true` as a scoped, reviewed exception
+([ADR-0017](../../docs/adr/0017-naruon-owned-password-form.md)) so naruon
+could render its own login form with zero Keycloak-rendered HTML in the
+loop, but that ADR's Correction (2026-09-03) found the grant type itself
+(OAuth2 ROPC) violates RFC 9700 §2.4 / RFC 10017 §7.3, so the flag was set
+back to `false` pending a standards-compliant replacement. No other RP ever
+gets this exception; the account-unification dynamic-registration validator
+still hard-rejects `directAccessGrantsEnabled: true` for everyone else.
+
+A real password credential to authenticate with comes from
+`POST /registration/accounts/password`
+([ADR-0018](../../docs/adr/0018-naruon-password-credential-issuance.md)),
+gated by its own `password_registration_api_token` — a third bearer
+credential, distinct from `operator_api_token` and `registration_api_token`.
+Without it configured, naruon's signup surface stays unavailable (503)
+rather than open. The realm's `passwordPolicy`
+(`"length(12) and notUsername and notEmail"`) enforces the same minimum a
+second time, server-side, independent of the endpoint's own validation.
+
 ## Bootstrap
 
 ```bash

deploy/keycloak/realm-cwl.json

@@ -3,6 +3,7 @@
   "displayName": "ContextualWisdom IdP",
   "enabled": true,
   "sslRequired": "external",
+  "passwordPolicy": "length(12) and notUsername and notEmail",
   "registrationAllowed": false,
   "registrationEmailAsUsername": true,
   "resetPasswordAllowed": false,

docs/OPERABILITY.md

@@ -66,6 +66,27 @@ must test the **Naruon** product login/token/authorization journey using the
 `naruon-web` RP client ID and verify the expected audience and bounded claims.
 Mapper unit tests alone do not prove Naruon product authorization readiness.
 
+## naruon password-signup 503 (expected, not an incident)
+
+`POST /registration/accounts/password` (ADR-0018) currently returns `503` on
+every call, unconditionally, before any Keycloak work happens. This is
+deliberate, not a live-dependency failure: `naruon-web`'s Direct Access
+Grants was disabled (ADR-0017's Correction, RFC 9700 §2.4 / RFC 10017 §7.3),
+and a password-only account created without it has no way to authenticate --
+the bound `browser-passwordless` flow accepts only passkeys. The endpoint is
+gated behind `services/account_unification/app/password_registration.py`'s
+module constant `PASSWORD_CREDENTIAL_LOGIN_AVAILABLE = False`.
+
+On-call triage: if this 503 is the *only* symptom (health checks, other RP
+clients, and the passwordless registration/login endpoints are otherwise
+green), no incident response is needed -- confirm the constant is still
+`False` in the deployed image and close as expected behavior. Re-enabling
+requires a standards-compliant replacement login mechanism (Authorization
+Code + PKCE or passkey/WebAuthn-capable headless contract), tracked against
+ADR-0017; flipping the constant back to `True` without that replacement
+reintroduces the original RFC violation. Full evidence trail:
+`docs/doctoring/2026-09-03-naruon-password-ropc-standards-correction.md`.
+
 ## Account merge recovery
 
 The active PR implementation makes merge, SCIM full replacement (`PUT`),