Crowning RAJ: How Resource Access JWTs Refactor Authorization Joyfully

On authority, minimality, and finally stopping the data plane from thinking.

Write the wry skit where Mark Miller is pitching RAJ to a minimal audience of relevant thinkers who stress-test him.

ChatGPT Prompt

Prologue: The Room

A long table. Five chairs.
Coffee that’s gone cold on purpose.

Mark Miller
(Capability-Based Security, ERights)
stands at a whiteboard with exactly one box drawn on it.

Inside the box:

RAJ

No arrows.
No clouds.

Mark Opens (Too Calmly)

Mark:

“I’m not here to propose a new access-control system.
I’m here to remove three.”

A pause. No one smiles.

Lampson: The Minimality Strike

Butler Lampson
(Principles of Computer System Design,
Principle of Least Authority)

Lampson:

“Why does this exist?
What complexity does it eliminate, rather than relocate?”

Mark:

“Authorization currently runs during execution.
I move it before execution, serialize the result,
and replace policy evaluation with a subset check.”

Lampson:

“So the enforcement rule is…?”

Mark (without hesitation):

Request ⊆ Authority

A long silence.
Lampson writes it down.
He does not object.
That’s a win.

Abadi: The Semantic Scalpel

Martín Abadi
(Access Control Logic,
Security Protocol Logic)

Abadi:

“What exactly does a RAJ assert?
Be precise. Is it a statement? A belief? A delegation?”

Mark:

“A RAJ asserts:
According to policy P at time t, this principal is authorized to perform actions A on resources R until t + Δ.”

“It is monotonic.
It does not revoke.
It expires.”

Abadi:

“So revocation is temporal, not logical.”

Mark:

“Yes. I refuse to lie about that.”

Abadi (after a beat):

“That is… honest.”

Brewer: The Distributed Reality Check

Eric Brewer
(CAP Theorem)

Brewer:

“What happens when policy changes mid-flight?
During a partition?”

Mark:

“The same thing that happens when a kernel hands out a
file descriptor.”

Brewer:

“Which is?”

Mark:

“You live with it until it expires.
Availability wins. Freshness is bounded.”

Brewer (nods slowly):

“At least you’re not pretending otherwise.”

Clark: The Layering Alarm

David Clark
(End-to-End Principle,
Internet Architecture)

Clark:

“Why is this not just another violation of the end-to-end principle?”

Mark:

“Because reasoning happens above the data plane,
and enforcement happens below it.”

“The wire sees only a capability.
No policy. No identity. No context.”

Clark:

“And the data plane cannot ask ‘why’?”

Mark:

“Correct. It only asks ‘does this fit?’”

Clark:

“…That’s the right layer.”

Ozzie: The Federation Test

Ray Ozzie
(Distributed Systems,
Federation in Computing)

Ozzie:

“Who do I have to trust?”

Mark:

“Only the authority that issued the RAJ.”

Ozzie:

“And if I don’t?”

Mark:

“Then you don’t accept it.
Federation is optional. Trust is directional.”

Ozzie (smiling now):

“So authority becomes explicit instead of ambient.”

Mark:

“Yes. Ambient authority is a bug.”

The Moment It Clicks

No one speaks.
Mark does not fill the silence.

Lampson (quietly):

“So IAM is just… a RAJ factory with a terrible interface.”

Abadi:

“And signed URLs are degenerate RAJs with no reuse.”
(Amazon S3 Presigned URLs)

Brewer:

“And most outages are policy engines in hot paths.”

Clark:

“And enforcement finally becomes boring.”

Ozzie:

“This composes.”

Mark caps the marker.

Epilogue: The Title Earned

Mark:

“I didn’t invent a new control system.
I stopped asking the data plane to think.”

A beat.

Mark:

“That’s all.”

No applause.
Three people are already rewriting old papers in their heads.

Curtain

On the whiteboard, someone has added a second line under RAJ:

Authorization, refactored.

Fade out.

