coulomb/key-cape
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind online human ID tokens to the exact current access grant
Some checks failed
Authentication acceptance / acceptance (push) Failing after 1m4s
Details
Authentication acceptance / provider-contract (push) Successful in 12s
Details
Build and Publish Container Image / build-and-push (push) Successful in 31s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a14bfc-9643-7872-aa12-98326dcf25e7
This commit is contained in:
tegwick 2026-10-18 12:13:56 +02:00
parent 08c083bae9
commit e2c5a94782
6 changed files with 270 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/current-token-client.md
View file

@ -28,6 +28,13 @@ not establish Windows ACL behavior or a broader platform admission.
## Current status is an authenticated fact
Online human PKCE ID tokens additionally carry the exact access-token `at_hash`
binding described in `online-token-status.md`. This client verifies access-token
facts; a consumer that also uses an ID token separately authenticates that token,
checks its purpose, and joins its signed hash, identity, issuance, assurance and
tenant provenance to the exact access grant. Neither token substitutes for the
other. The online profile's hash is additive; disabled legacy issuance is unchanged.
`OnlineClient.Check(ctx, token, ExpectedIdentity{...})` validates the signature,
issuer, exact single resource audience, subject, tenant, human/service type,
optional authorized-party binding, access-token purpose, unique jti and integer

9
docs/online-token-status.md
View file

@ -31,7 +31,14 @@ status registers `/introspect` and `/revoke`, advertises their implemented clien
authentication methods, and connects the same store to issuance and UserInfo.
Human PKCE and service grants add a cryptographically random `jti` to each access
token. ID-token claims and existing assurance/tenant provenance remain unchanged.
token. Online human PKCE ID tokens add `at_hash`, binding the exact access token
using the RS256 rule in [OIDC Core 3.1.3.6/8](https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken).
The ID token keeps its relying-party audience and omits access-only `jti`/`scope`;
the access token keeps its registered resource audience and omits `at_hash`.
Existing assurance/tenant provenance and the disabled legacy ID-token contract
remain unchanged. Consumers of this online human profile require the exact signed
hash before treating an ID token and access token as one grant; equal identity
facts or issuance seconds alone cannot distinguish separate grants.
Distinct grants in the same second have distinct bearer tokens: a new grant can
never remint a revoked token. A successful response is emitted only after the
token hash, expiry and current registration commitment have been recorded. No