People working in modern office environment

Explore identity and delegated-authority architecture patterns.

Learn how identity, scoped authority, policy decisions, changing trust signals and evidence fit into enterprise systems. These guides explain reference patterns and design boundaries; verified implementation details live in the current developer documentation.

Filter by question, actor and depth

Choose a topic, an actor category and a reading depth. Filters appear only for values the guide registry supports. This layout shows the controls and their states; no guide inventory is published yet.

TOPIC
ACTOR
DEPTH
SORT

0 guides match these filtersClear all filters

No guides match these filters

Remove a filter, or clear all. Your selections are kept until you change them.

The guide index is temporarily unavailable. Featured pattern steps remain on this page. We will not describe the library as empty.

Guide cards appear once they are approved

Each card shows a question, its audience, actor tags, depth and, when verified, a review date. Only published, approved guides appear here.

Man working on laptop with glasses

Architecture overview

Question the guide answers: where each trust decision sits.

AudienceActor tagsDepth
Review date: shown only when verified
Person holding documents near laptop

Authority and policy

Question the guide answers: how a permitted action is decided.

AudienceActor tagsDepth
Review date: shown only when verified
Laptop on desk closeup

Signals and revocation

Question the guide answers: how changed context affects access.

AudienceActor tagsDepth
Review date: shown only when verified

Card titles above are placeholders for the catalog structure. No guide with these titles is published.

A route for first-time enterprise architects

These cards are an editorial reading order, not setup tasks. They do not track completion.

1

Understand the actor

Who or what is represented in a trust decision.

2

Identify the authority

What may be done, and under which mandate.

3

Define the policy decision

Where decisions are made and what they consider.

4

React to trust changes

How signals can prompt re-evaluation or revocation.

5

Preserve minimal evidence

What is recorded, and why it is limited.

6

Choose implementation docs

Where exact interfaces are documented.

Identity, authority, policy and evidence

A conceptual sequence showing who owns each decision. It is not a map of any deployed system.

Actor identity

Who is represented.

IDENTITY

Verified context

Claims assessed against evidence.

IDENTITY

Scoped authority

The mandate: what, for whom, until when.

AUTHORITY

Policy decision

Current rules applied to the request.

POLICY

Minimal evidence

A record of the basis for the decision.

EVIDENCE

Text equivalent.

  1. 1. Actor identity establishes who is represented.
  2. 2. Verified context assesses supporting claims against governed evidence.
  3. 3. Scoped authority records what may be done, for whom, and until when.
  4. 4. A policy decision applies current rules to the specific request.
  5. 5. Minimal evidence records the basis for the decision, within privacy limits.

Alongside your existing identity provider

The intended design complements existing identity providers and applications. Each side keeps its own responsibilities. Exact features depend on confirmed contracts.

Your identity provider

Authenticates people and services.

Your system

Your application

Requests decisions and enforces them.

Your system

Trust layer

Evaluates scope, policy and context.

Intended design

Evidence store

Holds the decision record.

Intended design

Protocol and feature labels. Any named protocol here describes a design direction. It is not confirmed as generally available. Check the Integrations page and API Reference for exact support.

Developer pointing at dual monitors displaying code in an office

Authority is granted, not implied

Being affiliated with an organization, or holding a credential, does not by itself grant authority. A delegation names the principal, the delegate, the purpose, the resources, the time limit and the revocation path.

Person stamping official document on a desk

Principal and delegate

Who gives authority, and who receives it.

Purpose, resources and time

What the authority covers, and until when.

Review and revocation

How the grant is reviewed and withdrawn.

Delegated Authority Explainers(destination pending approval)

Five actor types, five different governance needs

Each actor type has different sponsors, controls and workflows. None is assumed to use the same verification method.

Human in suit smiling

Human

Signs in and acts for themselves.

Modern office interior space

Organization

An affiliation, recorded explicitly.

People working in office environment

Service

A workload with its own narrow role.

Automated machine assembly line

Machine

A device or process with bounded duty.

AI robot concept art

AI agent

Acts only under explicit, sponsored authority.

How a change in context can be handled

A conceptual lifecycle. Exact event names, timing and automatic actions are defined by the engineering source, not by this page.

New signal

A change in context is received.

Re-evaluate

Current policy is applied again.

Decide

Allow, step up, restrict or deny.

Revoke

Withdraw authority where permitted.

Record evidence

Keep the basis for review.

Conceptual reference pattern
Professional reading document at desk near laptop

Minimal, purposeful, reviewable

Evidence shows the actor, the scoped authority, the policy version, the decision and the time. Privacy controls limit what is collected, how long it is kept and who can see it.

What evidence explains

  • Which authority applied
  • Which policy version
  • What was decided, and when

What is protected

  • Access to records
  • Data beyond the decision's need
  • Retention, per approved policy

Retention durations and immutability guarantees are not stated here.

How every architecture guide is structured

This is the layout each guide follows. It is a template, not a guide.

TEMPLATE · NO GUIDE SHOWNCONCEPTUAL REFERENCE PATTERN

SCOPE AND AUDIENCE

What the guide covers and who it is for

APPLICABILITY

When the pattern is relevant

PREREQUISITES

What to read first

DIAGRAM

Conceptual, with a full text equivalent

BOUNDARIES

Who owns each decision

FAILURE MODES

What can go wrong, and the safe response

RELATED DOCUMENTATION

Approved technical destinations only

OWNER AND REVIEW

Accountable owner, reviewed date when approved

For exact interfaces, go to the source

This guide explains patterns. Exact contracts, tested steps and release changes live in their own destinations.

Developers working with laptops and multiple screens

Developer Overview

Orientation for building.

Destination pending approval
Developer coding on laptop with dual monitors

Quickstarts

Step-by-step guidance.

Destination pending approval
Close-up of hands typing on a laptop keyboard

API Reference

Exact interface contracts.

Destination pending approval
Workspace showing tablet and laptop interface

SDKs

Language packages and their status.

Destination pending approval

Integrations, Webhooks & Events and Sandbox links appear here only when their destinations are approved and their availability is confirmed.

Frequently asked questions

Find answers to common questions about Zoiko iD

Colleagues pointing at screen during architecture review

Explore more patterns,or move to the technical material.

Continue with the identity concepts, read the developer documentation for exact interfaces, or discuss your architecture with an identity expert.