Update ERC-7730: add optional integrity field amendment

[llbartekll]

Summary

• introduce an optional top-level integrity object that lets wallets and tooling detect descriptor tampering without changing how descriptors are interpreted
• document canonicalization (RFC 8785), message construction, signature validation for EIP-191/1271 with CAIP-10 signer IDs, JSON schema expectations, and explicit verifier UX handling

[eip-review-bot]

File ERCS/erc-7730.md

Requires 1 more reviewers from @arein, @arikg, @lcastillo-ledger, @paoun-ledger

[github-actions]

The commit 49b8320 (as a parent of 3f759c9) contains errors.
Please inspect the Run Summary for details.

[arein]

It's unclear to me "who" is the correct signer here. Once if've verified the signature to an address - how can I determine that this is the correct author?

My gut feeling tells me this should be out of scope for the initial ERC-7730

[llbartekll]

It's unclear to me "who" is the correct signer here. Once if've verified the signature to an address - how can I determine that this is the correct author?

My gut feeling tells me this should be out of scope for the initial ERC-7730

Signature verification proves key control, not who you should trust.
Determining the “correct author” is a trust and distribution problem and should be out of scope.

[lcastillo-ledger]

An alternative to defining the signature scheme in the ERC 7730 is to define the verifiable credential structure that can carry the integrity data. They have a type specifically dedicate for this (DocumentIntegrityCredential) and that way we can re-use the signature formats, signer identifier (DID spec) and verifier tooling.

[llbartekll]

An alternative to defining the signature scheme in the ERC 7730 is to define the verifiable credential structure that can carry the integrity data. They have a type specifically dedicate for this (DocumentIntegrityCredential) and that way we can re-use the signature formats, signer identifier (DID spec) and verifier tooling.

@lcastillo-ledger VCs/DIDs are useful, but I’d rather not add that stack to 7730. It increases complexity (resolvers, cryptosuites, verifier plumbing) for what should be a lightweight “is this descriptor intact and who signed it?” check. I would keep it minimal.