Delegated Superseding Recovery Rules

[SmithSamuelM]

Cooperative Recovery of Delegated Pre-Rotated Keys

Superseding Recovery

Supersede means that after an event has already been accepted as first seen into a KEL that a different event with the same sequence number is accepted that supersedes the pre-existing event at that sn. This enables the recovery of events signed by compromised keys. The result of superseded recovery is that the KEL is forked at the sn of the superseding event. All events in the superseded branch of the fork still exist but, by virtue of being superseded, are disputed. The set of superseding events in the superseding fork forms the authoritative branch of the KEL. All the already seen superseded events in the superseded fork still remain in the KEL and may be viewed in order of their original acceptance because the database stores all accepted events in order of acceptance and denotes this order using the first seen ordinal number, fn. The fn is not the same as the sn (sequence number). Each event accepted into a KEL has a unique fn but multiple events due to recovery forks may share the same sn.

Superseding Rules for Recovery at given SN (sequence number)

A0. Any rotation event may supersede an interaction event at the same sn. (existing rule) A1. A non-delegated rotation may not supersede another rotation at the same sn. (modified rule) A2. An interaction event may not supersede any event. ( existing rule).

(B. and C. below provide the new rules)

B. A delegated rotation may supersede another delegated rotation at the same sn under either of the following conditions: B1. The superseding rotation's delegating event is later than (sn is higher) the superseded rotation's delegating event in the delegator's KEL.
B2. The sn of the superseding rotation's delegating event is the same as the sn of the superseded rotation's delegating event in the delegator's KEL and the superseding rotation's delegating event is a rotation and the superseded rotation's delegating event is an interaction.

C. IF Neither A nor B is satisfied, then recursively apply rules A. and B. to the delegating events of those delegating events and so on until either A. or B. is satisfied, or the root KEL of the delegation has been reached. C1. If neither A. nor B. is satisfied by recursive application on the delegator's KEL (i.e. the root KEL of the delegation has been reached without satisfaction) then the superseding rotation is discarded. The terminal case of the recursive application will occur at the root KEL which by definition is non-delegated, wherefore either A. or B. must be satisfied, or else the superseding rotation must be discarded.

[blelump]

@SmithSamuelM hey,

is this feature related to the case where you'd like to revoke a QVI? So when the delegator delegates the QVI (delegatee), there's a way to revoke the QVI. In case I am using the wrong terminology, what I am asking is how to revoke a delegatee so that there is a way to remove it, i.e., in case of compromise.

[SmithSamuelM]

@blelump. This is not directly related to revoking a QVI. The authority to be a QVI comes via a QVI credential (ACDC) issued from the External GAR.

The purposes of a delegated AID are:

• more security via threshold structure that is the cooperative delegation tree of delegators and delegates.
• horizontal scaling of signing infrastructure.

There is no way for a delegator of an AID to unilaterally “revoke” that delegated AID. A delegator and delegate can cooperatively decide to abandon a delegated AID by performing a rotation to empty next keys.

KERI delegated identifiers are a different type of delegation from delegated ACDCs. Please do not confuse the two. Although they both manage types of delegable authority the mechanisms they each use serve different purposes.

ACDC delegation = unilateral potentially revocable delegation of specified authority AID delegation = bilateral (cooperative) delegation of unspecified authority

In many applications the best use of a delegated AID is in concert with ACDCs issued to that same delegated AID.

In your specific case where you want to unilaterally revoke authority in the case of compromise, you would need an ACDC in addition to the delegated AID. Then revoking the ACDC revokes the authority.

In the case where the delegate is cooperative and also wants to fix its compromise of keys then it performs a key rotation in cooperation with its delegator. This logic of this issue is to allow the rotation in the event that the delegate not only had compromised signing keys but compromised pre-rotation keys. This is useful when delegation is used for horizontal scaling of signing infrastructure where the signing hosts may have need weaker key management in return for more performant signing infra-structure. This allows recovery in spite of pre-rotation key compromise. Key management is about revoke and replace i.e. rotation. Usually revocation (not rotation) is used for credentials and the entitlement granted by that credential.

QVIs have both for good reason

[blelump]

@SmithSamuelM thanks.

I initially thought of this sophisticated mechanism described in the issue, enabling undoing IXNs, so that it inherently breaks the delegator<->delegatee relationship, thus exposing a mechanism to "revoke" the "trust" to given QVI.

Thinking of QVI revocation, I see cases like bankruptcy/not cooperative/anything else that fits into the "no longer trusted QVI" case.

In the case of revoking a QVI: is this all about eventually revoking ACDCs of QVI's that shall no longer be a QVI? Through TEL, I can find out the ACDC state so that a revoked QVI is discoverable by myself. The delegator<->delegatee relationship may still exist, yet it's broken due to the revoked ACDC.

[SmithSamuelM]

@blelump The role of QVI is solely granted via the ACDC. The additional requirement that the QVI's Issuee AIDs in the ACDC be delegated is about increasing the security of the those AIDs not about granting QVI authority.

[blelump]

@SmithSamuelM, my question is then out of the scope of this issue. Sorry for that. Can you assist with where to look for granting QVI authority? I am missing this piece from a technical perspective.

[SmithSamuelM]

@blelump. The vLEI Ecosystem Governance Framework docs describe in detail how a QVI is granted authority.
https://www.gleif.org/en/vlei/introducing-the-vlei-ecosystem-governance-framework