Skip to content

feat: session-key self-revocation (delegate surrender) #823

@nksazonov

Description

@nksazonov

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 ergonomicsRevokeSessionKey() 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions