SDA: Strictly Disciplining Authorization

Sequel to Crowning RAJ: How Resource-Access JWTs Refactor Authorization, Joyfully

Write the sequel skit where Mark S. Miller pitches the idea of “Software-Defined Authorization” to Dick Hardt (OAuth 2.0), Nick McKeown (Software-Defined Networking), & Charity Majors (Observability); build up to a non-omniscient total grammar by addressing their concerns.
ChatGPT Prompt

Opening: “Didn’t We Already Solve This?”

Dick:
“So… tokens again. OAuth already did delegation. Why rename it?”

Mark:
“Because delegation isn’t the problem. Authority is. And OAuth mixes identity, policy, and enforcement at runtime.”

Nick:
“Sounds like you’re hinting at a control plane.”

Charity:
“And a data plane. Which means debuggability. Which means pain.”

Mark (smiling):
“Exactly. Let’s make the pain finite.”

3. Thesis: Separate Intent from Enforcement

Mark (writes on board):

Control plane: declare intent
Compilation: produce authority
Data plane: enforce mechanically

Nick:
“That’s SDN. Policies compile to forwarding rules.”

Mark:
“Yes. Except the packets are requests, and the rules are capabilities.”

Dick:
“Capabilities as bearer tokens?”

Mark:
“As compiled authority. Bearer is an implementation detail.”

4. Charity Interrupts: “Show Me the Failure Modes”

Charity:
“I don’t care about elegance. I care about knowing why Alice downloaded 200 GB at 3 a.m.”

Mark:
“Then we ban creativity.”

Charity:
“…what?”

Mark:
“No dynamic policy evaluation. No runtime inference. Only artifacts you can point at.”

Nick:
“So enforcement is a subset check?”

Mark:
“Exactly. request ⊆ authority.”

5. Dick Pushes Back: “Revocation?”

Dick:
“Bearer tokens don’t revoke.”

Mark:
“They expire. On purpose.”

Dick:
“And when that’s not enough?”

Mark:
“You rotate the compiler key. The system fails closed.”

Charity:
“Bounded blast radius. Documented. Auditable.”

Dick (nods):
“That’s honest.”

6. Nick Sharpens the Analogy: “Where’s the Line?”

Nick:
“In SDN, bugs happen when semantics leak into the data plane.”

Mark:
“Same rule here.”

Mark (writes):

Data plane: no policy
No DB lookups
No conditionals
No context

Nick:
“Then the compiler must be deterministic.”

Mark:
“Stronger.”

7. The Turn: Deterministic Is Not Enough

Mark:
“Determinism still allows ambiguity.”

Charity:
“Preach.”

Mark (underlines):

Every step must produce a trivially verifiable canonical form — or error.

Dick:
“Every step?”

Mark:
“Parsing. Storage. Tokens. Logs. Proxies. Everything.”

8. The Objection: “You’re Asking for Omniscience”

Dick:
“How do you design for futures you can’t predict?”

Mark:
“You don’t. You design syntax, not semantics.”

Nick:
“Fixed grammar; evolving semantics.”

Mark:
“Yes. With one rule: no implicit authority.”

9. Total Grammar, No Escape Hatches

Charity:
“Let me guess. No ‘ext’ fields.”

Mark:
“None.”

Mark (writes):

Nick:
“Reverse-DNS like Java packages?”

Mark:
“Exactly. Ownership is explicit. Dispatch is mechanical.”

Dick:
“So a new feature is a new type, not a flag.”

Mark:
“And old verifiers fail closed. No guessing.”

10. Charity’s Test: “Can I Debug It?”

Charity:
“Can I answer: why was this allowed?”

Mark:
“Yes. Because there are only two artifacts.”

An immutable ledger (append-only event log)
A canonical capability

Charity:
“And the proxy just checks inclusion.”

Mark:
“And logs the token identifier.”

Charity (smiles):
“I can graph that.”

11. Naming the Thing

Nick:
“This isn’t storage. It isn’t networking.”

