Chain of authority: determination of when in clock time an issuance was authorized

[SmithSamuelM]

Dating ACDCs

Credentials (ACDCs) can have issuance dates and their associated anchoring TEL events can have both issuance and revocation dates, so we have the datetimes acnchored to the KEL. This applies to any delegated chainn of authority via a chain of credentials. Therefore any echosystem governance framework can simply state that unless otherwise excepted, by default a credential once issued is always valid unless explicitly revoked even if the chain of authority is broken after the issuance but issuances that happen after the chain of authority is broken are invalid. This can be a provision for any ecosystem that is using the vLEI ecosystem for downstream credentials. Its up to the validator always to decide wether or not to accept a credential, the tooling just performs checks and can report what the checks did. The validator can decide what to do with the result of those checks. The ecosystem governance framework for that organization and those is does business with (i.e. its business ecosystem) could add such provisions.

I2I Operator

The exceptional cases for breaking the I2I chain of authority are best used for last resort situations unless the application is which the authority so imbued has a natural timeliness vis a vis any issuances. Timeliness might be that issuances naturally expire based on a self-contained expiration date. Or for example in the vLEI case breaking a QVI credential chain of authority does not immediately invalidate any vLEI credentials issued by that QVI. There is a built in 90 day grace period. This same approach could be extended to indefinite grace periods for longer term cases like a deed to property. That either means defining what a break in the chain of authority means in the ecosystem governance framework or even defining in the rules section or even the schema section of the credential so that it is self contained.

We could also add a unitary modifier operator that modifies the I2I operator to be something like "pre" that means that issuances that have an issuance date that predates the date of any break in this link of the I2I chain are still valid but any issuances that post date are not. We want to be careful about defining normative edge operators because it will explode the complexity of the protocol and its normative tooling for everyone.

Use Case Example Purchase Order

A possible use case for chained ACDCs is a Purchase Order or PO for short. The Issuer of the PO has a chain of ACDCs that delegate issuing authority to that Issuer using the I2I operator in the edges. We want to be able to determine is a PO was validity issued on the Issuance date on the PO.

There are two options, one when one can trust the Delegating authorities in the chain of trust to not ever back date a revocation of delegated authority to a date before that actual wall clock date of the revocation and the other when one can not trust the delegating authorities to not back date. In many cases the delegating authorities are highly reputable organizations that would suffer severe loss in reputation and influence where they ever to back date, expecially if their ecosystem goverance framework (EGF) forbad and and attached legal liability for doing so. This is the approach GLEIF has taken. But in other cases some members of a chain of trust might be less reputable and so protection against malicious backdating revocation is benefictial

Ascertaining Issued as of Datetime for chain of Trust when chained issuers are trustworthy

Given the PO as an issued datetime field, the question is how to determine later that the chain of trust was unbroken "on" (or before) the issued datetime of the PO. Currently, the TELs for ACDC issuance and revocation include date-times on the states. So, we have an issued datetime and a revoked datetime provided by each TEL for each ACDC in a chain of delegating ACDCs. The validator of the PO needs to merely read the TELS and compare the issued and revoked date-times when present of each of the TELS against the PO datetime. If on the PO-issued date-time, the set of chain-issued date-times are all earlier and the set of chain-revoked date-times, if any, are all later, then the PO was valid on its datetime of issuance. We need a policy to resolve race conditions given network latency, and that can be accomplished by having a time window that rounds revocations to lie outside the window and issuances to lie inside. This time window can be as short as seconds or as long as a day. That would be application-specific.

Since those datetimes (TELs) already exist, the only tooling change would be two configuration parameters passed into the validation code. I suggest a validOn datetime parameter and a resolution window, resolution. The validator then passes in the PO date-time for the validOn datetime with the resolution window appropriate to that application (likely specified by the EGF), The default resolution could be 1 day.

This is the simplest thing we could do in code to modify our current tooling to support answering the issued valid on idate-time question.

Proving Issued as of DateTime for chain of turst when chained issuers are untrustworthy

This is more complicated because we have to enable the Issuee to prove valid as of datetime despite delgators in the chain of trust maliciously backdating revocations. But it actually doesn't require any changes to the existing TELs just simply having the Issuee save the reply's from the validation check performed by the Issuee at issuance. This allows the Issuee to prove duplicity in the event of a backdated revocation. The tooling configuration is the same as above.

1. The PO Issuee needs to validate that the PO was valid at the time of issuance and be protected from a malicious party in the chain of trust from retroactively breaking the trust chain in a way that invalidates that the PO was valid at the time of issuance, namely the issuance datetime on the PO itself. In other words, the Issuee needs to be able to prove to some validator that the PO was validly issued on its issue date. The question of determining if a validly issued PO has expired is another matter entirely that is PO-specific. It might have an expiration date, or it might revocable the day after Issuance. Expiraction or revocation of the PO itself as opposed to invalidation due to chain breaking is immaterial to this discussion of determining if indeed the PO was valid on the date of issuance.

