Support Timestamping for Signing Operations and Delegated Keys

Problem:

When using a delegated key with a validity period, it may be necessary to selectively provide evidence that the key was used for a signing operation within a valid time window, such as respecting the not-before and expiration-time fields within SIWE and/or JWTs.

Use case example:

As a decentralized social media user, I want to issue W3C Verifiable Credentials that indicate that I have followed someone on the platform or have 'liked' a post using my session key that was created via SIWE delegation.
When I issue the VC, the verifier needs to know that my session key was used correctly to issue the VC, that is, within its validity period.
By being able to demonstrate that the session key operation was bounded between two blockhashes, the verifier can be convinced that the time parameters on the SIWE request were respected, and they are not witnessing a VC created by a stolen session key in the future.

Approach:

Incorporate within the message to be signed a proof of time elapsed, such as a latest public blockchain hash, nonce generated by a witness, or something else that verifiers accept cannot be derived without crossing a certain fixed point in time.
Anchor the signing operation artifact (such as signing output checksum/other derivative) to a data store of some kind with desired data availability characteristics, such as public blockchain (bitcoin network, ethereum network, etc.), distributed cluster (Apache Kafka w/persist destination), or PostgreSQL database.
This allows the signer to prove to a verifier that subscribes to the same trust framework that the signing happened after time A and before time B.

Implementation:

We should support functionality in ssi that is able to leverage aspects of open timestamping standards such as https://opentimestamps.org/ to anchor signing operations to the user's ledger or audit log of choice, even if it's not based on a blockchain (e.g., CloudTrail or QLDB on AWS).

spruceid / ssi