Cross-domain authorization

Understand how authority crosses organizational and trust-domain boundaries through federation, and how public-key signatures enable third-party verifiability without any shared secret between domains.

Track

Engineering

Module

3 · Cryptographic delegation

Prerequisites

Digital signatures · Delegation chains · Signed short-lived credentials

Inside one organization, authority has a shared context: common key stores, common policy, a single root of trust. Across organizations that shared context disappears. Domain B has no reason to trust an identity or token minted inside domain A unless there is an explicit, verifiable basis for it. Cross-domain authorization is the discipline of establishing exactly that basis — a way for B to accept a grant from A, bounded and on B's own terms.

The scalable way to do this is federation built on public-key cryptography. Domain A signs its grants with a private key; domain B is configured to trust A's public key for a specific, limited set of claims. B verifies A's signature with public information alone — no secret has to be shared, no live connection to A is required at verification time. This is what distinguishes federation from the brittle alternative of every pair of domains exchanging and guarding a shared secret.

Federation standards in wide use — SAML and OpenID Connect for identity, and the W3C Decentralized Identifiers / Verifiable Credentials model for issuer-signed claims — all rest on the same primitive: a signed assertion the relying party verifies with the issuer's public key. The relying party holds a trust policy saying which issuers it accepts and for which claims, and resolves issuer public keys through an agreed mechanism (a published metadata/JWKS endpoint, a DID document, or pre-configured keys). Authority crosses the boundary as a verifiable statement, not as access to the issuer's internals.

Trust domain

A boundary within which a common root of trust and policy apply — typically one organization or security realm.

Federation

An arrangement where domains accept each other's signed assertions under an explicit, bounded trust policy, without merging their internal authority systems.

Relying party (verifier)

The domain that consumes and verifies an assertion issued by another domain, deciding locally whether and how to honour it.

Third-party verifiability

The property that anyone holding the issuer's public key can verify a grant — not just a party that shares a secret with the issuer.

Trust policy / trust anchor

The relying party's own configuration of which issuers it trusts, for which claims, under what constraints (audience, scope, freshness).

The relying party never outsources its decision. It verifies the issuer's signature (public key), checks the assertion is addressed to it (audience) and fresh (expiry), confirms the issuer is trusted for these specific claims under its own policy, and then maps the external grant to a bounded local authority. The external issuer asserts; the relying party disposes.

cross-domain acceptance (schematic)
# Domain A issues a signed, audience-bound, short-lived assertion
assertion = sign(A_private_key, {
  iss: "domain-A",
  sub: "agent-A7",
  claims: { role: "report-reader" },
  aud: "domain-B/reports",        # bound to the relying party
  exp: now + 5m
})

# Domain B (relying party) decides on ITS OWN terms, with PUBLIC info only:
def accept(assertion):
    pub = resolve_public_key(assertion.iss)       # A's PUBLIC key, no secret shared
    if not verify_sig(assertion, pub): reject()
    if assertion.aud != "domain-B/reports": reject()   # not for us
    if now > assertion.exp: reject()                    # stale
    if not trust_policy.allows(iss=assertion.iss,
                               claims=assertion.claims): reject()
    # map external claim -> bounded LOCAL authority (B's choice, attenuated)
    return local_capability(read, "B:reports/shared/*", exp=assertion.exp)

