Follow-up from @saucam's review of #225.
With the two-clock retention model, the retained issued_credentials population for short-TTL tokens grows from ~90d (Token.MaxTTL cascade clock) to ~400d (audit clock) — roughly 4.4×. The delegation read path has no time bound:
ListByIdentity — no expiry filter, no LIMITGetGraph / expandRootsByIdentity — seed WalkDownMulti with every parent-less JTIMaxGraphNodes trims only after the recursive CTE has run
An identity minting one root credential per session (the Claude Code pattern) will feel this directly as Delegation Explorer latency once ~400d of sessions accumulate.
Proposed: put an issued_at window (or LIMIT) on the root-expansion path so the evidence-retention window doesn't become a graph-query regression. Not urgent — the retention model in #225 is deliberate; this is the read-side companion.
Follow-up from @saucam's review of #225.
With the two-clock retention model, the retained
issued_credentialspopulation for short-TTL tokens grows from ~90d (Token.MaxTTL cascade clock) to ~400d (audit clock) — roughly 4.4×. The delegation read path has no time bound:ListByIdentity— no expiry filter, no LIMITGetGraph/expandRootsByIdentity— seedWalkDownMultiwith every parent-less JTIMaxGraphNodestrims only after the recursive CTE has runAn identity minting one root credential per session (the Claude Code pattern) will feel this directly as Delegation Explorer latency once ~400d of sessions accumulate.
Proposed: put an
issued_atwindow (or LIMIT) on the root-expansion path so the evidence-retention window doesn't become a graph-query regression. Not urgent — the retention model in #225 is deliberate; this is the read-side companion.