Add externalEvidence to entry metadata

[mrappard]

Adds an optional externalEvidence array to entryMetadata as a more general alternative to the benchmarkingInformation object proposed in #79.

Each item references externally hosted evidence supporting an algorithm's stated capabilities (e.g., benchmark results, audits, certifications). The evidence is provided by the entry owner and is informational only.

Field	Type	Required	Notes
url	string (uri)	yes	Location of the evidence
type	string	yes	Entity-specific namespaced value, e.g. org.example.evidence.benchmark
alg	sha256 | sha384 | sha512	with hash	From the C2PA hash algorithm list
hash	hex string	with alg	Hash of the content at url when the entry was written or last updated

Examples

The schema example now shows four kinds of evidence. All URLs and hashes are placeholders.

"externalEvidence": [
    {
        "url": "https://example.com/softbinding/alg1/benchmark-results.pdf",
        "type": "com.example.evidence.benchmark.report",
        "alg": "sha256",
        "hash": "799d4203122d296792b8005e2ae0dab7757ed9a0083b166bf19e0e400753bd38"
    },
    {
        "url": "https://example.com/softbinding/alg1/robustness.intoto.jsonl",
        "type": "com.example.evidence.attestation.in-toto",
        "alg": "sha384",
        "hash": "7470cab1248a1af9c48f96f6917ac466e5624a06dac8b1efcdde5f33dfccb766c45fd81de0a28173e370c2c65e929190"
    },
    {
        "url": "https://lab.example.org/credentials/alg1-robustness.vc.json",
        "type": "org.example.evidence.credential.vc",
        "alg": "sha256",
        "hash": "d512300b8eba83bfa9a9a0148cd7d1998f7ee81f3ed4bdadbe32d601c5b608fd"
    },
    {
        "url": "https://benchmark.example.org/leaderboards/image-watermarks",
        "type": "org.example.evidence.benchmark.leaderboard"
    }
]

#	Evidence	Published by	Hashed?	Why
1	Benchmark report (PDF)	Entry owner	Yes, sha256	A fixed document, so the hash pins the version that was reviewed
2	Signed in-toto attestation, e.g. a test-result predicate	Entry owner	Yes, sha384	Machine-readable, signed test results; shows any allowed alg can be used
3	W3C Verifiable Credential	Third-party lab (a different domain from the entry owner)	Yes, sha256	Independent assessment signed by the issuer
4	Public leaderboard	Benchmark maintainer	No	Live content that changes over time, so a hash would soon stop matching

The type values use each publisher's own namespace, since no C2PA-defined evidence types exist yet. A follow-up could define a small set of c2pa.* evidence types, following the pattern of c2pa.types.audit-log in the External Reference assertion.

The naming and structure follow existing core spec conventions rather than introducing new ones:

• "Evidence" rather than "validation", since validation has a defined normative meaning in the core spec and this data is not used by validators. It also matches the Process Evidence usage in the External Reference assertion.
• url + alg + hash mirror hashed-ext-uri-map, and the namespaced type mirrors data_types / categories. hash is hex encoded because the list is JSON rather than CBOR.

The schema example is updated. The schema passes jsonschema lint, and softbinding-algorithm-list.json still validates.

A corresponding core spec change will be needed, since SoftBinding.adoc includes this schema.

🤖 Generated with Claude Code

[dcondrey]

Reuses the existing namespace pattern and the hashed-ext-uri shape correctly.

No length check on hash against alg. sha256/384/512 are fixed-length hex (64/96/128 chars) — worth enforcing so a truncated hash doesn't silently pass. Not blocking.

Concretely:

Suggested change

	"hash": {
	"type": "string",
	"pattern": "^[a-fA-F0-9]+$",
	"description": "Hex-encoded hash of the content at `url` at the time the entry was written or last updated, computed with `alg`"
	}
	"hash": {
	"type": "string",
	"pattern": "^([a-fA-F0-9]{64}|[a-fA-F0-9]{96}|[a-fA-F0-9]{128})$",
	"description": "Hex-encoded hash of the content at `url` at the time the entry was written or last updated, computed with `alg`. Length must match sha256 (64), sha384 (96), or sha512 (128) hex characters"
	}

Doesn't tie the length to the specific alg value (that needs an if/then at the item level), but catches a truncated or garbled hash either way.

This overlaps with #79 — both add an informational evidence array to entryMetadata, different shape. Only one should land. This one lets you pin content with a hash; #79 doesn't. Which do you want to keep?

Separately: this is generic evidence (audits, leaderboards, certifications), not robustness measurement, so it doesn't address #61 either — that issue asked for comparable, structured scored results, not a link to an owner-hosted page in arbitrary format. If this and #79 get reconciled, robustness numbers probably want to stay a separate structured field precisely so they're comparable; this shape is fine for everything else (audits, leaderboards, certifications) that isn't trying to be comparable across entries.

[domguinard]

I suggest we first look at iterations from the initial PR related to this topic (https://github.com/c2pa-org/softbinding-algorithm-list/pull/79/changes) and present this alternative as well to the group during the next meeting.

[jcollomosse]

This looks like a duplicate effort of what's trying to be achieved in #79. Since they are both propsoing the same methodology i.e. URL to benchmarks with optional hash, can we discuss them both in one PR?

[mrappard]

I think that we are going to get push back for including benchmarks in the soft binding list.

Specifically because we were told not to include benchmarks in the soft binding list.

This PR is opaque way to link external data, which can include benchmarks and other information (I.E a compromise.)

I'm fine not discussing this or marking it as a draft.

But I feel like it might be best to get approval to place benchmark in the soft bindings list first before we settle on a schema.