Dick:
“It isn’t OAuth.”

Charity:
“It’s… authorization, but engineered.”

Mark:
“Software-Defined Authorization.”

(Pause.)

Nick:
“Control plane for authority.”

Dick:
“Compilation, not interpretation.”

Charity:
“Finite failure modes.”

12. Closing Invariant (Everyone Signs)

Mark (final slide):

At no point does the system accept, contain, transmit, or act upon a non-canonical representation.

Nick:
“That’s enforceable.”

Dick:
“That’s evolvable.”

Charity:
“That’s operable.”

Mark:
“Then we’re done.”

Lights out. The proxy hums quietly. Nothing surprising happens.

13. Epilogue: Formalizing RAJ

From tokens to compiled authority
From determinism to total canonical grammar
From authorization to system-wide correctness
From best effort to fail closed

Software-Defined Authorization isn’t a product.
It’s a discipline.

And disciplines age well.

Appendix I: How SDN Lost… Then Won

Software-Defined Networking (SDN) did not fail as an architectural idea.
But early SDN absolutely lost its first battle.

Understanding how it lost—and why it later won—is essential, because Software-Defined Authorization is deliberately starting from SDN’s second act, not its first.

I.1 The First Loss: Overestimating Central Intelligence

Early SDN proposals carried an implicit assumption:

If we centralize control, we can reason globally and optimize everything.

This manifested as:

logically centralized controllers
fine-grained, dynamic control over forwarding
expressive, programmable rule languages
expectation that operators would “write logic”

In practice, this failed because:

latency mattered
failure domains mattered
humans could not safely reason about that much power
networks became fragile under partial failure

SDN briefly looked like programmable routing hardware.

That was the mistake.

I.2 The Second Loss: Underestimating Implicitness

Even where SDN was deployed, early systems struggled because:

rule priority was underspecified
default behaviors varied by implementation
canonical match semantics were weak or absent
“best effort” interpretation crept back in

The separation of control and data planes collapsed when implicit semantics leaked across the boundary.

Determinism alone was not enough.
Deterministic ambiguity is still ambiguity.

This is where early SDN actually failed operationally.

I.3 The Turning Point: Canonical Artifacts, Not Programmability

SDN began to win only after it abandoned the fantasy of:

fully programmable forwarding
expressive rule languages
omniscient controllers

And instead embraced:

canonical rule representations
strict match semantics
fail-closed behavior
dumb, interchangeable data planes

Control planes became compilers.
Data planes became executors.

The real interface was no longer the API—it was the flow table.

I.4 Hardware Abstraction Was the Real Victory

Once forwarding behavior was:

explicit
canonical
finite

Hardware stopped mattering.

Routers and switches became:

replaceable
testable
predictable

Vendors could innovate underneath without changing semantics above.

This is when SDN stopped being a product category and became how networks actually work.

I.5 How SDN Finally Won

SDN “won” quietly:

Cloud networking adopted the model
Virtual switches enforced canonical rules
Kubernetes networking assumed it
Service meshes embedded it
Security groups and ACLs followed the pattern

The name faded.
The discipline remained.

That is not failure.
That is absorption.

I.6 The Lesson Software-Defined Authorization Takes Forward

Software-Defined Authorization deliberately skips SDN’s losing phase.

It does not assume:

omniscient control
expressive runtime policy
dynamic interpretation
permissive defaults

Instead, it adopts SDN’s mature conclusions:

separate intent from enforcement
compile intent into canonical artifacts
eliminate implicit behavior
constrain semantics to preserve correctness
make enforcement dumb, fast, and interchangeable

I.7 The Shared Invariant

SDN’s durable invariant became:

Forwarding behavior is entirely determined by explicit, canonical rules.

Software-Defined Authorization adopts the analogous invariant:

At no point does the system accept, contain, transmit, or act upon a non-canonical representation.

I.8 Summary

SDN did not fail because the idea was wrong.
It failed where:

implicit behavior survived
semantics were underspecified
expressiveness outpaced correctness

