feat: add Google ADK delegated-authority reference profile

[chuks]

Summary

Adds references/, a home for executable integration profiles, and the first profile: proof-carrying delegated authority for Google ADK agents over native Streamable HTTP MCP. No SDK source, SPEC.md normative behavior, or testvectors/v1/ fixture bytes change in this PR.

The profile answers one narrow question. When an ADK agent crosses an MCP or organizational boundary, can the system carrying the consequence independently verify who authorized the agent for that exact action, and which bounds still apply?

Type of change

• Bug fix (no fixture-byte change, no SPEC change)
• Documentation only
• SDK improvement (no fixture-byte change)
• Protocol change (changes signable bytes, scope vocab, or SPEC.md normative behavior) — must have a design-discussion issue linked
• New language SDK — must have a coordination issue linked
• Tooling / CI / build

Adds a new non-SDK references/ tree plus a one-command verification gate. Closest fit to the categories above; flagging explicitly rather than leaving it blank.

Related issues

None. Opening as a draft for review before the profile is linked from the docs site.

What the profile contains

• A two-hop delegation: principal to ADK commander to infrastructure specialist, narrowed to one region and a signed max_nodes ceiling.
• A receiver that runs as a separate process, owns its own trust configuration, and pins both the accepted root and the expected agent out of band. The presenting agent cannot substitute either through tool arguments or request headers.
• A native ADK McpToolset that exposes only the four business arguments to the model. Challenge acquisition and proof injection happen after ADK selects the tool, so private keys and proof bytes never enter model context.
• A deterministic path driven by a scripted model double through the real ADK runner, so the authorization result cannot depend on model judgment.

Verification

./scripts/google-adk-reference-check.sh

The gate builds a disposable virtual environment, installs the exact pinned public packages, refuses to run if ratify-protocol resolves to this repository's local Python SDK rather than the published package, runs the adversarial suite, and runs the demonstration.

Current result: 31 passed, zero skips, zero xfails. Recorded in references/google-adk/evidence/reference-evidence.md.

The suite covers allow plus the following fail-closed cases, each asserting that the protected handler invocation count does not move: excess node count, wrong resource, expiry, revocation, replay, operation altered after challenge issuance, wrong agent, valid chain under an untrusted root, malformed input, unauthenticated transport, pending-capacity saturation, concurrent duplicate request identifiers, and receiver unavailability.

Cross-SDK impact

None. The profile consumes the published Python package through its public API and adds no verifier semantics. The gate asserts that the local sdks/python tree is not on the import path, so this cannot mask an SDK regression.

Scope and non-goals

Recorded in full under Limitations in references/google-adk/README.md. The load-bearing ones:

• The receiver and challenge store are in memory in a single process. State does not survive restart, which fails closed.
• The protected provisioner is a counter. No cloud resources are created.
• Streamable HTTP MCP runs over loopback. No TLS, workload authentication, A2A, Vertex AI Agent Engine, or Agent Identity deployment is exercised or claimed.
• Proof injection uses a small pinned-version McpTool adapter, because ADK does not currently expose operation-specific hidden MCP metadata as a stable public hook. This is isolated and tested, and should be mapped with the ADK maintainers before anyone claims forward compatibility.
• Transport authentication uses a dedicated header rather than MCP authorization, because the presenting client's own credential already owns Authorization. This is deliberate and worth raising upstream.
• One static transport token. Any holder can consume the bounded pending capacity until the TTL expires.
• Protected execution is at-most-once, not exactly-once.

This is an independent draft. It is not a Google partnership, a Google-approved integration, or a Google reference architecture, and references/README.md states that passing tests do not make a profile official for the named platform.

Checklist

• DCO sign-off on every commit (git commit -s). CI rejects PRs without it.
• If protocol behavior changed: not applicable. No signable bytes, scope vocabulary, or normative behavior changed, and no fixtures were regenerated.
• If an SDK was touched: not applicable. No SDK source changed.
• If the threat model changed: docs/EXPLAINED.md updated to describe open reference profiles alongside the managed surface adapters.
• If the public docs reference a new field, method, or scope: no new field, method, or scope. A docs.identities.ai follow-up to link the profile is still open.
• Commit messages use conventional prefixes; first line under 72 chars.
• Commit and PR text written for a public audience.

How to verify

make test-all is unaffected and should be unchanged by this PR. The profile has its own gate:

./scripts/google-adk-reference-check.sh

Worth trying by hand: change max_nodes in references/google-adk/authority_reference/authority.py, or the region bound, and confirm the protected handler invocation count stays flat on every denial. The profile is intended to be easy to falsify.

[chuks]

This draft continues in #63 after renaming the source branch to feat/google-adk-reference. The code and review scope are unchanged.