Add AR-PROV: Agent Provisioning Readiness category (discovery → access → commerce → provisioning)

[developer-ainative]

Summary

This PR proposes a sixth category, AR-PROV (Agent Provisioning Readiness), that extends the standard from discovering, accessing, and paying a surface to provisioning a new account on it — an agent, under verifiable authorization from a human, creating and configuring a new account, accepting machine-readable terms, and receiving scoped credentials, without a human completing a form.

It adds: a category definition, conformance requirements AR-PROV-01…10, three conformance levels, a /.well-known/provisioning discovery profile with JSON Schema, four self-describing capability schemas, and a consent/security model. Full text in spec/categories/ar-prov.md.

Motivation — the gap

The current categories take an agent from discovery to payment, but there's an unaddressed step between them:

• AR-AUTH standardizes delegated access to an account a human already has (OAuth/OIDC, RFC 8414/9728, Web Bot Auth).
• AR-COMM standardizes payment (x402, ACP, UCP, MPP).
• Neither standardizes creating the account in the first place.

Today an agent that wants to use a new service on a user's behalf must fall back to driving a human signup form in a browser — brittle, unauditable, and outside the standard. As agent-led commerce moves from demos to production, "provision a new relationship" becomes as load-bearing as "log into an existing one."

The distinction in one line: AR-AUTH = an agent borrows access to an account a human already has; AR-PROV = an agent creates and configures a new account, under verifiable authorization.

What this PR adds

• Category file spec/categories/ar-prov.md (matching existing AR-* formatting and RFC 2119 usage)
• Requirements AR-PROV-01…10, grouped by three conformance levels — L1 Declared, L2 Programmatic, L3 Autonomous — so surfaces can adopt incrementally
• Discovery surface: /.well-known/provisioning profile + JSON Schema (modeled on the ecosystem's /.well-known/ + self-describing-schema convention)
• Capability schemas: terms, account-create, credential-issuance, onboarding, reverse-domain named, transport-bound (REST / MCP / A2A)

How it composes existing standards (no new primitives invented)

• Auth substrate: builds directly on AR-AUTH — OAuth 2.0 + PKCE / OIDC. Provisioning produces the account that later AR-AUTH flows authorize against.
• Consent: verifiable, scoped, expiring Mandates aligned with the W3C Verifiable Credentials data model and the AP2 Mandate pattern.
• Agent identity: Web Bot Auth / A2A agent cards.
• Transport: OpenAPI / MCP / A2A.

Alignment with the project's non-goals

This PR is deliberately consistent with the standard's stated philosophy: it defines conformance only — no tiers, no badges, no readiness grade. A surface either meets AR-PROV-NN at a given level or it does not. Scoring is left entirely to implementers and explicitly out of scope here.

Security & abuse considerations

Provisioning is higher-stakes than discovery or payment (durable accounts + standing credentials), so the proposal includes a security section: Sybil/spam mitigation via Principal-bound Mandates and provider-declared rate limits; least-privilege, revocable credentials; replay/forgery protection (nonce + expiry + signature verification); an auditable Principal → Agent → Mandate → account chain; and graceful, machine-readable step-up (AR-PROV-10) so providers that require human verification can say so in-band rather than failing opaquely.

Reference implementation & maintenance

An open reference implementation (FastAPI provider + MCP transport, with a conformance test suite) is published alongside this proposal, and we're offering to maintain the AR-PROV category going forward. Happy to split this into smaller PRs (category text first, then schemas, then security section) if that's easier to review.

Checklist

• Category text follows existing AR-* formatting and RFC 2119 usage
• JSON Schemas validate
• Requirements mapped to conformance levels
• Security considerations included
• No grading/scoring introduced (consistent with project non-goals)
• Reference implementation linked

---

Filed by AINative Studio. We're also publishing this spec in our own reference namespace so adoption isn't blocked on review cadence — upstream inclusion is the goal, and we'll keep the two in sync.