Amendment Idea: Delegate auto-expiry by time and/or ledger sequence

[bwif]

title: Delegate auto-expiry
description: Optional time and/or ledger-sequence expiry on a Delegate grant, enforced by the ledger
status: Idea
category: Amendment
requires: XLS-75

Delegate auto-expiry

Abstract

XLS-75 lets an account grant another account a fixed set of permissions, and revoke that grant by sending DelegateSet with an empty Permissions list. Revocation is active only. If the delegator is offline, the key that can revoke is unavailable, or nobody sends the revoke, the grant lasts until someone does.

This idea adds an optional expiry to the Delegate object, by Ripple-epoch time, ledger sequence, or both. Once it passes, the ledger rejects delegated transactions for that grant without a follow-up DelegateSet.

Motivation

Delegation exists so the master key can stay offline while a narrower key does day-to-day work. That only holds if the narrow grant can end without the master key coming back online.

Today it cannot. A compromised delegate, a lost revoke key, or a forgotten grant stays valid indefinitely. Escrow and Checks already bound lifetime on the ledger (FinishAfter / CancelAfter, Expiration). A delegate grant should be able to do the same.

Active revoke stays as it is. Expiry is the case where nobody sends a revoke.

Proposal

Optional fields on DelegateSet, stored on the Delegate object:

• Expiration: last valid Ripple-epoch time. Omitted means no time limit.
• ExpireLedger: last ledger sequence in which the grant is valid. Omitted means no ledger limit.

If both are set, the grant ends when either is reached. A DelegateSet that replaces the permission list may set, change, or clear them. An empty Permissions list still deletes the object immediately.

After expiry:

• A transaction with Delegate set for that pair fails. It must not claim a fee for a grant the ledger has already ended.
• The Delegate object is removed or becomes removable so the reserve is recoverable without the delegator having to notice.
• Expiry cannot be bypassed by deleting and recreating the delegate account. That is the same class of hole V1.1 closed for active revoke.

No new transaction type. This is a new amendment on top of Permission Delegation, not a change to the Final XLS-75 text.

Open questions for discussion

• Auto-delete on the validating path, or leave an expired object that any account can clean up?
• May expiry only be shortened after the grant, not extended?
• Is there a maximum lifetime, or is that the delegator's choice?

[cookiecryptonft-lang]

Fantastic idea - So would the time lock be over ridden by a general Revoke transaction? (Thinking about how Escrow time lock works)

From a use case perspectve the timed revoke allows for an institution to grant temp access to contractors/users etc. Also use cases for Contracts - Timing a revoke to sit alongside a cancellation period. At minimum this represents a way to safeguard against regular/master key loss by user leaving assets exposed to a delegate indefinately. Whilst the logic could likely be achieved of chain, the reliance on this detracts from the delegation being on chain in the first instance.

[mvadari]

• What happens when you update the permissions a Delegate object with an expiry field, before and after expiry?
• I recommend picking one between ledger sequence and time, not supporting both. It's more confusing and given that you can approximate time with ledger sequence and vice versa, not super useful to have both.

[bwif]

On update, DelegateSet stays a full replace, same as it is now.

Before expiry, a non-empty Permissions list swaps in the new permission set and the new expiry together. Leave Expiration off and the expiry is cleared. An empty list still deletes the object immediately.

After expiry the grant is already dead. A delegated transaction fails, and the object is removed so the reserve comes back without anyone having to send a follow-up. A later DelegateSet is a new grant, not a revival, so it does not keep the old expiry.

On time versus ledger index, I agree with picking one for v1.

Time matches how the ledger already bounds objects: Check.Expiration, Offer.Expiration, escrow CancelAfter. I'd ship Expiration only, and add ledger index later if someone actually needs count-of-closes.

[mvadari]

swaps in the new permission set and the new expiry together

What if there's no new expiry in the tx?

A later DelegateSet is a new grant, not a revival, so it does not keep the old expiry.

What if the object still exists and hasn't been deleted?

[bwif]

What if there's no new expiry in the tx?

No new Expiration in the tx: keep the one already on the object. Changing permissions should not clear it. Set Expiration to change it, or 0 to clear it.

What if the object still exists and hasn't been deleted?

If the object is still there after expiry: a delegated transaction fails and does not run as the delegator. A DelegateSet from the delegator still works. An empty list deletes it. A non-empty list is a new grant and replaces the object, so it does not keep the old expiry.