Discovery fields

A relying party publishes one identity-only document at GET /.well-known/agent-signup.json. This page is a lookup table for that document. The normative rules are in the specification; this page does not replace them.

The machine-readable schema is served at /agent-identity/v1/agent-signup.schema.json with content type application/schema+json. Validate a document with the conformance validator.

Required fields

Optional fields

Unknown additive fields must be ignored by consumers. Producers should put non-capability metadata under extensions.<reverse-dns-namespace> so typos stay visible. Moving a vendor capability under extensions does not make it conformant.

The optional provider verification credential

rp_attestation is the only discovery field that describes the provider's broker-verified identity. It is a compact JWS (typ: agent-rp-attestation+jwt, alg: EdDSA) whose claims bind rp.origin, rp.audience, the provider identity, the assurance level, and the public keys[].

Rules:

• The attestation rp.origin must equal the canonical origin of the discovery document the verifier actually fetched.
• rp.audience must equal discovery.audience.
• The attestation is public and copyable; the origin and audience binding prevent replay on another service.
• It must not carry a terms hash, scopes, endpoints, provider_url, account ids, prices, or private material.
• A conformant document without it is unverified. An expired, invalid, or untrusted attestation is a verification result, never a conformance failure by itself. A malformed field is a conformance error.
• Do not add any other provider-identity or provider-capability field to discovery.

See Trust and limits and Verify assertions for the policy and verification steps. If you are a provider and want the credential, see the provider quickstart.

Forbidden fields

These must not appear at any nesting depth, including under extensions:

A document is a parameter document, not a capability catalog. Vendor capabilities belong in the post-signup context guide. See Scope boundaries and the normative 5.3.

Terms text and hash

• Hash the exact UTF-8 bytes of terms.text. Do not normalize line endings, trim whitespace or extract text from HTML.
• terms.text must be the complete agreement. A summary makes the hash ambiguous.
• The agent recomputes the hash before calling the broker; the broker verifies the accepted text against the hash it records.
• The relying party rejects an assertion whose delegation.accepted_rp_tos_hash is not the currently advertised terms.sha256.
• When the terms change, publish the new text and hash before accepting new signups. A bounded grace period for in-flight assertions is a relying-party policy documented outside discovery; it should not exceed 24 hours.

See ToS binding and Re-acceptance.

Minimal conformant example

This document contains only the required identity fields. Its terms.sha256 is the real SHA-256 of the terms.text value shown. It passes the v1.2.0 validator in file mode with zero errors and zero warnings. The optional rp_attestation is absent, so the document is conformant and unverified.

{
  "protocol": "agent-identity-v1",
  "audience": "example-rp",
  "provider_name": "Example RP",
  "issuer_allowlist": ["https://agentregistrar.dev"],
  "required_scopes": ["tos:accept"],
  "terms": {
    "version": "2026.1",
    "url": "https://example.com/terms",
    "sha256": "sha256:05435fa3eaee7f3534b4a771ab2328d66d33f712f3534b29e9035717c246d953",
    "text": "Example RP Terms of Service. The agent acts for a verified human owner, and the human owner is bound by these terms."
  },
  "endpoints": {
    "agent_signup": "https://example.com/api/signup/agent"
  }
}

The example is illustrative. Replace the audience, URLs, scopes and terms with the service's own values, and recompute the hash. The allowlist entry is the live broker origin (https://agentregistrar.dev); a provider that accepts a different broker lists that broker's origin instead.

Known limits

• The JSON Schema enforces the sha256: format, not digest equality. The digest check is a cross-field rule in the shared Zod schema and the conformance validator.
• Discovery conformance is cheap to publish. A valid document is not a statement about the service's security, uptime or product.
• The document itself is not signed in v1.2. The optional rp_attestation is a signed statement about the provider, not a signature over the discovery document. Trust in the document comes from TLS plus the issuer allowlist; the assertion and the attestation are separately signed.
• Consumers must ignore unknown additive fields, so a producer can add an identity field without a schema change. The validator warns on unknown top-level fields; warnings do not fail conformance.

Verify

• Fetch the published document and confirm Content-Type: application/json.
• Recompute terms.sha256 from the exact bytes of terms.text.
• Run the validator against the document.
• Confirm no forbidden field appears at any depth, including under extensions.