SDN won when it became:

boring
explicit
constrained
canonical

Software-Defined Authorization begins there.

The loss was necessary.
The win was permanent.

Appendix II: Related Disciplines

Software-Defined Authorization does not emerge in isolation.
It sits at the intersection of several older disciplines that independently converged on the same hard-earned lessons: explicitness beats cleverness; canonical forms beat interpretation; constraints beat expressiveness.

This appendix situates Software-Defined Authorization among those disciplines—not as a replacement, but as a synthesis.

II.1 Capability-Based Security

Capability-based security established the foundational idea that:

authority should be explicit
possession should imply permission
absence of a capability implies denial

However, classic capability systems struggled with:

large-scale distribution
revocation
auditability
integration with heterogeneous systems

Software-Defined Authorization adopts the capability model but adds:

compilation from declarative intent
deterministic, canonical artifacts
explicit lifecycle and audit semantics
separation of issuance from enforcement

It is capability security adapted to modern distributed systems.

II.2 Compiler Design

Compiler theory contributes two critical insights:

Intermediate representations (IRs) matter more than source languages
Correctness comes from canonicalization, not expressiveness

Authorization policies are treated as source code.
Capabilities are the compiled artifacts.

Once compiled:

enforcement does not reinterpret policy
verification does not re-run compilation
errors are caught early, not at runtime

This is why authorization becomes predictable only when it behaves like compilation.

II.3 Deterministic and Total Computing

Deterministic systems guarantee repeatability.
Total systems guarantee termination and explicit failure.

Software-Defined Authorization requires both:

deterministic compilation
total grammars

Every step produces:

a canonical, trivially verifiable artifact
or a typed error

Partial results, best-effort interpretation, and implicit coercion are forbidden.

This places the system closer to formal computation than traditional access control.

II.4 Formal Grammars and Canonical Encoding

Formal grammar theory teaches that:

ambiguity is a design flaw
syntax must be decidable
canonical representations are essential for equivalence checking

Reverse-DNS namespacing, versioned schemas, and total parsing rules come directly from:

language design
protocol specification
cryptographic serialization formats

Authorization artifacts behave more like protocol messages than like configuration files.

II.5 Zero Trust Architecture (ZTA)

Zero Trust reframed perimeter security as:

explicit verification
no ambient trust
continuous enforcement

However, many Zero Trust systems:

retain runtime policy evaluation
depend on contextual inference
reintroduce implicit authority via defaults

Software-Defined Authorization complements Zero Trust by:

replacing inference with compilation
replacing context with explicit authority
replacing dynamic evaluation with mechanical enforcement

Zero Trust defines where to enforce.
Software-Defined Authorization defines how enforcement remains correct.

II.6 Observability and Debuggable Systems

Observability teaches that:

systems must explain themselves
outcomes must be attributable
debugging must not require guesswork

Authorization systems traditionally fail this test.

By reducing authorization to:

immutable events
canonical artifacts
mechanical checks

Software-Defined Authorization makes access decisions:

traceable
auditable
explainable after the fact

If a decision cannot be explained by inspecting artifacts, it is a bug.

II.7 Distributed Systems and Failure Semantics

Distributed systems theory emphasizes:

explicit failure modes
bounded inconsistency
fail-closed behavior

Authorization failures are safety failures, not availability failures.

Therefore:

uncertainty must result in denial
partial knowledge must not produce authority
outages must degrade into inaction, not permissiveness

This aligns Software-Defined Authorization with safety-critical system design.

II.8 Hardware Abstraction and Virtualization

Virtualization succeeded by:

constraining hardware interfaces
eliminating implicit behavior
standardizing semantics above the abstraction boundary

Software-Defined Authorization applies the same logic:

enforcement substrates become interchangeable
authority semantics are stable across backends
evolution happens above the abstraction line

Authority, like compute, becomes portable only when semantics are fixed.

II.9 What This Is Not

Software-Defined Authorization is not:

