Background
PR #809 (MF3-M05) added wallet-only revocation of session keys — the owner can now unilaterally revoke without the delegate's cooperation. During review, the question arose whether the session key itself should also be able to initiate revocation.
That change was correctly kept out of the audit fix to preserve scope. This issue tracks the follow-up.
Motivation
Self-revocation is strictly a reduction of authority — a session key surrendering itself can never escalate privilege. This makes it unconditionally safe to allow.
Practical use cases that wallet-only revocation doesn't cover:
- Autonomous agent graceful shutdown — a bot that finishes a job wants to clean up its own delegation without requiring the wallet to come online.
- Compromised key first-response — a leaked session key can self-revoke before the attacker uses it (the attacker cannot delay revocation by refusing to sign).
- SDK ergonomics —
RevokeSessionKey() that works from the session-key side, not just the wallet side. Much more natural for server-to-server integrations.
Industry analogues
| Domain |
Who can revoke? |
| OAuth 2.0 RFC 7009 |
Owner or token holder (token surrender is an explicit recommended pattern) |
| GitHub PATs |
Owner or the key itself (DELETE /applications/{client_id}/grant) |
| Power of Attorney (banking) |
Principal or attorney (attorney can resign independently) |
Proposed logic for the revocation branch
if session_key_sig present and valid → accept (delegate surrenders)
else if user_sig valid → accept (owner forcibly revokes)
else → reject
user_sig remains the escape hatch for lost/unavailable/malicious delegate scenarios. Session-key self-revocation is purely additive.
Implementation notes
- The signed payload already binds
(user_address, session_key, version, expires_at) — no replay across keys, wallets, or versions.
- The worst-case DoS from a stolen key self-revoking: the owner re-registers at
version + 1. Minor inconvenience only.
- Code change is small: the revocation branch in both
channel_v1 and app_session_v1 handlers needs to accept a valid session_key_sig as an alternative to user_sig.
- New SDK helpers:
RevokeChannelSessionKey / RevokeAppSessionKey callable from the session-key side (no wallet needed).
Background
PR #809 (MF3-M05) added wallet-only revocation of session keys — the owner can now unilaterally revoke without the delegate's cooperation. During review, the question arose whether the session key itself should also be able to initiate revocation.
That change was correctly kept out of the audit fix to preserve scope. This issue tracks the follow-up.
Motivation
Self-revocation is strictly a reduction of authority — a session key surrendering itself can never escalate privilege. This makes it unconditionally safe to allow.
Practical use cases that wallet-only revocation doesn't cover:
RevokeSessionKey()that works from the session-key side, not just the wallet side. Much more natural for server-to-server integrations.Industry analogues
DELETE /applications/{client_id}/grant)Proposed logic for the revocation branch
user_sigremains the escape hatch for lost/unavailable/malicious delegate scenarios. Session-key self-revocation is purely additive.Implementation notes
(user_address, session_key, version, expires_at)— no replay across keys, wallets, or versions.version + 1. Minor inconvenience only.channel_v1andapp_session_v1handlers needs to accept a validsession_key_sigas an alternative touser_sig.RevokeChannelSessionKey/RevokeAppSessionKeycallable from the session-key side (no wallet needed).