Digital Identity

Identity that earns the trust an enterprise has to place in it — by being governable, verifiable, and designed for the systems that depend on it.

On this page
  1. Top of page
  2. The shape of the work
  3. Common questions from clients
  4. What you walk away with
  5. Patterns we design our practice to avoid
  6. Evidence & references
  7. What to read next

§ 01 ·

When identity works, the rest of the security and architecture work becomes much simpler. The system can trust its own authorisation decisions. The audit trail is coherent. The organisation can move at a pace that does not depend on a person being in the room. When identity does not work, every other control is either too coarse or too brittle.

The work is to design identity into the architecture. The four phases the firm uses to do this work are on the How we work page.

§ 02 ·

The shape of the work

Numbers from the firm's own engagements over the last several years. Every number has a basis: `engagement data` (measured from real engagements), `design heuristic` (a working target the firm uses to plan), or `target` (a posture the practice is designed to maintain).

6–10
weeks is the typical horizon for a target identity architecture to reach a workable first cut
basis: engagement data
1
identity provider is the design goal — a single source of trust, with brokers and gateways as the explicit interface
basis: design heuristic
≥1
live, testable contract per external integration boundary (federation, sync, token exchange)
basis: design heuristic
0
unfederated credentials living outside the central identity store that the system depends on
basis: target

§ 03 ·

Common questions from clients

The questions we hear most often, in the order they tend to come up.

An identity store is the system of record for the organisation's identities — employees, contractors, service accounts, partners, customers, machines. It is a product. There are many competent ones.

An identity architecture is the design of how those identities are used. It names the trust boundaries, the authorisation model, the lifecycle, and the verification model — how a system can prove a decision was made correctly and on the right evidence.

In practice the store is a few months' work and the architecture is several years. The store is what you buy. The architecture is what you build.

Most identity engagements run between three and nine months. The framing phase (the trust map) is six to twelve weeks; the target architecture and federation contract work is the bulk of the engagement; the operating-model work is ongoing. The total horizon is set in the framing session and revised only by mutual agreement.

Engagements are priced against the trust map produced in the framing phase. The cost depends on the population of identities, the number of integration boundaries, the depth of the federation contracts, and the operating model the work needs. A typical range for a multi-phase engagement sits in the low-to-mid six figures; the final figure is set in the scoping call after the framing phase.

The first 30 days are the framing phase: structured interviews with leadership and practitioners, an inventory of the identity populations the organisation actually has, an inventory of the systems that issue or rely on identities, and the production of the trust map. By the end of the first 30 days, the client has a short list of decisions that need to be taken, ranked by how much they block the rest of the work.

By making the easy path the right path. Identity governance produces paved roads — pre-approved patterns for common decisions, pre-integrated applications, self-service for the routine, escalation for the exception. Most teams should not need to re-litigate the same questions for each new service. The forum sees the exceptions, not the routine.

A forum that sees every decision is a symptom of unclear contracts, not a solution to them.

§ 04 ·

What each phase produces in an identity context is on the How we work page.

What you walk away with

A flat list of the artefacts an identity engagement produces. The full shape of the engagement is on the [How we work](/services/methodology/) page.

A trust map

The population of identities the organisation actually has. The systems that issue or rely on identities. The trust boundaries that exist or are assumed. The gaps where a boundary is being crossed without a contract.

A target identity architecture as a reference model

Names the authoritative identity stores and what they each own. The federation patterns that connect them. The authorisation model. The lifecycle model. The verification model. Deliberately does not specify every component.

Federation contracts

For each boundary: the assertions that cross it. The trust relationship. The conformance tests that prove the contract is being honoured. The failure modes when a boundary breaks. Without these, identity work is folklore.

Operating-model documents

Who owns which decision. What the review cadence is. How exceptions are escalated. How the contracts are tested. How the architecture is revised when the evidence changes. Names what the operating model explicitly does not do.

A decision record per significant identity decision

A short, durable document. Records the decision. Records the assumption that proved correct. Records the conditions under which the decision will be revisited. The decision record is what lets the identity architecture be revised cleanly when the evidence changes.

§ 06 ·

Patterns we design our practice to avoid

Six failure modes we have seen repeatedly, across identity engagements of every size. Each one motivates a specific choice in how we work.

Security reviews find gaps in controls. They do not produce an architecture. An organisation that runs a security review every year and an identity review never has a better picture of its identity than it had when the last review finished.

A single store serving workforce, partners, customers, and machines is a design ambition that usually produces a worse outcome than a federation of fit-for-purpose providers. Different populations have different lifecycles and different regulatory contexts.

An authorisation decision that lives in a configuration file nobody has read in two years is folklore, not architecture. Without an explicit model of who decides what, on what basis, the system cannot tell a legitimate decision from a bypass.

Two systems exchanging assertions is not federation; it is a copy of identity data with extra steps. Federation requires a contract — assertions, trust relationship, conformance tests, failure modes — or it is just a less honest integration.

If the system cannot tell whether an identity is current, no authorisation decision is reliable. Lifecycle is the discipline that makes every other identity decision meaningful.

A review that happens at the end produces a finding list, not an architecture. By the time the review runs, the contracts are implicit, the assertions are baked in, and the changes the review recommends are expensive.

The thing that surprised us was how much of identity work is not about identity at all. It is about the contracts between systems. Once the contracts were explicit, the rest of the work got a lot smaller. Until they were explicit, every integration was a small project.

Head of Platform Engineering, mid-tier financial services firm, after a nine-month identity engagement

§ 08 ·

Evidence & references

Public frameworks and writing that inform the firm's practice.

OAuth 2.0 in Action
Justin Richer, Manning, 2017

The clearest end-to-end treatment of the authorisation layer as a contract, not a protocol. The conformance-test approach we use is the same approach the book describes for token exchange.

OAuth 2.1 — Authorization Framework
Dick Hardt, Aaron Parecki & the IETF OAuth Working Group, current draft

The consolidation of OAuth 2.0 — removing implicit flows, mandating PKCE, tightening redirect handling — is the same direction the paved-roads model takes the enterprise. Less to remember, fewer ways to be wrong.

API Security in Action
Neil Madden, Manning, 2020

The pattern language for token-based authorisation, key rotation, and the testability of authorisation decisions is the operational reference we lean on most often.

§ 09 ·

What to read next

The shape of the engagement, and the services and expertise the identity work most often sits next to.

Want to talk identity?

If you are weighing an identity programme, navigating a federation change, or strengthening the trust boundaries of an existing architecture, the firm is useful at that boundary. A short conversation is the right next step.

Start a conversation
© NOETRONIQ Contact