Does UCAN address root key rotation / recovery, and pre-authorization of one exact invocation?

[miyawakiclaude]

I've been building an offline-verifiable authority layer for agents, and while
writing an honest prior-art page I concluded that its delegation model overlaps
UCAN substantially — monotonic attenuation, deny by default, verification with
no service to ask. That page now says so.

Two things I could not find in the v1.0 specs, and I would rather be told I
missed them than keep claiming they are absent.

1. Continuity above the key.

did:key cannot rotate. If the key named as sub is lost or compromised,
everything delegated under it seems to end with it. I found discussion #95
("Service DID key rotation"), which reads as a question about services rather
than something the spec settles.

Is there an intended pattern for: the root key is gone, and a threshold of
pre-named recovery keys should be able to move the authority to a new root,
with old delegations resolving as superseded rather than simply failing?

Or is that deliberately out of scope — the position being that continuity is
the DID method's problem and UCAN should not have an opinion?

2. Human approval bound to one exact invocation, verifiable offline.

Not "this agent may write to this resource", but "a human approved this
destination and this content hash, once, and the approval is spent when it is
used". Invocation nonce and exp give replay uniqueness, and Receipt is an
executor's attestation after the fact. What I could not find is a pre-approval
that a verifier checks alongside the delegation chain, offline, without a
central authorization server.

Is this something UCAN considers in-band, out of band, or already expressible in
a way I have not seen? Policy predicates on the invocation args look close,
but they constrain the shape of what may be invoked rather than record that a
particular person consented to a particular instance.

---

I am not asking anyone to look at my project, and I am not proposing anything.
These are the two places where my prior-art assessment says "not found", and
"not found by me" is a statement about my search, not about UCAN. I read specs
closely enough to be wrong in specific ways rather than vague ones — the most
recent example is flop-labs/technocore-chat#290, where a conditional-write
handler silently discarded one of its two conditions — so if the answer is
"you missed it, here", that is the answer I am hoping for.

Context, only if useful: https://github.com/miyawakiclaude/lineageauth/blob/main/docs/PRIOR_ART.md