2. We will assume the worst case that every ACDC in the trust chain of the PO Issuer of the can be dynamically revoked via a TEL based revocation registry. The two states of the TEL are Issued and revoked Once revoked, it cannot be reissued. So its strictly monotonic. The issue and revocation state are provided by corresponding events in the TEL, which are anchored in the KEL of each of the Issuers of the delegating ACDCs. So, there is no way for an issued acdc to be revoked by a revocation event using a stale key state. The anchor for the revocation event must appear after the anchoring seal for the issuance event in the KEL of the issuer. This strictly orders the two events.

3. The issuance and revocation events in the TEL also have a datetime. A valid revocation event must also have a later datetime than the issuance event. Therefore, a malicious issuer of a link in the trust (authorization) chain can't issue a valid revocation event that is backdated before its corresponding issuance event. But it could issue and anchor and backdate the revocation any time after the issuance datetime and anchor.

4. We are going to use a day as the time resolution. We could use a different time resolution, like hour or maybe even as little as 10 minutes, given that network latency and clock drift are usually on the order of seconds, not minutes. But to be conservative for business purposes day is a good compromise. The rule is that all date-times are resolved to the day. Something happens on the same day or an earlier day or the next day. If a PO ACDC is such that is issuance day and any revocation in its trust chain (i.e. a chain break) has the same day then we reconcile in favor of the PO Issuee, that is, the PO was validly issued. This resolves any asynchronous network latencies deterministically. In effect, a chain break is ineffective if it occurs on the same day as the issuance. It had to have been broken on the day before. If broken on the day before, the PO Issuance was invalid, If broken on the same day or the day after then the PO issuance was valid

5. All credentials in the chain of trust need to have issuance dates that are earlier or same day as the issuance date in the PO.

6. The validator (issuee) queries the TELs of every credential in its trust chain on the day of Issuance of the PO to verify that on the day of the Issuance the TEL for each ACDC in the trust chain is, as of that day unrevoked. The response to the query is signed by the host controlled by the Issuer with a key controlled by the Issuer. The reply includes the datetime that the reply itself was issued. Its signing key state must be protected by the KEL of the issuer. This could be a the Issuer controller itself, or a witness of the issuer whose key state is bound in the KEL, or it could be a delegated identifier of the Issuer whose keystate is likewise anchored in the KEL of the issuer. There are other mechanisms that we can construct to satisfy this requirement but we have given some easy ones so we don't need to elaborate any more here. Each member of the set of signed replies from the trust chain are non-repudiable to each issuer of each ACDC in the trust chain. That set of replies constitutes an effective state proof that on the day of issuance the chain was unbroked and therefore the PO was valid on its day of issuance. A later revocation that is backdated to an earlier date would be detectably duplicitous by the validator with nonrepudiable proof of duplicity with respect to the set of replies for any third party recourse. Depending on the ecosystem governance framework, this duplicity would be reonciliable duplicity in the favor of the validator (issuee).

7. So now we have a PO that the Issuee (Validator) can prove was valid on the day of its issuance.

Other details about the PO can be layered on top of this but these will be very application even PO specific.

But using this trust chain proof based on a set of non-repudiably signed dated reply messages indicating revocation state, it would be very difficult for a malicious entity in the trust chain to retroactively defeat the issuance proof because at the very least the non-repudiably signed replies provide proof of duplicity of any such attempt.

[SmithSamuelM]

In this discussion was brought up the idea that why not use the sequence numbers of Delegating Issuances in a chain of trust as a way to prove the PO was valid on its day of issuance. There are too complications.

1. One the sequence numbers are not synchronized to clock time in KERI KELs. This could be a time registry. We would have to add an explicit synchronization facility. Essentially without adding such a facility the query reply provides a single point in time synchronization that does not impose any other requirements on the system. It just uses existing fields already in the existing TELs. So it is the minimal code change. But there may be applications where a wall time registry for an Issuer is overall beneficial.

2. A trust chain has sequences numbers from multiple KELs. These KELs are not mutually ordered. This has elements of the classic vector clock ordering problem which is unsolvable. I.e. vector clocks only form partial orders not total orders. So we would have to do something more. And even if we did we still have the problem of synchronizing the vector clock to the wall clock time for the business purpose of a dated PO. Which looks like either 1. immediately above or we just do what the propsed approch above.

[SmithSamuelM]

Vector Clock Pining

The sequence numbers of the issuance events for each ACDC in a chain of delegating ACDCs form the equivalent of a vector clock.

A well known property of vector clocks is that they only form a partial order not a total order. Any two times in a vector clock are orderable with a <= or un-orderable.

For example the two vector clock times [1,2,1] and [1, 3, 1] can be ordered as [1,2,1] < [1, 3, 1] but the two clock times

[1,2,1] and [2,1,1] can't be ordered with respect to each other.

To use a vector clock we have to have some other mechanism to imposes order or that allows us to make decisions deterministically with unorderable times.