Two things make this safe: nothing secret ever crosses the boundary (B only needs A's public key), and B maps the foreign grant to a deliberately narrow local authority rather than treating a trusted issuer as a blank cheque.

1. 1Domains A and B agree a trust policy out of band: which issuer keys B accepts from A, for which claims, with what constraints.
2. 2B obtains A's public key(s) through the agreed mechanism (metadata/JWKS endpoint, DID document, or pre-configuration).
3. 3When an A-side agent needs to act in B, A issues a signed assertion naming the subject, the claims, B as the audience, and a short expiry.
4. 4The agent presents the assertion to B.
5. 5B verifies the signature with A's public key, checks audience, freshness, and that the issuer is trusted for these claims under B's policy.
6. 6B maps the verified external grant onto a bounded local authority (attenuated), and only that local authority is exercised.

synthetic — partner agent reading a shared dataset
# Partner org A's agent needs to read a dataset that org B shares with partners.
# Out-of-band policy at B: trust A's issuer key "A-kid-2026" for claim partner-reader,
# mapped to read on B:datasets/shared/*, max 10m.

assertion = sign(A_key["A-kid-2026"], {
  iss: "org-A", sub: "agentA-42",
  claims: { tier: "partner-reader" },
  aud: "org-B/data", exp: now+10m
})

# B verifies with A's PUBLIC key (fetched from A's published JWKS), checks aud+exp+policy,
# then grants a LOCAL capability: read B:datasets/shared/* for <=10m. Nothing else.
# If A later tried claims:{tier:"admin"} -> B's policy doesn't map admin -> REJECT.
# If the assertion were presented to org-C -> aud mismatch -> REJECT.
# No secret was ever shared between A and B; C could also verify A's signature if needed.

Org A vouches for its agent; org B decides, on its own terms and with only public information, to grant a narrow, time-boxed local authority. The boundary stays clean: A cannot grant itself B-side admin, because B never maps that claim.

Multi-organization agent workflows — a procurement agent in one company calling a supplier's inventory agent, or agents from different vendors collaborating on a task — are inherently cross-domain. Public-key federation lets each organization keep its own root of trust and issue short-lived, audience-bound, attenuated grants that partner domains can verify independently. Crucially, verification needs no shared secret and no live call back to the issuer, so it works even when the issuer is offline and scales as the number of partners grows.

This composes with earlier modules: a cross-domain grant is just a delegation link whose issuer lives in another trust domain, verified end-to-end against a trust anchor; it should be attenuated to a minimal local authority and kept short-lived so stale cross-domain grants expire on their own. Third-party verifiability is also what makes cross-domain audit possible — a regulator or counterparty can later verify who authorized what using only public keys.

• ▸Trust is transitive and only as strong as the weakest federated domain: if you trust A's issuer broadly, a compromise at A becomes your problem. Keep the trust policy narrow and claim-specific.
• ▸Key distribution and rotation is the hard operational core: stale, wrongly-cached, or unverified issuer keys break verification or, worse, accept forgeries. Pin trust anchors and handle rotation deliberately.
• ▸Missing or ignored audience binding lets an assertion meant for one relying party be replayed at another — always enforce aud and fail closed.
• ▸Treating a trusted issuer as a blank cheque re-creates ambient authority across the boundary. Always map foreign grants to a minimal, attenuated local authority, never to broad local power.
• ▸Revocation is even harder across domains than within one; prefer short-lived assertions so cross-domain grants self-expire rather than relying on cross-domain revocation propagation.
• ▸A valid federated grant authorizes; it does not vouch for the remote agent's behaviour or the remote domain's internal security.

Expected direction: Public-key signatures are third-party verifiable: the relying company verifies the partner's signature with the partner's PUBLIC key, so no secret has to be shared or guarded on both sides, it scales to many partners, and verification needs no live call to the issuer. Required checks: (1) the signature verifies against the partner's trusted public key (resolved via an agreed mechanism, key pinned/rotated correctly); (2) the assertion is addressed to this relying party (audience) and is fresh (within expiry); (3) the issuer is trusted for exactly these claims under the relying party's own policy, and the grant is mapped to a minimal attenuated local authority rather than broad power.

Why does public-key federation scale better than pairwise shared secrets?

Because the verifier needs only the issuer's public key and a trust policy — nothing secret crosses the boundary, so you avoid guarding O(n²) shared secrets and the catastrophic leak if one is exposed.

What does "third-party verifiability" mean here?

Anyone holding the issuer's public key can verify a grant, not just a party that shares a secret with the issuer — enabling independent and even offline verification across domains.

Why should a relying party map a foreign grant to a narrow local authority?

To avoid re-creating ambient authority across the boundary: a trusted issuer must not be a blank cheque. The relying party decides on its own terms and grants only the minimal, attenuated authority needed.