Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a13eab-1e6a-7b33-9c37-372e90ada3a2
6.8 KiB
Sign-in diagnosis contract
Status: accepted contract for NK-WP-0051. This document is the only copy of the field list; other repositories link here instead of restating it.
Why
MASON-WP-0011 took a day because three facts about one login were split
across the account site, Authelia, and OpenBao. OpenBao said only
claim "groups" does not match any associated bound claim values. Every
surface below shows the same three facts, named the same way, for this
authorization request and no earlier one.
Fields
| Field | Meaning | Source |
|---|---|---|
uid |
The uid KeyCape resolved for this request | Authelia preferred_username (fallback sub), as KeyCape's Authelia adapter resolves it |
groups |
Directory group display names, sorted | That uid's LLDAP memberOf, reduced to display names |
assurance |
aal2 if this request verified a one-time code, else aal1 |
KeyCape: a one-time code verified within this request. Not MFAVerified alone, which is also true when a reused aal2 session satisfies the request |
client_id |
The relying party the login returns to | The authorization request |
openbao_error |
OpenBao's error text, verbatim | ops-mason receipt only |
assurance is per request. A reused session that was aal2 earlier is
aal1 here unless this request asked for and verified the one-time code.
Enrolling a factor is not aal2.
Authelia's own authentication_level is not assurance. KeyCape checks the
one-time code through privacyIDEA, so Authelia reports level 1 even for an
aal2 sign-in. Surfaces take assurance from KeyCape (the request or the
token it issued), never from Authelia's /api/state.
Never shown or logged
Tokens (ID, access, refresh, OpenBao), authorization codes, email
addresses, one-time passwords or seeds, passwords, session cookies, and raw
memberOf DNs. Group display names and the uid are the diagnosis; they are
not secret.
Where each field appears
| Surface | Fields | Owner | Task |
|---|---|---|---|
| KeyCape page before the redirect to the application. Opt-in per client (registration flag, default off), enabled first for the OpenBao client. One action: continue, plus how to sign in as someone else | uid, groups, assurance, client_id |
key-cape | NK-WP-0051-T02 |
| The existing KeyCape auth log line | client_id, uid, assurance |
key-cape | NK-WP-0051-T02 |
Account site users.coulomb.social: account-site uid and current Authelia uid on two separate lines. Authelia's cookie domain stays coulomb.social |
uid (twice, labelled by session), assurance of the account-site session |
user-engine | NK-WP-0051-T03 |
lldap_admin.py groups --user <uid> (read-only preview) |
uid, groups |
net-kingdom | NK-WP-0051-T04 |
ops-mason verifier receipt for an attended bao login |
uid, openbao_error (and assurance when known) |
ops-mason | NK-WP-0051-T06 |
Matching groups to an OpenBao role stays a metadata read in ops-mason.
Negative-login fixture
Fixture uid: tegwick (selected by the founder on 2026-10-15).
Founder confirmed existing MFA enrollment and directory membership of
railiance-admins only. The attended diagnosis independently of the directory
preview showed that same group list and aal2 before OpenBao refused the
workload login. This replaces the original
proposed fixture signin-probe-negative.
- not a member of
reuse-surface-hub-writers - not a platform admin (
net-kingdom-admins) - holds a one-time password (existing MFA confirmed by the founder for
NK-WP-0051-T05; factor management at
https://pink-account.coulomb.social/, realmcoulomb)
The user is never created or described with credentials in git. A
successful diagnosis of this fixture shows uid=tegwick,
groups without reuse-surface-hub-writers, assurance=aal2, and then the
OpenBao groups refusal.
Evidence
| Item | Value |
|---|---|
| key-cape page and log line | live 2026-10-15: forgejo.coulomb.social/coulomb/key-cape@sha256:cdec9dd7c515f7e0a6169fc3fa560ee2cc47bf40d899755dec808c362f5ce010 (source 8c6c071, includes af3b1b0). signInDiagnosis: true set on live openbao-admin 2026-10-15 (sso/keycape-config rv 71655453 → 75372162, byte-preserving, issuer restarted). Accepted 2026-10-15: founder bao login -method=oidc -path=netkingdom role=platform-admin showed the page and completed |
| user-engine two-session lines | live 2026-10-15: forgejo.coulomb.social/coulomb/user-engine@sha256:1e6547c40c93c49f01438edcf76c20f561ccebc110220bae020723505aa56c70 (source 7f1db71, pinned in rapp-user-engine a42c68f). Also shows the account-site session assurance. Founder accepted: platform-root · aal2 and Authelia platform-root |
ops-mason receipt, fresh-browser login, capabilities-self proof |
ops-mason fca5591 (MASON-WP-0012); both attended proofs passed 2026-10-15, member token revoked. Receipts |
sys/capabilities-self grant and UI workload-role select |
railiance-platform 0f0282a (RPF-WP-0057); CCR-2026-0045 approved by founder for both requested roles and applied through contained admin session (exit 0). Overlay deployed and make openbao-verify-login-overlay passed. Separate UI button clickthrough remains RPF-WP-0057-T04 |
Attended acceptance — 2026-10-15
Both native verifier receipts passed. The founder observed the diagnosis before continuing each login and confirmed the resulting OpenBao response:
| Login | Diagnosis | OpenBao result |
|---|---|---|
| Admin apply | platform-root, includes net-kingdom-admins, aal2 |
Accepted; CCR-2026-0045 applied; contained session exited 0 |
| Member proof | bernd.worsch-3, includes reuse-surface-hub-writers, aal2 |
Accepted; exact workload policy, intended reads, parent/sibling denials, token revoked |
| Negative proof | tegwick, railiance-admins only, aal2 |
Refused: claim "groups" does not match any associated bound claim values |
Acceptance record and receipt digests,
member receipt,
negative receipt.
The receipts contain no token or KV value; callback codes are redacted.
The negative receipt names tegwick and preserves OpenBao's refusal text.
The uid and assurance receipt inputs are corroborated by the founder's
observations for those exact requests; CLI arguments alone are not evidence.
The approved login overlay is deployed and its HTTP verification passes. Direct browser exercise of its role-selection controls remains in the existing owner task RPF-WP-0057-T04; native attended OIDC logins exercised both roles. NK-WP-0051's attended diagnosis/refusal goal is met. No group memberships, admin entity policies or survey grant were changed; no KV values were read.