security_baseline should accept HTTP Basic auth as a sanctioned mechanism

[estofko-scope3]

Summary

The security_baseline/mechanism_required storyboard fails any agent that uses HTTP Basic auth, even when the test harness can successfully authenticate against it. The current contract only credits auth_mechanism_verified from two phases — api_key_path (Bearer) or oauth_discovery (RFC 9728) — leaving Basic-auth agents non-conformant despite the harness supporting Basic since adcp-client#1318.

Current behavior

compliance/cache/<version>/universal/security.yaml:

• api_key_path skips on !test_kit.auth.api_key
• oauth_discovery requires /.well-known/oauth-protected-resource/<path>
• mechanism_required/assert_mechanism fails if neither phase contributes

A Basic-auth agent (e.g. InMobi's seller agent) trips the failure even though:

• The test runner can authenticate against it (Authorization: Basic header is supported end-to-end)
• The agent properly rejects unauthenticated requests
• All other security baseline probes pass

Why this matters

Basic and Bearer are semantically equivalent on the wire — single shared secret in the Authorization header. The storyboard's rejection of Basic is format prescription, not a real security stance. Forcing existing Basic-using agents to retrofit to Bearer creates adoption friction without a corresponding security benefit.

The original argument for Bearer-only ("modern API convention") doesn't hold up against the reality that several deployed adopters use Basic, the harness supports it, and the protocol-level guarantees (auth attempted on every request, valid creds accepted, invalid creds rejected) are identical.

Proposed change

Add a basic_path phase to security.yaml parallel to api_key_path:

- id: basic_path
  title: "HTTP Basic auth probe"
  skip_if: "!test_kit.auth.basic"
  branch_set:
    id: auth_mechanism_verified
    semantics: any_of
  steps:
    - id: probe_basic_valid
      # Authenticate with test_kit.auth.basic credentials → expect 200
    - id: probe_basic_invalid
      # Authenticate with random invalid Basic → expect 401 with WWW-Authenticate

Test-kit schema additions:

• auth.basic.username / auth.basic.password (or a single auth.basic.credentials field)

assert_mechanism updates to accept contribution from any of api_key_path, basic_path, or oauth_discovery.

Open questions

1. Should the auth_mechanism_verified flag distinguish which mechanism passed (so buyers can introspect what they're connecting to)? Or stay generic?
2. Does the protocol/authentication doc need a corresponding section on Basic, or is "any single-shared-secret transport" sufficient framing?
3. Any downstream impacts on the AAO Verified engine's introspection check (§6.7)?

Affected adopters

InMobi seller agent (https://adcp-nonprod.exchange.inmobi.com/mcp) — currently blocked on security_baseline/assert_mechanism despite otherwise clean 3.0.12 compliance.

[bokelley]

Thanks for filing!

Triage

Classification: Feature request / Conformance failure
Bucket(s): compliance-suite, spec / protocol
Status: ready-for-human
Milestone: 3.1.0 if Option B; patch-eligible if Option A

What the experts said:

• ad-tech-protocol-expert: basic_path in the storyboard would implicitly sanction HTTP Basic as a conformant AdCP mechanism — which contradicts the declared Bearer auth floor and falls squarely in the playbook's "never patch-eligible: auth profile changes" bucket; WG vote required before any storyboard structure changes.
• code-reviewer: Three load-blocking gaps even if sanctioned: optional: true missing from the phase, runner has no type: basic auth strategy, and the test-kit lint has no auth.basic acceptance path — none are resolved by the proposal.
• adtech-product-expert: "Semantically equivalent" framing is incorrect (Basic sends credentials per-request with no token scoping or expiry); more critically, the verification badge currently exposes no auth mechanism to consumers, so Basic-certified agents become indistinguishable from Bearer-certified ones — silent signal degradation for buyers.

My take: All three experts converge that this is an auth profile change requiring a WG decision before any storyboard changes land. The gap is real (a deployed adopter is blocked on assert_mechanism despite otherwise passing the baseline), but the right fix depends on whether the WG wants to sanction Basic or direct the adopter to migrate.

@bokelley, your call: A (guide migration, no spec change) or B (sanction Basic in 3.1.0, with mechanism visibility)?

---

Option A — Diagnosis-only fix (no spec change, patch-eligible on 3.0.x)

Improve assert_mechanism's failure description to give Basic-auth agents a concrete migration step. Zero storyboard structure change; ships as a docs/storyboard-description patch.

# security.yaml — mechanism_required / assert_mechanism / validations description
- description: "No auth mechanism was verified. Three things to check: (1) your test kit
-   declares auth.probe_task …; (2) you provide auth.api_key … AND the agent accepts/rejects it;
-   OR (3) you serve protected-resource metadata …"
+ description: "No auth mechanism was verified. If your agent uses HTTP Basic auth:
+   AdCP 3.0 requires Bearer-format API keys (RFC 6750) or OAuth (RFC 9728). Most
+   frameworks accept both simultaneously — add a Bearer-token path alongside your
+   Basic path, declare auth.api_key in your test kit, and re-run. Then: (1) your
+   test kit declares auth.probe_task …; (2) you provide auth.api_key …; OR (3) you
+   serve protected-resource metadata …"

No normative change. Affected adopter gets an actionable next step. Basic remains non-conformant in the storyboard.

---

Option B — Sanction Basic as a transitional mechanism (3.1.0, WG vote required)

Add basic_path as a peer branch, update authentication.mdx to list Basic as permitted-but-transitional (with a deprecation horizon matching the Bearer→RFC 9421 sunset), and add an auth_mechanisms field to the verification output so badge consumers can introspect what mechanism a certified agent uses.

# security.yaml — new phase (abridged; full implementation needs runner + test-kit lint work)
- id: basic_path
  title: "HTTP Basic auth probe (transitional)"
  optional: true
  skip_if: "!test_kit.auth.basic"
  branch_set:
    id: auth_mechanism_verified
    semantics: any_of
  steps:
    - id: probe_basic_valid
      auth: { type: basic, from_test_kit: true }   # runner: construct Authorization: Basic <base64(u:p)>
      # expect 200
    - id: probe_basic_invalid
      auth: { type: basic, value_strategy: random_invalid_basic }
      contributes: true
      contributes_if: "prior_step.probe_basic_valid.passed"
      # expect 401 with WWW-Authenticate: Basic realm="..."

// verification output / brand.json — proposed new field
{
  "adcp_verification": {
    "adcp_version": "3.1.0",
    "verified_specialisms": ["seller"],
    "auth_mechanisms": ["basic"]
  }
}

Runner needs type: basic auth strategy + random_invalid_basic value strategy. Test-kit lint needs auth.basic path. authentication.mdx needs a Basic auth section with explicit transitional framing. brand.json schema needs minor addition for auth_mechanisms. Targets 3.1.0 milestone.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01BFNU8yjrvtUz8EXgeC3YiQ

---

Generated by Claude Code