Appendix I: RAJA

Resource Access JWT Authority

RAJA is the minimal control-plane service required to make RAJ real.

It does exactly one thing:

Compile authorization decisions into enforceable authority.

Nothing more.

I.1 What RAJA Is

RAJA is:

  • an authorization compiler
  • an authority issuer
  • a policy decision boundary

Concretely, RAJA:

  1. Authenticates a principal
  • Validates an identity token (typically an IdP-issued JWT)
  • Extracts stable principal identity and attributes (e.g., iss, sub, groups)
  1. Evaluates authorization
  1. Issues authority
  • If allowed, mints a RAJ (Resource Access JWT)
  • Signs it using standard JWS
  • Sets scope and expiration

RAJA does not:

  • proxy data
  • store resources
  • enforce access
  • manage identities
  • evaluate policy at request time

I.2 What RAJA Is Not

RAJA is not:

  • an Identity Provider (IdP)
    (see OpenID Connect)
  • an IAM replacement
    (cf. AWS IAM)
  • a session manager
  • a proxy
  • a metadata catalog
  • a governance UI

It is intentionally boring.

Its power comes from what it refuses to do.

I.3 Inputs and Outputs

Input to RAJA

  • Identity JWT
  • Requested action(s)
  • Requested resource(s)
  • Context (optional but critical)

Output from RAJA

  • A RAJ:
  • cryptographically signed
  • resource-scoped
  • action-scoped
  • time-bounded
  • self-verifying

RAJ is a capability in the sense of
Capability-Based Security.

I.4 RAJA and Policy Engines

RAJA is policy-engine agnostic.

It treats policy engines as advisors, not authorities.

Typical integration:

Other viable policy decision points (PDPs):

The invariant is:

Policy decides. RAJA asserts. Enforcement obeys.

This mirrors classic separations between:

  • policy decision points (PDPs) and
  • policy enforcement points (PEPs)
    (XACML terminology).

I.5 RAJA and Enforcement Planes

RAJA never appears in the data path.

Enforcement planes (e.g., MinIO, databases, compute runtimes):

  • validate the RAJ locally (signature + expiry)
  • check that a request is a subset of granted authority
  • execute or deny

They never:

  • call RAJA
  • call a policy engine
  • ask “why”

