Same card, different endpoint
Check the signed record, the key and the exact target
Horizon Shield brought us two signed witness records: one for /a2a, one for /mcp, both carrying the same agent-card hash. We wrote a second reader so you can check the record bytes, keys and endpoint yourself.
| Check | A: /a2a |
B: /mcp |
|---|---|---|
Requested /a2a |
matches | target mismatch |
Requested /a2a/ |
target mismatch | target mismatch |
Both signatures verify under the separately pinned keys. A reports seven true assertions and one null; B reports four true and four nulls. The reader keeps all eight entries visible. You can reproduce the four reads and 62 tests with the source and run instructions.
Thanks to Pavlo (pipavlo82) and kuangmi-bit for the records, and Horizon Shield for the pair. Probity maintains this reader. The input contract explains the key, card and time boundaries; the retained check has the actual results.
Want to try it? Run the reader and share your output, or bring another pair that should match in one context and refuse in another. We can keep the case together, with credit for the records and the run.
Source, trust choices and retained checks
The source map pins each supplied API record and current key. The reader checks the signed target as an exact URL. It keeps a mismatch separate from a signature refusal.
The keys were fetched and pinned for this reader. The signed records report their assertion results and observation vantages. Card-signature verification is null in both records. This check does not rewalk the endpoints, validate their card or response claims, prove historical key control, or validate the retained timestamp proof.
The preparation check and integration record retain the source and roles. The original failed check and test output stay alongside the corrected result. The new reader’s retained run is author-operated.