A message to railiance-platform listed the upstream issuer pin as outstanding
when the committed receipt showed it done ten hours earlier. Corrected to them
directly; recorded here with the other two instances because the pattern is the
point, not the individual slip. docs/evidence/ is the authoritative artifact for
live proofs in this repository, and reading it is cheaper than the corrections
it prevents.
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
Read-only inspection shows KEY-WP-0013-T02's custody gate has moved since
yesterday: both approval clients are registered in sso/keycape-config, both
secrets exist in the namespace and are wired into the pod, and the image is
pinned to the digest T06 published. The live issuer passes every conformance
check that needs no credential.
That does not establish the claim contract. Subject, tenant, roles, scopes,
lifetime and excess-scope denial are what keycape verify-client proves, and it
needs the client secret in the environment. Reading either secret is client-side
retrieval, which the provisioning packet records as not admitted, so that run is
an attended operator action. T02 now waits on the run, not on custody.
Also re-verified the KEY-WP-0028 rule against the deployed config, after a peer
noted it fails closed at startup with a rollout imminent. The three browser
clients there carry neither serviceSubject nor roles; the three service clients
carry both legitimately. Kept as errors rather than warnings on that evidence.
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
serviceSubject and roles are read only on the client_credentials path. On a
browser client they are accepted and then ignored, since subject and roles come
from the directory user -- so a registration that looks effective fails later as
a downstream rejection rather than as a registration defect. tokenLifetime was
already rejected this way, so the rule existed and was incomplete.
Nothing in dev-config, the example fixture or the live deployment sets either
field on a browser client, checked against all three rather than assumed, so this
breaks no existing configuration.
tenant is deliberately excluded, and a test pins that: a browser client may
declare one, and humanTenant resolves it against the directory, refusing issuance
when they disagree (KEY-WP-0013-T05). An earlier version of this change rejected
tenant too and would have made that feature unusable. It started from T05's
blocker paragraph, which was accurate when written and already fixed by the time
this task began -- blocker prose ages faster than the code it describes.
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