This follows the end-to-end principle
(https://en.wikipedia.org/wiki/End-to-end_principle):

  • reasoning at the edges
  • enforcement in the core

I.6 Failure and Revocation Model

RAJA is explicit about tradeoffs:

  • Revocation is time-based
  • Authority expires; it is not revoked mid-flight
  • This favors:
  • availability
  • simplicity
  • honesty

This mirrors long-standing system behavior such as:

If immediate revocation is required:

  • shorten TTLs
  • rotate signing keys
  • change policy epochs

RAJA does not pretend to offer magic.

I.7 Why RAJA Exists at All

Without RAJA:

  • policy lives in hot paths
  • enforcement engines must think
  • authority is ambient and implicit
  • audits are post-hoc and speculative

With RAJA:

  • authorization becomes a compile step
  • enforcement becomes mechanical
  • authority becomes explicit
  • systems become explainable

This is a direct application of authorization compilation:

  • policy → capability
  • decision → artifact
  • reasoning → enforcement invariant

I.8 The One-Line Definition

RAJA is the service that turns “allowed” into something executable.

Everything else is commentary.

Appendix II: Why This Wins

This appendix explains why RAJA + RAJ is not just cleaner, but structurally superior to prior authorization models.

Not faster in microbenchmarks.
Not prettier in diagrams.

Superior because it changes where complexity is allowed to live.

II.1 It Moves Reasoning Out of the Hot Path

Traditional systems evaluate authorization during execution:

  • every request
  • every multipart part
  • every retry
  • every range read

This puts:

  • policy engines
  • identity resolution
  • context assembly

…directly in the data plane.

RAJA refactors this by introducing authorization compilation:

policy → decision → authority artifact → execution

At runtime, enforcement reduces to:

request ⊆ authority

That is a constant-time, local check.

This mirrors well-known system evolutions:

II.2 It Eliminates Ambient Authority

Most cloud systems rely on ambient authority:

  • IAM roles
  • long-lived sessions
  • implicit permissions bound to identity

Ambient authority is dangerous because:

  • it is invisible at execution time
  • it is hard to reason about
  • it expands silently

RAJs make authority:

  • explicit
  • inspectable
  • bounded
  • portable

This aligns directly with
Capability-Based Security:

Authority should be carried explicitly, not inferred from identity.

II.3 It Is Honest About Revocation

Many systems pretend to offer instantaneous revocation while quietly failing under partitions, caches, and retries.

RAJA does not pretend.

It adopts a time-bounded authority model:

  • authority expires
  • revocation is temporal, not magical

This is the same honesty embraced by:

This is not a weakness.
It is an explicit tradeoff in favor of availability and predictability
(CAP Theorem).

II.4 It Restores Proper Layering

RAJA enforces a clean separation:

This respects the
End-to-End Principle:

  • reasoning at the edges
  • mechanics in the core

Systems become simpler because each layer is allowed to be stupid in the right way.

II.5 It Scales Across Services, Not Just S3

Because RAJs are:

  • resource-scoped
  • action-scoped
  • service-agnostic

…the same authority model applies to:

  • object storage
  • databases
  • query engines
  • ML training jobs
  • workflow execution

Anywhere today where IAM roles are over-granted “just to make it work,” RAJs fit better.

This is why the pattern generalizes beyond:

Those are special cases.
RAJ is the general case.

II.6 It Makes Enforcement Boring (On Purpose)

When a system reaches maturity, the core becomes dull.

RAJA’s final enforcement rule is intentionally uninteresting:

Validate signature → check expiry → subset match → execute

That boredom is the victory condition.

It means:

  • fewer bugs
  • fewer outages
  • fewer surprising interactions
  • fewer midnight pages

This is the same arc followed by:

  • kernels
  • networks
  • databases
  • schedulers

Complexity belongs at design time, not execution time.

II.7 It Explains the Past Without Mocking It

RAJA does not invalidate earlier systems.
It contextualizes them.

  • IAM → standing authority
  • STS → coarse-grained envelopes
  • presigned URLs → single-request capabilities
  • proxies → misplaced policy enforcement

They were all steps along the way.

RAJA is simply the point where the system finally says:

“Authority is a thing. Let’s name it.”

II.8 The Quiet Winning Property

The final reason this wins is subtle:

It feels smaller than what came before.

One service.
One artifact.
One enforcement invariant.

When an idea collapses complexity instead of adding features,
it has usually reached the right level.

II.9 The One-Line Summary

RAJA wins because it turns authorization from a runtime concern into a compiled, explicit, enforceable artifact.

Everything else follows from that.

Appendix III: Rational S3 Access with AVP / Cedar

This appendix explains why AWS Verified Permissions (AVP) and its policy language Cedar are the right policy engine for RAJA, and how the combination produces rational S3 access—that is, access that is explainable, minimal, and composable.

III.1 What “Rational” Means Here

By rational, we mean:

  • access decisions are explicit
  • decisions are explainable
  • the same inputs always yield the same outputs
  • authorization logic is separable from execution
  • enforcement does not depend on hidden state

This is not a UI claim.
It is a systems property.

III.2 The Core Problem with Traditional S3 Authorization

Amazon S3 authorization today is governed by a mixture of:

These mechanisms suffer from three structural issues:

  1. Policy is evaluated in the hot path
  2. Authority is ambient, not explicit
  3. Decisions are hard to explain after the fact

The result is access that works, but is not rational.

III.3 What AVP / Cedar Actually Is

AWS Verified Permissions (AVP) is a managed policy evaluation service built on Cedar, a purpose-built authorization language.

Cedar is intentionally:

  • declarative
  • deterministic
  • non–Turing complete
  • side-effect free

A Cedar policy answers exactly one question:

Given a principal, an action, a resource, and context — is this allowed?

In access-control terms, Cedar functions as a classic
Policy Decision Point (PDP).

III.4 Why Cedar Is Well-Suited to RAJA

Cedar’s properties align precisely with RAJA’s needs:

  • Determinism
    → the same request always yields the same RAJ
  • Explainability
    → decisions can be logged, audited, and reasoned about later
  • Safety
    → no loops, no side effects, no hidden state
  • Separation of concerns
    → Cedar decides whether; RAJA asserts that

Cedar is not asked to:

  • stream bytes
  • understand multipart uploads
  • reason about retries
  • run per request

It does one thing well: decide.

III.5 How RAJA Uses Cedar (Mechanically)

The interaction between RAJA and Cedar is deliberately simple.

  1. Input normalization
  • RAJA authenticates an identity token (typically an OIDC JWT)
  • Normalizes:
    • principal
    • requested action(s)
    • requested resource(s)
    • contextual attributes (purpose, realm, environment)
  1. Policy evaluation
  • RAJA submits this tuple to AVP / Cedar
  • Cedar returns:
    • ALLOW or DENY
    • optional explanation or decision trace
  1. Authority issuance
  • If ALLOW, RAJA mints a RAJ
  • The RAJ encodes:
    • allowed actions
    • resource scope
    • expiration
    • a decision identifier

After this point, Cedar is no longer involved.

III.6 Why Cedar Must Not Be in the Data Plane

Placing Cedar (or any PDP) directly in the S3 request path would:

  • reintroduce latency
  • reintroduce tight coupling
  • reintroduce failure modes
  • negate the benefits of RAJ entirely

RAJA enforces a strict rule:

Policy engines decide once. Enforcement engines never decide.

This mirrors long-established system separations such as:

III.7 Rational S3 Access: The Resulting Model

With RAJA + Cedar, S3 access becomes:

  1. Explicit
    Authority is a concrete artifact (the RAJ)
  2. Minimal
    Only the required actions and resources are granted
  3. Composable
    One RAJ governs many requests, retries, and multipart flows
  4. Auditable
    Every RAJ corresponds to a specific policy decision
  5. Boring to enforce
    Enforcement is a subset check, not a policy debate

This is what rational access looks like.

III.8 Why This Is Better Than “Smarter Buckets”

Many alternatives try to make S3 itself smarter:

  • richer access points
  • more bucket-level semantics
  • more per-request evaluation

RAJA takes the opposite approach:

Make the bucket dumb. Make authority explicit.

That inversion is the breakthrough.

III.9 The One-Sentence Summary

AVP / Cedar decides whether access should exist; RAJA turns that decision into authority; S3 (via a proxy) simply checks that authority and serves bytes.

That is rational S3 access.

Appendix IV: Redefining S3 Permissioning with Envoy + RAJ

This appendix explains how Envoy Proxy combined with RAJs (Resource Access JWTs) can redefine Amazon S3 permissioning without modifying S3 itself. The result is a clean control-plane / data-plane split for object storage authorization, analogous to what Envoy enabled for service-to-service networking and service meshes.

The goal is not to make S3 smarter.
It is to make authority explicit so S3 doesn’t have to think.

IV.1 The Core Insight

The Amazon S3 API is fundamentally HTTP-based. While S3 authorization today is deeply intertwined with IAM and request signing (AWS SigV4), nothing in the protocol requires authorization to be evaluated at request time.

Envoy exploits this separation.

Envoy was designed as a high-performance Layer-7 proxy that:

This makes Envoy a natural authorization enforcement plane for S3 traffic.

IV.2 What Envoy Does (and Does Not Do)

Envoy does:

Envoy does not:

  • understand S3 semantics
  • evaluate IAM policies
  • manage identities
  • reason about multipart workflows

This limitation is a feature, not a flaw.

Envoy treats S3 as just another HTTP backend and leaves all reasoning upstream.

IV.3 The Role of RAJ

A RAJ (Resource Access JWT) is a signed, time-bounded authorization capability issued by RAJA after a policy decision (for example using Cedar via AWS Verified Permissions).

A RAJ encodes:

  • allowed S3 actions (e.g., GetObject, PutObject)
  • allowed resource patterns (bucket and key prefixes)
  • expiration (exp)
  • decision metadata for auditability

The RAJ is presented by the client on every S3 request (typically as an HTTP header).

Envoy’s responsibility is not to decide access, but to verify:

Is this request a subset of the authority asserted by the RAJ?

This mirrors classic enforcement rules from capability systems.

IV.4 Envoy as the S3 Authorization Enforcement Plane

Envoy enforces RAJs using standard, existing mechanisms:

  1. JWT validation
    Envoy validates the RAJ’s signature and expiration locally using a trusted JWKS endpoint.
  2. Request matching
    Envoy matches the HTTP method, request path, and headers against constraints derived from the RAJ’s declared authority.
  3. Allow or deny
  • If request ⊆ authority, Envoy forwards the request to Amazon S3
  • Otherwise, Envoy rejects the request immediately

There are:

  • no calls to RAJA,
  • no policy evaluation,
  • no IAM lookups.

Authorization has already been compiled.

IV.5 Multipart Uploads and Long-Lived Workflows

Multipart uploads expose the limits of request-scoped authorization. They involve:

  • multiple independent requests,
  • retries,
  • partial failures,
  • long-lived workflows.

With RAJs:

  • a single authority governs the entire multipart lifecycle,
  • Envoy enforces consistency across CreateMultipartUpload, UploadPart, and CompleteMultipartUpload,
  • no re-authorization is required per request.

This mirrors operating-system patterns such as open → read/write → close using file descriptors.

Presigned URLs (cannot express this lifecycle.
RAJs can.

IV.6 Why Envoy Must Never Call RAJA

A critical invariant of this architecture:

The data plane must never call the control plane.

If Envoy were to call RAJA or a policy engine on each request:

  • latency would increase,
  • availability would decrease,
  • failures would cascade,
  • authorization would re-enter the hot path.

Instead:

  • RAJA decides once,
  • RAJ carries authority,
  • Envoy enforces mechanically.

This mirrors long-standing system separations such as compilers vs runtime execution and query planners vs executors.

IV.7 Why This Redefines S3 Permissioning

Traditional S3 permissioning assumes:

  • identity implies authority,
  • policy must be evaluated per request,
  • storage must reason about access.

Envoy + RAJ inverts these assumptions:

  • Authority is explicit
  • Policy is compiled
  • Enforcement is mechanical
  • Storage is policy-agnostic

S3 becomes a pure object service, not an authorization engine.

IV.8 Why AWS Hasn’t Done This (Yet)

AWS already embraces this model elsewhere:

  • Envoy-style data planes for networking,
  • JWTs for identity.
  • externalized policy engines like Cedar.

But S3 predates these patterns.

Introducing RAJ-style authority artifacts would require acknowledging that:

  • IAM conflated identity, authorization, and execution,
  • authorization can be serialized and reused,
  • storage systems should not evaluate policy.

That is a conceptual shift, not a feature addition. Large platforms typically make such shifts only after the ecosystem proves inevitability.

IV.9 The Inversion That Matters

Traditional approach:

“Make S3 smart enough to authorize.”

Envoy + RAJ approach:

“Make authority explicit so S3 doesn’t have to authorize.”

That inversion is the breakthrough.

IV.10 One-Sentence Summary

Envoy enforces RAJs locally and mechanically, transforming S3 permissioning from implicit, request-time policy evaluation into explicit, compiled authority—without changing S3 itself.

Everything else is detail.

Leave a comment

Blog at WordPress.com.

Up ↑