From the privacy-policy legal review of 2026-08-03: "Complete immediate deletion of session credentials when revocation is observed. The current one-hour residual-access explanation is admirably transparent, but it remains a meaningful security limitation."
Current behaviour: revocation at id.ai takes effect in two steps (policy section 7): anything new stops within ~5 minutes, but an already-issued per-application delegation is reused from the session cache (Session.app_delegations, src/identities.rs) without an Internet Identity round-trip until it expires — up to 1 hour, II's default TTL, because mcp_prepare_delegation is called with max_ttl = null.
Two changes, both already identified in #114's review discussion:
- Pass a short
max_ttl (~5 minutes) to mcp_prepare_delegation so a cached delegation cannot meaningfully outlive revocation. Delegations are cached per (session, origin, account) and re-derived near expiry, so the cost is more derivation round-trips, not user-visible friction.
- Purge on observed revocation: when a call through a delegated identity returns
Unauthorized from Internet Identity or the network, drop the session's cached delegations (and treat the session as ended if the grant itself was revoked) instead of retrying or letting siblings be reused.
When it ships: the privacy policy's section 7 two-step revocation description and the retention table should be updated to the stronger guarantee (both files, plus the submission guides that repeat the ≤1 h window).
From the privacy-policy legal review of 2026-08-03: "Complete immediate deletion of session credentials when revocation is observed. The current one-hour residual-access explanation is admirably transparent, but it remains a meaningful security limitation."
Current behaviour: revocation at id.ai takes effect in two steps (policy section 7): anything new stops within ~5 minutes, but an already-issued per-application delegation is reused from the session cache (
Session.app_delegations,src/identities.rs) without an Internet Identity round-trip until it expires — up to 1 hour, II's default TTL, becausemcp_prepare_delegationis called withmax_ttl = null.Two changes, both already identified in #114's review discussion:
max_ttl(~5 minutes) tomcp_prepare_delegationso a cached delegation cannot meaningfully outlive revocation. Delegations are cached per(session, origin, account)and re-derived near expiry, so the cost is more derivation round-trips, not user-visible friction.Unauthorizedfrom Internet Identity or the network, drop the session's cached delegations (and treat the session as ended if the grant itself was revoked) instead of retrying or letting siblings be reused.When it ships: the privacy policy's section 7 two-step revocation description and the retention table should be updated to the stronger guarantee (both files, plus the submission guides that repeat the ≤1 h window).