Verifying Integrity of KEL and Witness Logs — Any Cryptographic Methods in Signify or KERIA endpoint?

[Kaifmohd]

Hi all,

While working with signify-ts and KERIA, I had a question regarding the integrity of event logs.
Is there any recommended way to cryptographically verify the authenticity and integrity of KEL (Key Event Logs) or witness receipts/logs? Specifically:

Can we detect if any tampering has occurred in the event sequence or witness data?
Are there any built-in methods or endpoints in signify-ts or KERIA that help validate these logs?
Can signatures from controllers and witnesses be verified independently using local cryptographic primitives?
I understand that the KEL structure and SAIDs offer some protection, but I’m looking for a robust verification method to ensure that:
The event chain is cryptographically intact (e.g., digest chaining, proper d field)
Attached signatures (atc, receipts) can be independently verified
Would love to hear how others handle this, or if there are utility methods in the libraries that I might have missed.

Thanks in advance!

[iFergal]

The parser in keripy will process incoming KEL events using the kevery (see here), and make sure they are correctly witnessed etc. KERIA runs this parser.

You need to do it like this because KELs can have forks and they can be malicious - and there are recovery mechanisms for KEL forks. So just cryptographically verifying that a KEL follows correct KERI semantics and is signed correctly isn't enough. And ideally, you would incorporate a pool of watchers to independently do such verifications and check with them, which in turn protects from additional attacks.

After OOBIing with an identifier, you use the keyStates.query() and keyEvents endpoints in Signify, KERIA will return KEL events that have already been verified for you by your agent in the cloud. Again, ideally, watchers should be more integrated into this.

I have however always thought of a Signify edge client communicating with watchers in case your KERIA agent got compromised, but nothing has been done there yet.

[Kaifmohd]

Hey @iFergal , Thankyou for your reply.

So that means when we use keyStates and keyEvents like functions which returns the events or states are already verified on KERIA side using KEVERY?

Also I few questions,

1. How we can create a custom schema. I tried vlEI server. I had created a JSON file. I saidify as mentioned on the vLEI server and got the @id from that but when I trying to resolve OOBI for schema with my AID it is not working.

2. In a scenario where a university (acting as an issuer) creates its AID with 3 witnesses and issues a verifiable credential (VC) to a student, how can the student verify the authenticity of this credential? Additionally, if a third party such as an employer wants to verify the same credential, what is the correct verification flow in signify-ts? Is there a built-in method in signify-ts to verify such credentials?

[iFergal]

@Kaifmohd Yes, but it will just return the last known key states. If there are updates to the KEL of the remote identifier, you should use keyStates.query() to update the state first (and wait for the operation to complete). Once KERIA has watcher integration this will hopefully be more seamless though.

1. Can you show the error? I know there is an issue with the latest vLEI server docker images, which is why I have rolled back to 0.2.0 in my PR, and tagged Kent. It might be related to that (wrong content type).

2. I suggest reading https://github.com/WebOfTrust/keripy/blob/main/ref/tel.md to become familiar with TELs. Normally, IPEX to interactively share the credential and registry events and KERIA will do the verification. This is likely what you want to do - you can see it being used in the credentials integration tests.

Alternatively, you can also just stream the CESR events to the 3902 endpoint and the parser will verify them. Or use /credentials/verify in KERIA to pass one from Signify - though I think the corresponding Signify endpoint is not on the WebOfTrust main - would be easy to add.

[Kaifmohd]

hi @iFergal,

Thank you for clearing my doubts.
->For the issue I faced in the vLEI server, if I am running the docker-compose file as mentioned in the signify-ts, the integration scripts, some of them, like credentials.test.ts, are failing.

https://github.com/WebOfTrust/signify-ts/blob/78d0a694522b4a7ce3c8a77de417d96ed739397f/docker-compose.yaml#L12-L21

So I found a temporary fix. By changing the command path to command: vLEI-server -s ./schema -c ./credentials -o ./oobis

The internal code is trying to find the schema in the /schema/acdc folder. For eg: when running saidify-schema command.

There is not any acdc path inside schema folder here in the above image that the code is looking for.

The above is setup from the default script of docker-compose.yml

trustlistschema.json

The above is the schema that I want to use. When I sadify the above schema I get a @id for that Schema SAID.

But when I am using it like other vLEI schema examples like QVI schema. It give me error while resolving oobi.

For the other thing that I want to mention. (Note this is different issue that I was facing earlier)
Steps to replicate the issue:

1. Just try to docker-compose up the signify-ts repo.
2. Run the credential.test.ts integration file.
3. Observe the Docker containers running - for me the KERIA server is crashed.

And got the below error.

[iFergal]

@Kaifmohd When the saidify the schema, you need to update the @id field in your json file with that value and save it.

I can see trustlistschema.json has an ID of ETrustListCredentialSchema123456789AbCdEf - so probably you need to manually copy it in. I'm not sure on the process as I didn't build the vLEI server.

Regarding running the tests - yes, it needs to be pinned to 0.2.0, or based on your research, have the entrypoint updated on main. I have it pinned on my PRs in review.

Most likely KERIA is crashing because it's not handling the OOBI resolution error properly, so Signify cannot fetch.

[Kaifmohd]

Hey @iFergal,

Do you know about this endpoint /credentials/verify as you mentioned its not there in Signify-ts in Veridian Wallet Documentation its mentioned its in some forked branch. Do you know that repo?

I tried creating my own in credentialing.ts just for testing purposes. But it was not working. At first it return sucess as its a long running operation it is submitted to some queue so we need to do somekind of polling check which I was doing using operations().get(). But I guess its not returning and stuck in the operations loop.

async verify(acdc: object, iss: object, anc?: object): Promise {
const path = '/credentials/verify';
const method = 'POST';
const headers = new Headers({ Accept: 'application/json' });
const body: any = {
acdc: acdc,
iss: iss
};

    // Add anchoring event if provided
    if (anc) {
        body.anc = anc;
    }

    const res = await this.client.fetch(path, method, body, headers);
    const op= await res.json();
    return {
        acdc: new Serder(acdc),
        iss: new Serder(iss),
        anc,
        op,
    };
}

Could you please help here?

[iFergal]

Here is where I added it: cardano-foundation/signify-ts@3cb2dc0 - async verify function.

But to be able to verify a credential, your wallet needs to:

• Have resolved the ACDC schema OOBI
• Have resolved the issuer OOBI
• Be aware of the registries

With IPEX, these are streamed async after IPEX granting to the disclosee. So how you retrieve that info in this setup is use case dependent.

For example, this fork was used in this repo: https://github.com/iFergal/tokenized-acdc-verifier

• On startup, the OOBIs are resolved and the TEL registry is queried: https://github.com/iFergal/tokenized-acdc-verifier/blob/main/packages/server/src/index.ts#L38-L51
• Then we could verify new ACDCs via the API: https://github.com/iFergal/tokenized-acdc-verifier/blob/main/packages/server/src/controllers/credentials.ts#L23-L47

But the main issue is the TEL query (registry querying) functionality for KERIA was incomplete, and I believe it's broken in keripy - these were fixed on the fork but never got merged off the fork: WebOfTrust/keripy#868

I did this for a POC so haven't needed to progress it since, unfortunately. If you have a similar use case, it might be a good exercise to get that keripy PR working again, but it also requires some input from the core maintainers.