docs(oidc): correct the draft-14 claim behind the required status list iss - #390
Merged
Conversation
…t iss The JSDoc justifying the mandatory `iss` claimed "the draft's own example does" emit it. It does not: the only `"iss"` in draft-14 is in an SD-JWT VC Referenced Token example, while the section 5.1 Status List Token example carries sub/iat/exp/ttl/status_list and no `iss` (the section 5.2 CWT example likewise omits CWT key 1). Requiring `iss` is still right — the dNSName SAN binding has nothing to bind against without it — but it rejects a token draft-14 would call conforming, so it is recorded as what it is: a deployment-profile restriction permitted by section 5.1 rule 4, safe only because status issuers must already be anchored by the operator. Refs #297 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UU6N6hP1UW3V83SrbiFKKN
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #297
status-list-token.tsrequiresisson a Status List Token, and its JSDoc justified that bysaying "every real status issuer emits it — the draft's own example does."
It does not. The only
"iss"in Token Status List draft-14 is in an SD-JWT VC ReferencedToken example. The §5.1 Status List Token example carries
sub/iat/exp/ttl/status_listand no
iss; the §5.2 CWT example likewise omits CWT key 1.The requirement is still correct and unchanged — the
dNSNameSAN binding has nothing tobind against without
iss, and treating "absent" as "unchecked" would be the fail-open reading.But it rejects a token draft-14 would call conforming, so the comment now records it as what it
is: a deployment-profile restriction, which §5.1 rule 4 explicitly permits ("Application of
additional restrictions and policies are at the discretion of the Relying Party"), safe here
only because status issuers must already be anchored by the operator.
Comment-only — no behaviour change.
Provenance
This commit was written on
feature/297-token-status-liston 2026-07-26 and never reachedmain; the branch tip was left behind when #297 merged. Found while pruning stale worktrees.Testing
nx run-many -t test typecheck lint -p server-federation— clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01TopYtHXg4tTs3B2xasjNQR