@NewtonProtocol Every time you fly, you prove who you are exactly once.
At the security checkpoint, an agent checks your ID against your boarding pass. After that, every gate agent and flight attendant who deals with you for the rest of the trip only asks for the boarding pass.
Nobody at the gate re-examines your passport. They don't need your date of birth or your home address. They just need to know you were cleared.
I hadn't thought much about how strange that separation is until I started looking at how crypto systems handle identity and compliance.
The common approach seems to be all or nothing. Either a platform holds onto your full identity data to check every action you take, or a chain does no checking at all and hopes for the best.
What would it look like to prove you're allowed to do something, without a system needing to keep re-examining who you are?
That question is what led me to how @NewtonProtocol structures its authorization layer.
Newton separates identity verification from the authorization decision itself. Through an integration with Persona, verified identity and residency attributes feed into Newton's policy engine, but the check happens once, through a trusted execution environment, rather than being re-run in the open every time.
What moves onchain afterward isn't the identity data. It's the outcome a cryptographic attestation confirming a transaction met the required policy, recorded so it can be verified later without exposing what sits behind it.
From what I understand, the policies themselves are written in Rego and evaluated by a decentralized network of operators before a transaction settles, similar to how a card network checks fraud rules and identity before a payment clears.
The interesting part wasn't the privacy angle on its own. It was realizing that authentication and authorization are actually two different problems that most systems quietly merge into one.
Authentication asks who you are, and ideally only needs answering once. Authorization asks what you're allowed to do right now, and needs answering every single time.
Conflating them forces an uncomfortable choice. Either identity gets exposed repeatedly to keep verifying it, or checks get skipped to protect privacy.
Splitting them changes that. The identity check stays private and happens rarely. The authorization check happens constantly, but only ever exposes a yes or no, not the reasoning behind it.
I keep wondering what this actually costs, though. You gain privacy, but you lose the ability to personally verify what happened inside that private check.
You're trusting the oracle, the enclave, and the operators translating identity into a decision, rather than seeing the underlying data yourself. That's a different kind of trust, not the absence of it.
For developers, this seems to remove a real burden. Storing a full identity database of your own users is a liability most teams don't want and can't fully secure anyway.
For users, it means a public, auditable record of what was authorized exists, without a public record of who exactly you are attached to it.
For institutions, it offers something harder to get elsewhere: proof a rule was followed, without needing to become the custodian of everyone's personal data to prove it.
The more I sit with this, the more it feels like the actual insight isn't about privacy or compliance individually. It's simpler than that.
Proof doesn't require exposure.
I'm still not completely convinced that trusting infrastructure you can't personally audit is meaningfully different from trusting whoever used to hold your data directly.
Maybe the real question isn't whether identity and permission should be separated. Maybe it's how much quiet trust that separation asks of us in whatever sits in between.
