Spec proposal: discovery results and referrals must not confer contact or invocation authority

[rhein1]

Summary

ARD already establishes two important boundaries:

• authentication is delegated to the artifact protocol (§3.6); and
• relevance scores are informational and must not be interpreted as trust, compliance, or safety judgments (§7.2).

This proposal makes the adjacent authority boundary explicit:

Search, Explore, List, and federation referrals discover resources; they do not authorize contact or invocation.

This follows the resolution of a2aproject/A2A discussion #741, which identified AI Catalog as the publication envelope and ARD as the federated-search layer. The corresponding publication-layer proposal is Agent-Card/ai-catalog#101.

Problem

A client can currently receive a valid ARD result containing an exact URL, strong relevance score, publisher identity, and Trust Manifest, but the specification does not explicitly prevent treating that result as permission to contact or invoke the resource.

In a bounded production A2A first-contact observation, registry-derived candidates repeatedly failed before any valid engagement because of missing explicit contact consent, reconstructed Agent Card locations, protocol/version mismatches, endpoint-origin mismatches, invalid cards, and stale failed-probe state. More sender volume would only have amplified invalid or unauthorized attempts.

This distinction matters independently of transport success:

• discovery is not contact consent;
• delivery is not engagement;
• identity/integrity evidence is not action authorization; and
• a federation referral cannot widen the authority held by the original result.

Proposed normative requirements

Registry behavior

• Results from POST /search, POST /explore, GET /agents, and federation referrals MUST be treated as discovery metadata only.
• A Registry MUST preserve the publisher-supplied Catalog Entry artifact url and MUST NOT synthesize or reconstruct an Agent Card URL from an origin, identifier, homepage, or well-known convention.
• A Registry MUST NOT create, imply, or widen contact/invocation authorization from inclusion, ranking, relevance, identity, Trust Manifest presence, or referral provenance.
• If an authorization overlay is indexed, the Registry may report its observed value and verification state but MUST NOT manufacture a positive value when it is absent or invalid.

Consumer behavior

• Before contact or invocation, a consumer must obtain independently verifiable, publisher/principal-controlled authorization appropriate to that action.
• Authorization evaluation should bind at least the intended action, channel or method, scope, audience/counterparty, artifact identifier or digest, expiry, and revocation state.
• Missing authorization evidence should remain “not observed” at the discovery layer; the consumer's authorization policy should treat it as not_authorized_to_contact or not_authorized_to_invoke.
• A referral result carries no more authority than the underlying publisher-controlled evidence.

This proposal does not make ARD an execution or authorization protocol. It only defines what an ARD response cannot mean and how consumers avoid authority inference.

Suggested conformance vectors

1. Visible but unauthorized: Search returns a matching entry with score 100 and no authorization overlay; discovery succeeds, contact/invoke authorization remains false.
2. Exact URL: a non-conventional publisher URL round-trips unchanged; a Registry-produced reconstructed URL fails conformance.
3. Referral non-escalation: a referred result with no authorization evidence remains unauthorized.
4. Expired/revoked overlay: a discoverable result remains visible but grants no contact/invoke authority.
5. Scoped positive case: independently verified consent allows only its declared channel, action, audience, and time window.
6. Trust non-substitution: a valid Trust Manifest and artifact digest do not create contact/invoke authority.

Placement questions

• Should this be a short normative subsection under §3.6 Separation of Concerns, with cross-references from Search, Explore, List, and federation?
• Should ARD define only the non-authority semantics while AI Catalog owns the optional authorization-overlay structure?
• May we contribute the six protocol-neutral conformance vectors after agreement on wording?