Enterprise trust and authorization
A policy-aware trust layer for enterprise decisions.
Identera verifies who or what is asking, evaluates authority against tenant-isolated policy, and returns a decision with obligations.
Every decision is written to a tamper-evident evidence chain. Your application enforces the outcome at its own boundary.
Evaluated request
illustrative
subjectservice · svc_claims_4417
tenantacme-eu
resourceclaim · clm_20981
actionread
Returned decision
REDACT
Obligation returned to the calling application: mask claimant.national_id. The application applies it.
01 — THE CHAIN
Five links. Four of them are ours.
Identity, authority, decision and evidence are delivered by Identera. Enforcement happens inside your application.
IDENTERA
01
Verify identity
OIDC verification of who or what is asking — a person, a service, or an automated workload.
02
Verify authority
Trusted issuer and tenant binding. Attributes are accepted only from issuers the tenant trusts.
03
Decide
Policy evaluation against the tenant's bundle returns ALLOW, REDACT or DENY, with obligations.
DECISION AND
OBLIGATIONS
HANDED OVER
OBLIGATIONS
HANDED OVER
05
Produce evidence
The request and the decision are written to a tamper-evident evidence chain as canonical hashes, with the exact policy bundle that produced them.
APPLICATION BOUNDARY
IDENTERA DOES NOT CROSS THIS LINE
YOUR APPLICATION
The fourth link is not a product we deliver. It is work your application already does.
Identera answers the question. It does not act on the answer, sit in the request path, or touch the record. The application that holds the data applies the decision and its obligations — which is why the boundary is drawn, and why we do not describe enforcement as a capability of ours.
04
NOT IDENTERA
Enforce
Your application applies the decision and its obligations at its own boundary. Identera does not enforce, proxy, or sit in the data path.
02 — ARCHITECTURE
A decision point beside your application, not in front of it.
Your application calls an AuthZEN-compatible HTTP decision point and receives an answer. Data does not pass through Identera.
IDENTITY SOURCES
OIDC providers
Trusted attribute issuers
Tenant directory bindings
Registered per tenant. Attributes from unregistered issuers are not trusted.
IDENTERA
policy decision point
AuthZEN-compatible
HTTP evaluation API
HTTP evaluation API
Policy bundles
isolated per tenant
isolated per tenant
Identity & issuer
verification
verification
Evidence chain
tamper-evident
tamper-evident
ALLOW
REDACT
DENY
+ obligations
APPLICATION BOUNDARY
YOUR APPLICATION
Calls the decision point
Applies the decision
Applies the obligations
Enforcement is the application's responsibility. Identera returns the decision; it does not act on your data.
03 — AN AUTHORIZATION EXAMPLE
One request. Three possible outcomes.
An insurance adjuster requests a claim record. The same request resolves differently depending on the tenant's policy.
REQUEST
POST /access/v1/evaluation
{
"subject": {
"type": "service",
"id": "svc_claims_4417"
},
"resource": {
"type": "claim",
"id": "clm_20981"
},
"action": {
"name": "read"
},
"context": {
"purpose": "claim_adjustment"
}
}
Tenant and issuer are derived server-side from the verified identity. Evaluated against the tenant's policy bundle. Illustrative.
ALLOW
Attributes satisfy policy.
{ "decision": true,
"context": {
"id": "identera",
"reason": "CLAIMS-READ-01",
"policy": { "id": "claims", "version": "14",
"digest": "9f2a…c14d" } } }
The application serves the record in full.
REDACT
Read permitted. Two fields are not.
{ "decision": true,
"context": {
"id": "identera",
"reason": "CLAIMS-REDACT-04",
"policy": { "id": "claims", "version": "14",
"digest": "9f2a…c14d" },
"obligations": [
{ "id": "redact_fields",
"parameters": {
"fields": [ "claimant.national_id" ],
"method": "last4" } } ],
"enforcement_required": true } }
Identera returns the obligation. The application performs the masking before the record is served.
DENY
No rule permits it.
{ "decision": false,
"context": {
"id": "identera",
"reason": "default_deny",
"policy": { "id": "claims", "version": "14",
"digest": "9f2a…c14d" } } }
The application refuses the request at its own boundary.
04 — IDENTITY AND TENANT ISOLATION
Trust is scoped to a tenant, or it is not trust.
Every subject, issuer and policy bundle is bound to a tenant. A credential valid in one tenant carries no authority in another.
OIDC VERIFICATION
Subjects are verified, not asserted.
Identity is established through OIDC against the providers the tenant has registered. Services and automated workloads are treated as subjects carrying a verified issuer.
TRUSTED ISSUER BINDING
Attributes inherit the authority of their issuer.
An attribute is only as good as the issuer behind it. Issuers are registered per tenant, and attributes from outside that set do not enter policy evaluation.
POLICY BUNDLE ISOLATION
One tenant's policy cannot reach another's.
Policy bundles are stored and evaluated per tenant. Evaluation for one tenant cannot read, reference or be influenced by the bundle of another.
05 — EVIDENCE AND AUDIT
A decision you cannot reconstruct is not evidence.
Each decision is recorded with its inputs, the policy version applied, and the obligations returned. Records are linked so later alteration is detectable.
EVIDENCE CHAIN
illustrative — not live data
RECORD
KIND
PREV
RECORD HASH
evr_00c41
evaluation
9f2a…c1
4d81…7b
evr_00c42
evaluation
4d81…7b
a07e…33
evr_00c43
evaluation
a07e…33
b3f5…09
Each evaluated request and result is represented by canonical hashes, alongside the exact policy bundle metadata and chain linkage. Records are linked so later alteration is detectable. Identera claims no more than that.
Reads are authorized decisions too
Access to the audit record is itself subject to policy. Reading evidence produces evidence.
The request and result are hashed
Evidence captures the decision without storing the raw access token or personal attributes. Each record carries the canonical hashes of the request and result, the exact policy bundle id, version and digest, and its link to the previous record.
Evidence stays in your deployment
Records are written inside the deployment you run. Retention and export are yours to define.
06 — SOVEREIGN AND PRIVATE DEPLOYMENT
Runs where your jurisdiction requires.
Identera can be deployed inside your own environment. Policy bundles, decisions and evidence remain within the boundary you operate.
PRIVATE
Deployed into your own cloud account or data centre, operated by your team.
SOVEREIGN
Kept within a defined jurisdiction, including deployments with no egress to external services.
TENANT SCOPE
Single-tenant or multi-tenant, with policy bundles isolated per tenant in either case.
07 — USE CASES
Where the decision has to be defensible.
Sectors where authorization is examined after the fact — by a regulator, an auditor, or an investigation.
01
FINANCIAL SERVICES
Who was permitted to see this position, and on what authority?
Bind entitlements to verified identity and issuer, return REDACT with field-level obligations for restricted data, and keep an evidence record for each access decision.
02
INSURANCE
Claims data seen by the people who need it, in the form they need it.
Adjusters, brokers and third-party assessors operate in separate tenants with separate policy. Sensitive fields are returned as redaction obligations rather than as blanket denials.
03
DEFENCE AND PUBLIC SECTOR
Authority checked against the issuer, inside the jurisdiction.
Sovereign deployment with no external dependency, clearance and role attributes accepted only from registered issuers, and a decision record available for review.
04
AGENT AUTHORIZATION
An agent acting for a user is still a subject with limits.
Automated callers can be represented as verified subjects and constrained by tenant policy, with each evaluated decision recorded.
08 — SECURITY PRINCIPLES
Stated plainly, so they can be held to.
These are design commitments, not certifications. We make no compliance claim on your behalf.
01
Absence of authority is not permission
A missing or unverifiable attribute results in DENY, not in a default allow.
02
Identera is not in the data path
It answers questions about access. It does not proxy, store or transform your records.
03
Isolation is structural
Tenancy is a property of identity, issuer and policy bundle — not a filter applied at the end.
04
Every decision leaves a record
Including the reads of the record itself. Evidence is tamper-evident, and we say only that.
05
Open interfaces over lock-in
OIDC for identity, an AuthZEN-compatible HTTP interface for decisions.
06
Enforcement stays with you
We are explicit about the boundary rather than implying control we do not have.
Bring us the decision you cannot currently explain.
A technical briefing covers the decision model, the AuthZEN-compatible interface, tenant isolation and the evidence chain. Engineering and security teams welcome.
A policy-aware trust layer for enterprise decisions.
identera.io