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.

[iFergal]

@SmithSamuelM Does this mean that there currently is no implemented solution for revocation timeliness for LE, ECR, OOR, OOR-AUTH credentials, or has something since been put in place? e.g. how to avoid invalidating evidence signed by an ECR holder, that is later revoked.

I have also seen the discussion in #597. I think I read that before and mistakingly assumed all vLEI credentials had material timestamps for issue/revoke, which is not the case.

[SmithSamuelM]

One would have to ask GLEIF about datetime stamps in the issuance/revocation TELS for the other types of VLEIs. As I recall, since they the OOR and ECR vLEIs are derived fromt the originating LE vLEI. Revocation of the LE vLEI effectively invalidates the derived vLEIs so the operative datetime for revcation with respect to the grace period is the LE vLEI and not anything for the others.

I agree that if one is worried about invalidating evidence produced by attestations of an ECR holder, that now becomes invalid if the ECR is effectively revoked because the underlying LE vLEI is explicitly revoked, there is cause for concern.

the semantics of vLEIs by themselves are insufficient to guarantee provenance of digital assets. More sophisticated TELs are needed.
I have spent some time working on that problem which is outside the scope of the vLEI. The vLEI is a necessary but not sufficient piece.

The underlying problem is that the issuance/revocation TEL is fully under the control of the Issuer of the associated ACDC (vLEI). So if that Issuer is malicious, they could do things like backdate or forward date or other mischief with respect to any datetimes in the TEL itself.

When one is coming at this from a shared ledger perspective, which enforces a total ordering, it is easy to believe that anchoring datetimes could somehow protect one from this behavior. It does not. The only ordering that the shared distributed consensus enforces is the order of events as they appear in the replicated state log (aka blockchain). So the semantics of datetimes are at best informative.

This means one must implicitly trust the issuer of the datetime.

Cryptographic in this case is merely secure attribution, a given issuance can be securely attributed the source i.e. controller of the private keys that control the attributed identifier. Not in any way the veracity of the information in the issuance, i.e. a datetime etc. Veracity is not cryptographically verifiable only attribution. Vericity has to be verified by other means. If its a physical measurable then some reproduciable measurment process may suffice. If its mathematical then one can do the math so to speak (which is essential balancing accounts). So solving the provenance problem is more difficult than solving the secure attribution problem. Its solvable but not trivially so.

As a policy matter, a VLEI issuance in the first place is a matter of Trust in the administrative operational fidelity and integrity of GLEIF and its assigns (i.e. QVIs). But this trust is reputational (administrative) not cryptographic. It serves to bind an AID to a legal entity but that binding is not cryptographic in nature it is administrative in nature. As you may recall, I clasify roots-of-trust as either cryptographic, algorithmic , or administrative..

In contrast, the authentication of control over the AID provided by the KEL is cryptographic, so the binding triangle between the controller, AID, and key state is cryptographically strong. However, the binding strength between the controller and the legal entity is not cryptographic (it is not part of the original KEL KERI triangle). Reputational bindings are one solution for the cheap pseudonumity problem. The vLEI is a wonderful solution for that.

The binding between legal entity and AID starts with a manual identity assurance process that requires trusting the operational integrity and fidelity of GLEIF/QVI. So, trusting the operational integrity and fidelity of GLEIF/QVI with respect to the datetimes of issuance and revocation in the associated TEL is no weaker than the trust one already places. You can't make the binding between the Legal entity and its AID any stronger, There is no cryptographic mechanism to do so. So its already the best one can do.

You implicitly trust the TEL for reasons stated above. There is no free lunch, and a blockchain anchor of a given binding or its datetime does not strengthen that given binding with respect to any other administrative binding by that same trusted entity.

 One might want to add a duplicity detection capability to the TEL itself, which has merit. But that merit is reputaitonal and so affects whether GLEIF/WVI itself is generally trustworthy, not whether or not a given datetime in a TEL is trustworthy independent of GLEIF/QVI.  So duplicity detection for a TEL is extra infrastructure that does not change the type of the binding i.e administrative vs cryptogrphic. It speaks to whether or not GLIEF/QVI is worthy of trust at all which applies to all its bindings.  And if GLEIF/QVI is not worthy of trust for reputational administrative bindings then there is no value to the vLEI. So the incentive to GLEIF/QVI is to be reputationally trustworthy.

FYI
The datetime in the LE VLEI for the grace period is relative to the moment of revocation as exhiibited by the TEL. It assumes GLEIF is not maliciously changing that datetime.

[iFergal]

I agree that if one is worried about invalidating evidence produced by attestations of an ECR holder, that now becomes invalid if the ECR is effectively revoked because the underlying LE vLEI is explicitly revoked, there is cause for concern.

Thanks Sam; definitely understand the administrative/reputation trust in GLEIF.

I'm considering a more common scenario where the LE vLEI is not revoked, but the ECR credential itself is. For example, the employee may no longer work at the company, or it might have been a temporary service provider, so we revoke the ECR but we want the evidence from the time period to live on.

I understand the complexity of that, so I was just checking if we had a system or design in place yet!

When one is coming at this from a shared ledger perspective, which enforces a total ordering, it is easy to believe that anchoring datetimes could somehow protect one from this behavior. It does not. The only ordering that the shared distributed consensus enforces is the order of events as they appear in the replicated state log (aka blockchain). So the semantics of datetimes are at best informative.

I agree that the solution should not use a shared ledger for the interoperability and latency concerns. But I'm not sure how it wouldn't help protect the behaviour if one did.

For example, you might have a blockchain-specific use case and an ACDC that links to the LE vLEI. Your EFG for your use case could say that the ACDC is only considered issued once it appears on-chain, and is only revoked once the revocation is seen on-chain. And any evidence tied to this ACDC is only valid if it falls between those 2 transactions on-chain.

However, if the QVI or LE credential is revoked - what happens? I'm not sure. Perhaps you could also anchor those revocations as an interim solution, but I know this only works for this situation. Also tagging @m00sey and @kentbull for insights.

I found this discussion because I do actually have what I described above - a blockchain specific use case, that already writes onto the ledger, but now wants to leverage vLEI as an identity layer.

[SmithSamuelM]

Ok, so for evidence issued by an ECR holder that has their ECR revoked to be verifiable after the ECR itself is no longer verifiable, that evidence would have to bound to the state of the ECR when the ECR was valid. So one possible solution as your question surmises is to include a datetime stamp in the issuance/revocation registry for the ECR and then match up datetime stamps of issuances by the ECR holder with respect to evidence. The weakness of this is that a malicious ECR holder could issue evidence attestations after thier ECR was revoked but backdate to before their ECR was revoked. So the provenance of the evidence needs a different type of log, that doesn’t allow new evidence to be attested too by an ECR holder after the ECR is revoked. The log is an evidence log not an issuance/revocation log for the attesters. All that is currently supported is the issuance/revocation log.

As I mentioned above I have spend some time working on that later problem. Maybe its something we can talk offline about.

[SmithSamuelM]

I will give an example. Historically chain-of-custody provenance is only established to the strength of the reputational credibility of the custodians.. If for example a police officer were to at some point in time be discredited due to provable corruption, then every prior criminal conviction in which that police officer asserted chain-of-custody over evidence could be invalidated and need to be re-opened because the chain-of-custody of the associated evidence would now be broken. There is no free lunch here. The advantage of KERI and the vLEI is that one is not attenuating the reputational strength by using KERI and the vLEI for secure attribution over chain-of-custody reputational attestations. But its not changing the underlying trust problem.