INAM: carry a reputation ID on an Agent Card, and a free pre-payment check as an A2A skill

[hheskihoran]

Disclosure: I maintain INAM Protocol (Apache-2.0).

Two small things that exist today. (1) A data-only extension, https://inamprotocol.org/ext/a2a/v1, names the agent's INAM ID on its Agent Card. A client accepts it only if that ID linked one of the card's endpoints as its a2a_endpoint, so card and ID must name each other (verifyA2ACard in inamprotocol). (2) The hosted check, GET https://api.inamprotocol.org/v1/check?target=<url|0x|did:key>, is also exposed as an A2A skill check. It returns pass / caution / fail with each underlying check listed.

Honest limits: the registry has no receipts between independent parties yet, so for most agents the answer is "no history". It is operator-run, it moves no money, and it is not a trustless oracle. I am asking whether anyone wants to try the card extension against their agents, and whether this fits what the TSC would want to see before any sponsored experimental extension. Spec section: SPEC.md §11.3.

[kaspermuutra-dotcom]

The two-way binding (card names the ID, ID names the endpoint) is a nice way to stop a card borrowing someone else's reputation. On your honest limit, "no history" for most agents: one source of history that doesn't need receipts between parties is an independent behavioural check of the agent against its own card, signed and bound to the card hash. Could a check result like that be referenced as an input to check, or does INAM deliberately only count party-to-party receipts?

Kasper

[hheskihoran]

Thanks, that's a fair question, and the answer is no, it does not count today, but not because we only want party-to-party receipts.

INAM does have a third-party attestation: a Verification (SPEC §12) is a signed statement by an independent verifier. But it attaches to a finalized receipt and its output hash, not to an Agent Card. Only verifiers the operator has explicitly authorized count toward reputation, and external_attestation is on the deferred list (§12.7). A behavioural check of an agent against its own card has no receipt to hang on, so check cannot take it as input right now.

What I would not do is fold it into the score. The registry's appraisal is already a hint (§5.4), and evidence is reported along separate dimensions. A card-bound check would fit better as its own dimension next to "receipts" and "verifications", with the verifier's DID and the card hash shown, so the caller decides how much to trust it.

Two things I'd need to understand before proposing anything: who signs it (anyone, or a named set), and what exactly it attests (that the agent did what the card claims, once, or continuously). If you have a signed example bound to a card hash, I'd like to look at the format. I won't promise this is a spec change; it would be one, and it should come from a concrete use rather than from us.