# 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/`,
  realm `coulomb`)

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](evidence/2026-10-15-sign-in-diagnosis/acceptance.json) |
| `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](evidence/2026-10-15-sign-in-diagnosis/acceptance.json),
[member receipt](evidence/2026-10-15-sign-in-diagnosis/reuse-surface-hub-writer-member.txt),
[negative receipt](evidence/2026-10-15-sign-in-diagnosis/reuse-surface-hub-writer-non-member.txt).
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.