DEV Community

imokokok
imokokok

Posted on

A Valid Signature Is Not Yet a Trusted Receipt

#ai #web3

A local verifier returns valid: true for an execution receipt.

That answers a cryptographic question: does the receipt’s signature match the public key supplied to the verifier, and do the signed fields pass the supported checks?

It does not answer a separate identity question: why should the reviewer trust that this key belongs to the expected issuer?

A signature proves control of a private key. The reviewer still needs an independently established link between that key and the issuer they intended to trust.

This is why a key registry included in the same downloaded bundle should be treated as discovery data. If a verifier accepts a receipt’s bundled key as its own trust source, a party could create a new key, sign a fabricated receipt, and satisfy that verifier’s signature check.

The trust configuration should come from a separate, reviewed source. It should identify the expected issuer and key, the deployment audience, and the key’s validity or revocation status.

Here is the shape of a local verification call with priorseal-sdk:

import { verifyReceiptLocally } from 'priorseal-sdk/verifier';

const result = await verifyReceiptLocally(receipt, {
  trustedKeys: independentlyConfirmedKeyRegistry,
  expectedAudience: 'your-deployment-audience',
});

if (!result.valid) {
  throw new Error(`Receipt verification failed: ${result.code}`);
}

console.log({
  verificationScope: result.verificationScope,
  outcome: result.outcome,
  executionStatus: result.executionStatus,
  complianceStatus: result.complianceStatus,
  requiredExternalChecks: result.requiredExternalChecks,
});
Enter fullscreen mode Exit fullscreen mode

The application supplies the receipt, the independently confirmed key registry, and the expected audience. The verifier performs no network requests. It checks signatures and receipt relationships within its supported scope.

The result keeps several claims distinct:

  • valid reports whether verification passed with the supplied trust configuration.
  • outcome reports the execution result recorded in the receipt.
  • complianceStatus reports whether the correlated execution matched the authorization, when assessable.
  • requiredExternalChecks lists checks the offline verifier cannot complete, such as ERC-1271 state or EVM anchor inclusion.

A local result that requires external checks should remain visibly incomplete until those checks are handled. Offline verification does not mean every chain-dependent claim has been independently re-established.

The same principle applies when connecting Insight and PriorSeal. Insight’s oracle assessment and PriorSeal’s authorization and execution receipt keep separate trust roots. A commitment can show that a digest was included in an authorization; it does not make PriorSeal the issuer of Insight’s assessment.

Before displaying one green “Verified” badge, ask what your verifier actually established:

  1. Did the signature match?
  2. Was the signing key trusted independently?
  3. Did the receipt target the expected audience?
  4. Did the verifier finish all required checks?

A signature is a strong piece of evidence. Its meaning depends on the trust configuration around it.

References

Top comments (0)