Abandoning an AID

[SmithSamuelM]

Relationship between Abandonment and Transferability

1. An AID that starts life as a non-transferable AID can’t have anything but an inception event. Its use cases are ephemeral. It’s not a persistent or unbounded term identifier. It has a bounded term. The boundedness is use-case specific. The use case defines how to interpret its ephemerality.

1.1 If the derivation code is a Non-trans code, then the inception event can’t have anything in it besides the one key and a fixed threshold of 1. It can’t have any seals, etc., which means one can infer everything in the inception event from the AID itself. The inception event provides no net information. This means one doesn’t need to ever see the inception event if ts allowed to have one, but it's purely purely perfunctory.

1.2 if the derivation code is transferable then the AID is effectively non-transfereable if and only if the next key digest list in the inception event is empty. This means that no other events are allowed. Its one and done. The advantage of an effective non-trans is that the inception event can have net information in it. For example it can be multisig, it can have seals, it can have witnesses. So there are use cases where you want to create an AID that anchors something but that AID can never but for anything else. The use case may be ephemeral and the anchor is invalidated once that ephemerality is actualized or the use case is a permanent anchor where the AID is tightly bound to the Inception event as a SAID of the inception event. This makes all the cryptographic material, keys, witness IDs, Seals one time use that is strongly bound to the AID. No other use of the keys pairs besides creating the inception event is allowed which means that even if the signing keys are later compromised it doesn't matter since no other event can be created with those signing keys and no other seals can be anchored.So its a totally secure one time issuance AID which issuance is persistent but the AID is effectively non-transferable.

2. An AID that starts life as transferable (i.e. unbounded term) may at some time in the future no longer be needed or may have been compromised in some way that makes it better to abandon it and start over than to try and recover and repair it. In this case, the controller issues a rotation with an empty next-key digest list. This makes the AID effectively non-transferable in much the same sense as an effective non-trans above. It does not start life as effective non-trans so the use cases are different. The rotation event that abandons it can have seals so it can do a last-gasp action of commitments before being abandoned. This could be part of a change of AID, not merely a change of control of AID but a retiring of the AID, and the seals could anchor transactions that designate a replacement AID. Or its reputation has been so badly damaged by compromise that it's not worth the effort to recover, but it's better to abandon it and start over.

Example

Let's say I want to create a watcher that has higher security because it uses multi-sig. However, I will just replace the watcher rather than recover it in the event it has become polluted by first seeing a compromised KEL. I don’t want to have a polluted watcher, so I must abandon it. Now, I could use either an effective non-trans at inception or a trans at inception that becomes non-trans later. It depends on how much effort the recovery is relative to having a clean slate.

Really the main reason to recover control of a compromised (signing keys, witnesses, etc) is because the reputation of the AID is sufficiently valuable that starting over and rebuilding that reputation on a new AID is more costly than rotating the key state. But lets say the reputation is bad not good. Then abandonment makes a lot of sense. (edited)

More Detail

The correct logic is that an AID is abandoned when either the Inception or a subsequent Rotation event rotates to an empty next key digest list (which means the next threshold must also be 0).

When its an inception it makes the AID non-transferable. This means that no other events are allowed after the inception. One can’t anchor anything after the inception. It's one and done. This means that a validator should drop any events it sees after any establishment event that rotates to an empty next key digest list regardless of the signing threshold or anything else in either the abandoning event (inception or rotation) or the subsequent event.

There is a unit test “search for word “abandon” where an interaction event follows a rotation to a null next key digest list and the interaction event raises an error so it is not accepted.

When the abandoning event is the Inception, we could call this a soft abandonment. i.e. is of the same effectively pre-abandoned status as a non-transferable identifier. It's an ephemeral use case, and there is some other information that tells one if one can trust its use at all.

When it's abandoned after the inception via a rotation, we could call this a hard abandonment. It's not ephemeral but abandoned.

To reiterate, the only criteria for abandoning is that the next rotation key digest list is empty. This means that an abandoning establishment event (Inception or Rotation) that specifies an empty next key digest list will not validate unless it's next threshold is 0.

Here is the code in Kever that enforces abandonment.

if not self.ndigers:  # prior next list is empty so rotations not allowed
            raise ValidationError("Attempted rotation for nontransferable"
                                  " prefix = {} for evt = {}."
                                  "".format(self.prefixer.qb64, ked))

if not self.transferable:  # not transferable so no further events allowed
            raise ValidationError("Unexpected event = {} is nontransferable "
                                  " or abandoned state.".format(ked))

The non-transferable condition is true if ndigers is zero or not its transferable.

So when an AID is abandoned, ndigers is zero (empty next key digest list ), so any event after the event that made it nontransferable is not accepted.