One mechanism we can use in this example is what I call sequence number pining (or pegging). In this mechanism A the Issuer's delegating ACDC pins the sequence number of the deletate Issuee's KEL at the time of delegation by including it in the TEL of the Delegating event.

This pin then means that the Issuee may only use the authority vested in it for its own issuances that are anchored after the sequence number in the pin. This prevents the Issuee from effectively backdating issuances before the sequence number of the pin.. This synchronizes the Issuer's and Issuee's KEL times as measured by their sequence numbers.

Where the pin gets really useful is that a revocation event also pins the revocation event to the Issuee KEL's sequence number. This means that the Issuee may not use the authority vested in it by the delegating ACDC with any issuances that are anchored after the KEL time of the revocation pin sequence number.

The two pins specify an allowed range of sequence numbers with respect to the Issuee's (delegate's) KEL during which the delegate has authority. Outside that range the delegate does not have authority.

This prevents an Issuee from backdating an anchored issuance because it's too late once the Issuer pins a SN from the Issuee's KEL, the Issuee cannot exercise its authority falsely by backdating an anchor SN that is outside the range of the pining.

The complication is that the chained delegator revocation pins may happen in real time asynchronously to the delegated issuances that depend on its authority so we then have a race condition. We have to specify deterministic logic to resolve those race conditions.

But a chain of trust can be pinned so that each Issuer as delegator pins the sequence number range during which the issuee as delegate can use their delegated authority.

[SmithSamuelM]

In general, distributed systems have rigid limitations on synchronization resolution due to network latency. Vector clocks were an early attempt to resolve that in a deterministic way which failed. Practical solutions require some monotonic resolution mechanism.

A simple example is a OTP (one time passcode). Most are familiar with this when using an authenticator app. The OTP app provides a passcode that changes every few seconds. The time window of a few seconds is the resolution latency for synchronizing the two generators of the OTP. Each generator starts with the same seed and then uses a verifiable random derivation function to produce a new passcode. Both sides of a OTP have a generator that is seeded with the same random seed. They have to be synchronised in time so that when one side asks for the passcode the other side can produce the same passcode. The time window has to long enough to account for clock drift and network latency and the time it takes to type the passcode. The auth apps will even change the color of the passcode when it is getting close to the end of the window. If one types the passcode too close to the edge fo the window then the other side may have already moved to the next window and the authentication fails becuase a stale code was provided.

For high performance networks the time windows for synchronization can be really small and all that happens if one misses a window is an immediate retry. The retry will be at the start of a window so it will almost always succeed which means the worst case latency is two time windows. This is easy to design for. But expecting that windows can be smaller than some multiple of the average total round trip latency for all the devices that need to be synchronized is a fools errand. The business logic has to account for that fact.

That means one has to decide in the ecosystem goverance framework how to resolve conflicts in whose favor. Which means someone will have it resolved not in their favor. One can prioritize what is more important. An example would be instant revocation which may allow malicious revocation. But the tradeoff is that you trust the revokers more than you trust those being revoked because the revokers have more ncentives to be trustworthy that those being revoked. This was the logic GLEIF used in the vLEI design. It assumes that QVIs won't engage in malicious backdating of revocations. And if that is not sufficient then a given LE can simulataneously use two QVIs so that its either-or logic with two chains of trust. If either is valid then the vlei is valid. That means that even if one of the QVIs is malicious it can't cause harm.

But for example, one conflict reconciliation would be that a retroactive revocation has to have cause. If the delegating revoker can prove that at a point in time (of the KEL) of the delegatee misbehaved, then any actions by the delegatee after that point in time are revocable and the delegatee's expense. This allows the revoker to do instant revocation retroactively and telegraph that to any validators but the revocation can't be before the provable misbehavior so it legally in a technically provable way, disincentivizes maliciouis revocation.

So validating the state of an ACDC in a chain of ACDCs means having a time window large enough that the validation can complete and any changes to the state have to be locked out during that time window. This is no different than the classic semaphone locking and atomic code windows in real time operating systems. Its the same type of problem. The time windows size is always a function of the latency of the distributed process communication about their state.

[pfeairheller]

I believe we need to change the verification code for ACDCs in KERIpy ASAP because what we do now is not adequate. For example, it does not persist a credential if it is revoked upon presentation. I don't believe that is correct behavior, not to mention avoiding persistence if a chain is broken due to revocation. I think that is too heavy handed.

Instead I'd like to propose an update to the verification service that only checks the cryptographic validity of the credential itself, whether an issuance event has "ever" existed and whether the chains actually exist and then persists it and the relevant TEL events at time of admitting, then recurses through the chains. In the event that something like a TEL event or a credential chain node is missing, we escrow and wait for it to show up as we do today, but if all relevant data is available, we persist even if revoked or chains are revoked.

We should then add functionality that specifically reports on credentials status and chain status for already persisted credentials. In this way, we elevate the decision about revocation up to a "business decision" and not integral to the parser.

[pfeairheller]

I created an issue to track this work:

#600