Datetime Stamps in TELs, revocation registries for ACDCs issuance and revocation events

[SmithSamuelM]

I wanted to add some clarification or suggestions on how to manage revocation timing.

For GLEIF, which is a reputable entity and must be trusted for the GLEIF ecosystem, the use of a datetime stamp-based
grace period was deemed an acceptable risk. The risk is that the external GAR of GLEIF could maliciously backdate a QVI revocation such that the calculation of the 90-day grace period would be materially affected.

The counter incentives for GLEIF external GAR (EGAR) to act maliciously, in this case, were deemed to be sufficient that the risk level is small enough to be acceptable without a technical solution.

For credentials issued by a QVI the issuance and revocation dates on those credentials in the QVIs TEL are not material. They can be ignored. The activation (revocation state) timing of these credentials is always with respect to the time viewed from the perspective of the verifier at which a verifier checks the TEL for that credential (except for the exception listed above where the 90 day grace period is calculated wrt the QVI's credential revocation date).

With that exception noted, when the TEL state of the vLEI credential is actively issued and not yet revoked at the time of the check by the verifier, then it's issued. If at the time that the verifier checks the TEL the state is revoked, then it is revoked. This is regardless of the date-time stamp on the credential. The datetime stamp on issuance and revocation events for LE, ECR, OOR, OOR-AUTH credentials can be safely ignored by verifiers. It is merely useful.

In general, that should be the design approach the DateTimes on the revocation events in the TEL are problematic in general.
The exception to this is the grace period noted above. After some lengthy discussion, GLEIF (we) decided it was an acceptable risk to use a DateTime-based grace period because of GLEIF's trusted position as the trust anchor (root-of-trust) w.r.t. QVIs.

I would recommend in general, that the date time stamps on the TELs of all other credentials not be material.

Should there arise a need for the DateTime stamp to be material, then one would have to consider whether or not there is enough risk of malicious backdating that a technical solution is necessary as opposed to an incentive solution.

One suggestion for a technical solution is that there be defined a maximum time period between entries to the Issuer's KEL, and if there is no event at the expiration of that time period, then an interaction event that has a seal (hash) of a timestamp be entered in the KEL. This forces a monotonically increasing last event time that provides a moving time window making it provably duplicitous for the issuer to issue a backdate that lies before the time window.