Programmable Messaging API  ·  View 22 of 22  ·  Assurance

Identity And Authorisation

The tenant, the sender identity, the destination's consent and the carrier credential are four separate proofs.

Editable source SVG draw.io All views
Tenant app Edge Credential service Sender registry Consent store Attempt executor Custody Carrier 1. scoped API credential 2. introspect, check limits 3. tenant, scopes, sender allowlist 4. may this tenant use this sender here? 5. registered in this jurisdiction 6. is this destination still consenting? 7. granted, evidence v9 8. workload identity, no static secret 9. short-lived, single-route token 10. bind with route credential 11. bound, sequence window open 12. revocation effective within 15 s Identity And Authorisation — Four Different Things Prove Themselves The tenant, the sender identity, the destination's consent and the carrier credential are four separate proofs. v 1.0 · owner Integration Platform Architecture

Decisions

  • Authenticating the tenant does not authorise the sender identity, and authorising the sender does not authorise the destination — each is checked separately and recorded separately.
  • Executors hold no long-lived carrier material: workload identity is exchanged for a short-lived, single-route token at the custody boundary.
  • Credential revocation and tenant suspension are data-plane events with a stated propagation bound, not control-plane state somebody reads later.

Assumptions

  • Credential revocation and suspension effective within 15 s; consent, sender and rule changes within 30 s.
  • Per-credential rate limits and per-credential sender restriction, so a leaked key is bounded in blast radius as well as in time.

Risks

  • Four proofs on the submit path is four dependencies inside a 150 ms p95; any one of them becoming slow makes the platform look unavailable.
◀  Trust Zones All views
Solution Architecture v1.0 · Google Cloud · Integration Platform Architecture · 2026-10 · 22 views · 16 architecture decision records22-identity-flow