a policy engine
an IAM replacement
a general-purpose language
a runtime reasoning system

It borrows discipline from many fields while deliberately rejecting their excesses.

II.10 Synthesis

Across these disciplines, the same pattern recurs:

implicit behavior causes failure
expressive systems resist reasoning
canonical artifacts enable correctness
compilation outperforms interpretation

Software-Defined Authorization is the point where these lessons converge—applied specifically to authority.

Not new ideas.
New alignment.

Appendix III: How RAJA Saves Cedar From Itself

This appendix is not a critique of Cedar.
It is an explanation of how Cedar remains correct when paired with RAJA—and how it quietly fails when used alone.

III.1 Cedar’s Strength—and Its Natural Failure Mode

Cedar is excellent at what it was designed to do:

express authorization intent declaratively
evaluate policies safely (decidable, non-Turing complete)
reason over identity, attributes, and context

Its natural operating mode, however, is:

Evaluate policy at request time.

Left on its own, Cedar is therefore pulled toward:

runtime interpretation
context dependence
distributed evaluation
implicit authority via defaults and conditions

None of these are Cedar’s fault.
They are consequences of being used as a runtime oracle.

III.2 The Historical Trap: PDPs at Enforcement

When Cedar (or any PDP) is invoked during enforcement:

policy becomes the executable artifact
authority is re-derived repeatedly
context becomes mandatory
auditability requires replay
correctness depends on evaluation order and environment

In this mode, even a safe policy language inherits the classic problems of:

ABAC
IAM
inline authorization checks

Cedar stays sound, but the system becomes interpretive again.

III.3 RAJA’s Intervention: Move Cedar Upstream

RAJA changes when Cedar is allowed to speak.

Cedar is used only to answer one question:

May authority be minted?

That is:

before enforcement
before side effects
before ambiguity matters

Cedar evaluates intent, not actions.

Once Cedar returns ALLOW, it is immediately silenced.

III.4 From Policy Evaluation to Authority Compilation

RAJA takes Cedar’s boolean decision and performs a different operation entirely:

resolve references
pin immutables
canonicalize actions
emit a finite authority artifact (RAJ)
or error

Cedar never:

enumerates resources
defines scopes
encodes semantics
participates in enforcement

Policy remains source material, not executable truth.

III.5 How This Saves Cedar

RAJA protects Cedar from pressures it was never meant to bear:

Cedar no longer needs to be highly available on the data path
Cedar is insulated from latency and partial failure
Cedar is no longer blamed for audit gaps
Cedar does not accrete “just one more condition” to handle runtime edge cases

Cedar stays:

expressive
safe
comprehensible

Because it is no longer asked to be final.

III.6 The Critical Asymmetry

In this pairing:

Cedar can influence whether authority exists
Cedar can never influence what authority means

That asymmetry is the safeguard.

If Cedar were allowed to shape authority directly, its semantics would leak into enforcement.
RAJA prevents that by enforcing a total, canonical grammar that Cedar cannot bypass.

III.7 Enforcement Without Cedar (On Purpose)

At enforcement time:

Cedar is absent
policy is absent
identity is absent
context is absent

Only two things remain:

a canonical request
a canonical authority artifact

The check is mechanical.

This is not a limitation.
It is the entire point.

III.8 The Resulting Division of Responsibility

Cedar answers:

Should we grant?

RAJA answers:

What exactly was granted?

Enforcement answers:

Is this action already included?

Each component does one job.
None are asked to improvise.

III.9 The Broader Lesson

Cedar is a policy language.
RAJA is an authority compiler.

Confusing the two is how systems regress into interpretation.

Paired correctly, they form a pipeline that is:

expressive at the edges
rigid at the core
mechanical at the point of action

III.10 Summary

RAJA does not replace Cedar.
It rescues Cedar from being used where interpretation is dangerous.

By confining Cedar to the control plane and forcing all meaning to pass through a canonical compilation step, RAJA ensures that:

policy remains human
authority remains formal
enforcement remains boring

