Register the approver client now its callback exists
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 47s
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 47s
informed-decision submitted client_id informed-decision-approver and redirect https://decisions.coulomb.social/auth/callback, with the origin already live and verified by them rather than reported: both / and /auth/callback return 200 on a Let's Encrypt certificate valid to 2026-12-09. The host is decisions, not the decide of an earlier draft. Its path serves a placeholder for now, which does not matter -- the redirect is matched as an exact string and never fetched. Published as a public authorization_code client with S256 PKCE, audience approval-engine, scopes openid/approval:read/approval:approve, mfaRequired true and a declared tenant:platform. No secretRef, since PKCE is the whole proof. TestApproverRegistrationShapeIsExact pins every field, so widening a scope or relaxing MFA fails the build rather than reading as an edit, and asserts the registration passes startup validation -- proving the KEY-WP-0028 tenant exemption holds for the registration that actually depends on it. Two existing guards fired on the way in and neither was loosened. The tenant pin refused an unreviewed client carrying a tenant, which is its purpose, so the approver was added to its reviewed set deliberately. And the audience test panicked slicing secretRef[4:], an assumption that held while the fixture had only confidential clients; the approver is the first public one, so the loop now guards on the env: prefix. The declared tenant reaches the token by the GH-DEC-2026-013 gap route by construction, and tenant_source says so: registration, never directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P Assistant: claude-code Assistant-Model: opus Assistant-Process: 713576@bnt-lap001 Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
This commit is contained in:
parent
f9812ab3b2
commit
c9bb7fac58
5 changed files with 226 additions and 21 deletions
|
|
@ -34,7 +34,16 @@ requests:
|
|||
custody_owner: railiance-platform
|
||||
consumer: approval-engine-operator
|
||||
human_registration:
|
||||
status: awaiting-exact-callback
|
||||
status: submitted-2026-09-10
|
||||
client_id: informed-decision-approver
|
||||
redirect_uri: https://decisions.coulomb.social/auth/callback
|
||||
# Origin verified live before submission: / and /auth/callback both return 200
|
||||
# from 92.205.62.239 on a Let's Encrypt certificate CN=decisions.coulomb.social
|
||||
# valid 2026-09-10 to 2026-12-09, deployed by railiance-apps. The host is
|
||||
# decisions.coulomb.social, NOT the decide.coulomb.social of an earlier draft.
|
||||
# The path serves a placeholder while the surface is gated on
|
||||
# APPROVAL-WP-0002-T01; the redirect is matched as a string and never fetched.
|
||||
origin_verified: true
|
||||
blocks_service_client_rollout: false
|
||||
# Owner identified 2026-09-09: informed-decision (hub repo cf4c7da8). It
|
||||
# supplies client_id and callback URI from INFD-WP-0001-T07 once it has a
|
||||
|
|
@ -58,9 +67,16 @@ human_registration:
|
|||
directory has not placed the user, requires agreement when it has, and
|
||||
refuses issuance on conflict rather than relabelling. Safe only because
|
||||
registrations are static and deployment-owned. Still outstanding from
|
||||
elsewhere: the exact client_id and callback URI from informed-decision
|
||||
(INFD-WP-0001-T07), and whether the owners prefer the directory-sourced
|
||||
resolution instead, which this implementation degrades into cleanly.
|
||||
elsewhere: whether the owners prefer the directory-sourced resolution
|
||||
instead, which this implementation degrades into cleanly.
|
||||
resolved_2026_09_10: |
|
||||
client_id and callback URI received and registered. GH-DEC-2026-013 granted
|
||||
the registration-bound shape as a declared bounded gap, so the declared
|
||||
tenant is admissible; the token says how it got there via tenant_source =
|
||||
"registration", never "directory". Per gate-house's later correction the
|
||||
tenant field carries three facts, and a registration-supplied value is
|
||||
adequate for approval-engine's store-isolation gate and NEVER for doctrine
|
||||
turning on this person's membership of the zone.
|
||||
verification:
|
||||
# The first two lines are now one runnable command per client; see
|
||||
# docs/native-authentication.md, "Verifying a live registration". It writes
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue