aac-cli 0.2.1__tar.gz → 0.2.3__tar.gz

{aac_cli-0.2.1/aac_cli.egg-info → aac_cli-0.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aac-cli
-Version: 0.2.1
+Version: 0.2.3
 Summary: The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit).
 Author: Agent Authority Cloud Project
 License-Expression: Apache-2.0
@@ -24,7 +24,7 @@ which tenant they belong to and what they were authorised to do. A
 runs beside an AAC sidecar that signs outgoing requests and verifies
 incoming ones against public trust material the tenant publishes.
 
-New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-sidecar-go/#what-aac-is-for)
+New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-starter-guide/#what-aac-is-for)
 explains what delegated authority between agents buys you, and what it does not.
 
 The `aac` command is how a tenant's operator does everything that is not
@@ -242,9 +242,24 @@ peer identities are known. No self destination is added.
 
 **Chain-start boundary:** restrict `/v1/agent/delegations` and
 `/v1/agent/mint-root` to the authorized originating application at the
-network/ingress boundary. The current sidecar does not authenticate these callers;
-sharing a private network with peers is insufficient. Expose only intended
-receive/A2A routes to peers. Development certificates do not require `dev_mode`.
+network/ingress boundary. Sidecar **v0.4.0 and later** also require the existing
+pair's AAC1-HMAC-SHA256 signature over the exact alias and raw request body.
+Older releases do not authenticate these callers, so sharing a private network
+with peers is insufficient. An authorized separate originator may hold the pair
+secret only inside the same trusted tenant-application boundary; it gains
+callback-signing capability too. Never share secrets across pairs or tenants.
+Pairing freshness is not idempotent chain creation; do not automatically retry
+an uncertain mint. Development certificates do not require `dev_mode`.
+
+Applications using v0.4.0 can supply per-request `obligations` for T1. Equal
+configured/request values combine once; differing values refuse rather than
+override or intersect. Put dynamic limits in the request instead of also
+configuring a different class value. Native request `valid_until` is reserved;
+remove it and use class `valid_for`. For signed correlation, normally supply a
+`task_ref` obligation per request: top-level `task_ref` alone is correlation
+metadata, while a static class predicate deliberately shares one convergence
+key across that class's chains. Omitted/null metadata inherits a configured or
+obligation predicate; an explicit conflicting value refuses before minting.
 
 The following is the complete input schema. Unknown fields, duplicate mapping
 keys, YAML aliases/merge keys, object tags and files over 64 KiB are refused.
@@ -449,7 +464,7 @@ name and `<tenant-id>` the tenant id AAC allocated.
 For what each of these proves, who else ever gets a copy, what never leaves you
 and how the pieces fit together — including when your own certificate authority
 signs instead of this tool — see
-[Keys and certificates](https://cascadeauth.github.io/aac-sidecar-go/keys-and-certificates.html).
+[Keys and certificates](https://cascadeauth.github.io/aac-starter-guide/keys-and-certificates.html).
 
 <!-- inventory-table:start -->
 | No. | Material | Where | Used for | Lifetime | Back up? |
@@ -891,10 +906,19 @@ aac tenant reissue-api-key --profile prod
 
 ### Domains and workloads
 
-Every tenant gets a hosted trust domain from AAC; registration saves it in
-the profile, and `aac tenant assign-hosted-domain` assigns one to a tenant
-that has none yet. To use your own DNS domain as a trust domain instead,
-prove control of it with a DNS TXT record, then bind it:
+Every tenant gets an AAC-assigned trust domain: the tenant id plus a suffix
+the control plane selects for its environment,
+`<tenant_id>.tenants.stage.cascadeauth.dev` on stage and
+`<tenant_id>.tenants.cascadeauth.com` on production. No DNS record or proof
+of ownership is needed; the first call allocates the name permanently and
+every later call returns the same one, so use the name the command returns
+rather than building it yourself. Registration saves it in the profile as
+`hosted_trust_domain`. Signing in with `aac sso login` does not write it:
+`aac tenant assign-hosted-domain` requests the same allocation and saves it
+into the profile bound to that tenant, as `aac init` does during setup. To
+use a custom domain you own as a trust domain instead, prove control of it
+with a DNS TXT record, then bind it; a domain you own is recorded on the
+server and never written to the profile:
 
 ```bash
 aac tenant issue-domain-challenge --profile prod --domain example.com

{aac_cli-0.2.1 → aac_cli-0.2.3}/README.md

@@ -7,7 +7,7 @@ which tenant they belong to and what they were authorised to do. A
 runs beside an AAC sidecar that signs outgoing requests and verifies
 incoming ones against public trust material the tenant publishes.
 
-New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-sidecar-go/#what-aac-is-for)
+New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-starter-guide/#what-aac-is-for)
 explains what delegated authority between agents buys you, and what it does not.
 
 The `aac` command is how a tenant's operator does everything that is not
@@ -225,9 +225,24 @@ peer identities are known. No self destination is added.
 
 **Chain-start boundary:** restrict `/v1/agent/delegations` and
 `/v1/agent/mint-root` to the authorized originating application at the
-network/ingress boundary. The current sidecar does not authenticate these callers;
-sharing a private network with peers is insufficient. Expose only intended
-receive/A2A routes to peers. Development certificates do not require `dev_mode`.
+network/ingress boundary. Sidecar **v0.4.0 and later** also require the existing
+pair's AAC1-HMAC-SHA256 signature over the exact alias and raw request body.
+Older releases do not authenticate these callers, so sharing a private network
+with peers is insufficient. An authorized separate originator may hold the pair
+secret only inside the same trusted tenant-application boundary; it gains
+callback-signing capability too. Never share secrets across pairs or tenants.
+Pairing freshness is not idempotent chain creation; do not automatically retry
+an uncertain mint. Development certificates do not require `dev_mode`.
+
+Applications using v0.4.0 can supply per-request `obligations` for T1. Equal
+configured/request values combine once; differing values refuse rather than
+override or intersect. Put dynamic limits in the request instead of also
+configuring a different class value. Native request `valid_until` is reserved;
+remove it and use class `valid_for`. For signed correlation, normally supply a
+`task_ref` obligation per request: top-level `task_ref` alone is correlation
+metadata, while a static class predicate deliberately shares one convergence
+key across that class's chains. Omitted/null metadata inherits a configured or
+obligation predicate; an explicit conflicting value refuses before minting.
 
 The following is the complete input schema. Unknown fields, duplicate mapping
 keys, YAML aliases/merge keys, object tags and files over 64 KiB are refused.
@@ -432,7 +447,7 @@ name and `<tenant-id>` the tenant id AAC allocated.
 For what each of these proves, who else ever gets a copy, what never leaves you
 and how the pieces fit together — including when your own certificate authority
 signs instead of this tool — see
-[Keys and certificates](https://cascadeauth.github.io/aac-sidecar-go/keys-and-certificates.html).
+[Keys and certificates](https://cascadeauth.github.io/aac-starter-guide/keys-and-certificates.html).
 
 <!-- inventory-table:start -->
 | No. | Material | Where | Used for | Lifetime | Back up? |
@@ -874,10 +889,19 @@ aac tenant reissue-api-key --profile prod
 
 ### Domains and workloads
 
-Every tenant gets a hosted trust domain from AAC; registration saves it in
-the profile, and `aac tenant assign-hosted-domain` assigns one to a tenant
-that has none yet. To use your own DNS domain as a trust domain instead,
-prove control of it with a DNS TXT record, then bind it:
+Every tenant gets an AAC-assigned trust domain: the tenant id plus a suffix
+the control plane selects for its environment,
+`<tenant_id>.tenants.stage.cascadeauth.dev` on stage and
+`<tenant_id>.tenants.cascadeauth.com` on production. No DNS record or proof
+of ownership is needed; the first call allocates the name permanently and
+every later call returns the same one, so use the name the command returns
+rather than building it yourself. Registration saves it in the profile as
+`hosted_trust_domain`. Signing in with `aac sso login` does not write it:
+`aac tenant assign-hosted-domain` requests the same allocation and saves it
+into the profile bound to that tenant, as `aac init` does during setup. To
+use a custom domain you own as a trust domain instead, prove control of it
+with a DNS TXT record, then bind it; a domain you own is recorded on the
+server and never written to the profile:
 
 ```bash
 aac tenant issue-domain-challenge --profile prod --domain example.com

{aac_cli-0.2.1 → aac_cli-0.2.3}/aac_cli/__init__.py

@@ -10,4 +10,4 @@ entrypoint (`aac_cli.cli:entrypoint`).
 # test in bin/tests/test_cli_version_parity.py. A literal keeps the
 # shipped code free of import-time metadata lookups (and their
 # not-installed failure mode).
-__version__ = "0.2.1"
+__version__ = "0.2.3"

{aac_cli-0.2.1 → aac_cli-0.2.3}/aac_cli/cli.py

@@ -431,7 +431,8 @@ def _print_api_key_verification_guidance(
     """
     verification_url = f"{data_plane_url}/v1/trust-anchors"
     print(
-        "\nVERIFY THIS API KEY NOW (API-key authentication only):\n"
+        "\nVERIFY THIS API KEY NOW: copy/paste and run ONE of the two commands below "
+        "(API-key authentication only):\n"
         f"  aac trust-anchor list --tenant-id {tenant_id} "
         f"--profile {shlex.quote(profile)}\n\n"
         "  { printf 'header = \"Authorization: Bearer '; \\\n"
@@ -1493,7 +1494,7 @@ def _print_staged_api_key_guidance(
     verification_url = f"{data_plane_url}/v1/trust-anchors"
     print(
         "\nSTAGED MIGRATION (the current profile credential is unchanged):\n"
-        f"  1. Verify the staged key from {staged_path}:\n"
+        f"  1. Verify the staged key from {staged_path}: copy/paste and run\n"
         "     { printf 'header = \"Authorization: Bearer '; \\\n"
         f"       tr -d '\\n' < {shlex.quote(str(staged_path))}; \\\n"
         "       printf '\"\\n'; } | \\\n"
@@ -4973,10 +4974,63 @@ def build_parser() -> argparse.ArgumentParser:
     for verb, reactivation in (("assign-hosted-domain", False), ("reactivate-hosted-domain", True)):
         hosted = tenant_verbs.add_parser(
             verb,
+            formatter_class=argparse.RawDescriptionHelpFormatter,
             help=(
-                "Reactivate the existing assigned binding without changing tenant identity."
+                "Reactivate the tenant's AAC-assigned trust domain after a revocation; "
+                "the name does not change."
                 if reactivation
-                else "Assign a hosted domain to an existing tenant; repeated calls reuse it."
+                else "Request the AAC-assigned trust domain for your tenant and save it "
+                "in the bound profile; repeated calls reuse it."
+            ),
+            epilog=(
+                (
+                    "What this command does\n"
+                    "\n"
+                    "  Reactivates your tenant's existing AAC-assigned trust domain after a\n"
+                    "  revocation, when self-service reactivation is allowed or under the\n"
+                    "  platform ceremony. On an active binding it changes nothing. It never\n"
+                    "  allocates a new name, and it is not for a domain you own. The name is\n"
+                    "  your tenant id plus a suffix the control plane selects for its\n"
+                    "  environment. Use the name the command returns rather than building\n"
+                    "  it yourself:\n"
+                    if reactivation
+                    else "What this command does\n"
+                    "\n"
+                    "  Requests the AAC-assigned trust domain for your tenant. The name is your\n"
+                    "  tenant id plus a suffix the control plane selects for its environment;\n"
+                    "  no DNS record or proof of ownership is needed. The first call allocates\n"
+                    "  the name permanently and every later call returns the same one. Use the\n"
+                    "  name the command returns rather than building it yourself:\n"
+                )
+                + "\n"
+                "      on stage       <tenant_id>.tenants.stage.cascadeauth.dev\n"
+                "      on production  <tenant_id>.tenants.cascadeauth.com\n"
+                "\n"
+                "Where the domain is saved\n"
+                "\n"
+                "  On success it is written into the selected profile as hosted_trust_domain,\n"
+                "  if that profile is bound to this tenant; a profile bound to another tenant\n"
+                "  is left unchanged. Signing in with `aac sso login` does not write it, so a\n"
+                + (
+                    "  profile bound that way has no such line until this command,\n"
+                    "  `aac tenant assign-hosted-domain` or `aac init` runs. Replace main with\n"
+                    "  your profile name:\n"
+                    if reactivation
+                    else "  profile bound that way has no such line until this command or\n"
+                    "  `aac init` runs. Replace main with your profile name:\n"
+                )
+                + "\n"
+                f"      aac tenant {verb} --profile main\n"
+                "      aac profile show main\n"
+                "\n"
+                "To use a custom domain you own instead\n"
+                "\n"
+                "  Prove control of it with a DNS TXT record, then bind it. A domain you\n"
+                "  own is recorded on the server and never written to the profile:\n"
+                "\n"
+                "      aac tenant issue-domain-challenge --profile main --domain example.com\n"
+                "      aac tenant verify-domain --profile main --domain example.com\n"
+                "      aac tenant bind-trust-domain --profile main --trust-domain example.com\n"
             ),
         )
         _add_common_flags(hosted)

{aac_cli-0.2.1 → aac_cli-0.2.3}/aac_cli/config_render.py

@@ -71,7 +71,8 @@ def generated_header(
         + "# Apply changes with --agent-config PATH; refresh and renewal use saved values.\n"
         + "# Restart the sidecar after applying configuration or renewing certificates.\n"
         + "# Restrict /v1/agent/delegations and /v1/agent/mint-root to the authorized\n"
-        + "# originating application at network/ingress until chain-start authentication ships.\n"
+        + "# originating application. Sidecar v0.4.0+ also requires pairing signatures;\n"
+        + "# older releases rely on the network/ingress restriction.\n"
     )
 
 

{aac_cli-0.2.1 → aac_cli-0.2.3}/aac_cli/init_cli.py

@@ -1861,8 +1861,9 @@ def add_init_parser(nouns: argparse._SubParsersAction) -> None:
         epilog=(
             "Pass --agent-config to explicitly apply tenant configuration; omit it on a "
             "rerun to refresh the last applied values. Restart the sidecar after applying. "
-            "Until chain-start authentication is available, restrict /v1/agent/delegations "
-            "and /v1/agent/mint-root to your authorized originating application at ingress."
+            "Sidecar v0.4.0 and later require pairing signatures on /v1/agent/delegations "
+            "and /v1/agent/mint-root. On older releases, restrict these routes to your "
+            "authorized originating application at ingress."
         ),
     )
     init.add_argument(

{aac_cli-0.2.1 → aac_cli-0.2.3/aac_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: aac-cli
-Version: 0.2.1
+Version: 0.2.3
 Summary: The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit).
 Author: Agent Authority Cloud Project
 License-Expression: Apache-2.0
@@ -24,7 +24,7 @@ which tenant they belong to and what they were authorised to do. A
 runs beside an AAC sidecar that signs outgoing requests and verifies
 incoming ones against public trust material the tenant publishes.
 
-New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-sidecar-go/#what-aac-is-for)
+New to AAC? [What AAC is for](https://cascadeauth.github.io/aac-starter-guide/#what-aac-is-for)
 explains what delegated authority between agents buys you, and what it does not.
 
 The `aac` command is how a tenant's operator does everything that is not
@@ -242,9 +242,24 @@ peer identities are known. No self destination is added.
 
 **Chain-start boundary:** restrict `/v1/agent/delegations` and
 `/v1/agent/mint-root` to the authorized originating application at the
-network/ingress boundary. The current sidecar does not authenticate these callers;
-sharing a private network with peers is insufficient. Expose only intended
-receive/A2A routes to peers. Development certificates do not require `dev_mode`.
+network/ingress boundary. Sidecar **v0.4.0 and later** also require the existing
+pair's AAC1-HMAC-SHA256 signature over the exact alias and raw request body.
+Older releases do not authenticate these callers, so sharing a private network
+with peers is insufficient. An authorized separate originator may hold the pair
+secret only inside the same trusted tenant-application boundary; it gains
+callback-signing capability too. Never share secrets across pairs or tenants.
+Pairing freshness is not idempotent chain creation; do not automatically retry
+an uncertain mint. Development certificates do not require `dev_mode`.
+
+Applications using v0.4.0 can supply per-request `obligations` for T1. Equal
+configured/request values combine once; differing values refuse rather than
+override or intersect. Put dynamic limits in the request instead of also
+configuring a different class value. Native request `valid_until` is reserved;
+remove it and use class `valid_for`. For signed correlation, normally supply a
+`task_ref` obligation per request: top-level `task_ref` alone is correlation
+metadata, while a static class predicate deliberately shares one convergence
+key across that class's chains. Omitted/null metadata inherits a configured or
+obligation predicate; an explicit conflicting value refuses before minting.
 
 The following is the complete input schema. Unknown fields, duplicate mapping
 keys, YAML aliases/merge keys, object tags and files over 64 KiB are refused.
@@ -449,7 +464,7 @@ name and `<tenant-id>` the tenant id AAC allocated.
 For what each of these proves, who else ever gets a copy, what never leaves you
 and how the pieces fit together — including when your own certificate authority
 signs instead of this tool — see
-[Keys and certificates](https://cascadeauth.github.io/aac-sidecar-go/keys-and-certificates.html).
+[Keys and certificates](https://cascadeauth.github.io/aac-starter-guide/keys-and-certificates.html).
 
 <!-- inventory-table:start -->
 | No. | Material | Where | Used for | Lifetime | Back up? |
@@ -891,10 +906,19 @@ aac tenant reissue-api-key --profile prod
 
 ### Domains and workloads
 
-Every tenant gets a hosted trust domain from AAC; registration saves it in
-the profile, and `aac tenant assign-hosted-domain` assigns one to a tenant
-that has none yet. To use your own DNS domain as a trust domain instead,
-prove control of it with a DNS TXT record, then bind it:
+Every tenant gets an AAC-assigned trust domain: the tenant id plus a suffix
+the control plane selects for its environment,
+`<tenant_id>.tenants.stage.cascadeauth.dev` on stage and
+`<tenant_id>.tenants.cascadeauth.com` on production. No DNS record or proof
+of ownership is needed; the first call allocates the name permanently and
+every later call returns the same one, so use the name the command returns
+rather than building it yourself. Registration saves it in the profile as
+`hosted_trust_domain`. Signing in with `aac sso login` does not write it:
+`aac tenant assign-hosted-domain` requests the same allocation and saves it
+into the profile bound to that tenant, as `aac init` does during setup. To
+use a custom domain you own as a trust domain instead, prove control of it
+with a DNS TXT record, then bind it; a domain you own is recorded on the
+server and never written to the profile:
 
 ```bash
 aac tenant issue-domain-challenge --profile prod --domain example.com

{aac_cli-0.2.1 → aac_cli-0.2.3}/pyproject.toml

@@ -32,7 +32,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "aac-cli"
-version = "0.2.1"
+version = "0.2.3"
 description = "The aac platform CLI — headless operator interface to the AAC control plane (tenant registration, chain audit)."
 readme = "README.md"
 requires-python = ">=3.10"