Which is exactly how safe systems endure.

Appendix IV: Newton’s Fourth Law

For Every Action There Is a Canonical Representation

Write as John Cleese, comparing SDA to Newton shifting natural philosophy from language to mathematics.
ChatGPT Prompt

(As delivered by John Cleese, wearing a wig he insists is historically accurate)

Good evening.

I’m John Cleese, which means I am contractually obligated to explain something grave, abstract, and faintly ridiculous, while pretending not to enjoy it at all.

Today’s topic is Software-Defined Authorization, which—despite appearances—is not a new cheese, nor a Scandinavian furniture line, but rather a profound intellectual shift. One that bears a striking resemblance to what happened when natural philosophy stopped waving its arms about and started writing things down in mathematics.

This brings us, inevitably, to Isaac Newton.

IV.1 The First Three Laws (A Brief Recap, for Those Who Skipped School)

Newton gave us the laws of motion, all of which can be summarized as:

Things behave badly unless you are very precise about them.
Precision helps.
Apples are dangerous.

Before Newton, people explained motion using language:

“The stone wants to fall.”
“The heavens prefer circles.”
“God is feeling whimsical today.”

After Newton, motion was described using formal symbols, and suddenly:

predictions worked
arguments ended
bridges stopped collapsing quite so often

This was not a change in facts.
It was a change in medium.

IV.2 Authorization, Before Its Enlightenment Period

Authorization today is largely pre-Newtonian.

It is described in:

policy documents
configuration files
IAM consoles
human intention
vibes

Questions like:

“Should Alice be able to read this?”
“What happens if Bob does that?”
“Why did this work yesterday?”

are answered with interpretation, context, and occasionally ritual sacrifice.

Meaning lives in:

defaults
evaluation order
runtime inference
undocumented behavior

Which is to say: language.

IV.3 The Problem with Language (Apart from the French)

Language is marvellous for poetry, seduction, and shouting at inanimate objects.

It is terrible for enforcing authority.

Because language:

permits ambiguity
rewards cleverness
tolerates interpretation
allows people to say “well, technically…”

Authorization systems built in language inevitably behave like philosophers arguing about motion before calculus.

Everyone sounds confident.
No one agrees.
Things fall over.

IV.4 Newton’s Fourth Law (At Last)

Software-Defined Authorization proposes a modest addition to Newton:

For every action, there exists a canonical representation — or the action does not occur.

This is not metaphorical.
It is merciless.

An action here means:

reading data
writing state
invoking a service
causing an effect

If you cannot:

name it precisely
represent it canonically
verify it mechanically

Then, quite simply:

You may not do it.

No interpretation.
No inference.
No “but I meant…”

IV.5 From Language to Symbols (Again)

Just as Newton replaced:

“motion as described”

with:

motion as represented

Software-Defined Authorization replaces:

“permission as intended”

with:

permission as artifact

Policies become source code.
Authority becomes a compiled object.
Enforcement becomes arithmetic.

The system no longer asks:

“Does this seem allowed?”

It asks:

“Is this action contained within this representation?”

And if not, it declines politely and immediately, like a well-trained butler.

IV.6 Error Is Not Failure; Ambiguity Is

In pre-Newtonian science, disagreement was common and progress slow.

In pre-canonical authorization, ambiguity is common and outages frequent.

Software-Defined Authorization makes a shocking claim:

Error is acceptable. Ambiguity is not.

If an action cannot be represented, the system refuses to guess.

This is not rudeness.
It is maturity.

IV.7 The Punchline (Because I Am, After All, John Cleese)

Newton did not make the universe simpler.

He made it expressible.

Software-Defined Authorization does not make systems safer by adding intelligence.
It makes them safer by removing interpretation.

Which brings us, finally, to the law itself:

Newton’s Fourth Law:
For every action there is a canonical representation; if there is not, there shall be no action.

If that sounds harsh, remember:

So is gravity.

Yet we build skyscrapers with it.

Thank you.

(Exit pursued by an authorization error.)