-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delegated Superseding Recovery Rules #26
Comments
@SmithSamuelM hey, is this feature related to the case where you'd like to |
@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:
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 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 QVIs have both for good reason |
@SmithSamuelM thanks. I initially thought of this sophisticated mechanism described in the issue, enabling undoing IXNs, so that it inherently breaks the 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 |
@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. |
@SmithSamuelM, my question is then out of the scope of this issue. Sorry for that. Can you assist with where to look for |
@blelump. The vLEI Ecosystem Governance Framework docs describe in detail how a QVI is granted authority. |
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.
The text was updated successfully, but these errors were encountered: