What's deployed

The services behind this demo, what each runs, and whether each is answering right now.

One private network: six services that make and carry the decisions, and one service for every agent and API of the story. Two face the internet: this site, and the federation's public records. The rest answer only to each other. Everything below is read from the services themselves when you open this page, not from a list kept by hand.

Checking…

1The picture, live

Orange borders face the internet; the rest answer only on the private network. The mark on each box is that service answering when this page loaded; for the agents and APIs it is all of them answering. Both ways purpose can be checked are drawn, and the one in force now is marked.

What talks to what

Scroll sideways to see the whole picture.

Federation host trust anchor · Northwind Bank · Accredited Fintech Registry · every member's record · the resolve endpoint PUBLIC Federation host: checking You a browser This site scenario runner these pages PUBLIC This site: checking Agents and APIs one service each: keys, PEP checking… PRIVATE Agents and APIs: checking Authorization server RFC 8693 token exchange DPoP · private_key_jwt PRIVATE Authorization server: checking PingAuthorize AuthZEN servlet, embedded PDP 10 rules, first applicable PRIVATE PingAuthorize: checking Purpose service facts, no model judge, purpose map PRIVATE Purpose service: checking Model runtime Ollama CPU · volume PRIVATE Model runtime: checking starts a run grant, plan to the origin token exchange each hop calls the next agent or API AuthZEN, each call AuthZEN, before issuing facts, verdict reads, compares purpose checked here resolve resolve, every decision the resolver's model reads each member's words purpose checked here
Every relier, the agents, the authorization server and the purpose service alike, resolves an entity through the federation's resolve endpoint before it trusts it. The site hands the origin agent the customer's grant and the plan; from there the agents exchange tokens and call each other. The authorization server asks PingAuthorize before it issues; each agent's and API's PEP asks it before it answers. PingAuthorize calls the purpose service for facts and a verdict, and the purpose service reads the model. When purpose is checked in the federation's policy, the resolver's own model reads each member's words instead.

2The services

ServiceWhat it doesExposureRunsNow
Checking…

3The agents and APIs

Who vouches for whom, and who asks for a token for whom.

The relationships, liveDrawing…

Scroll sideways to see the whole picture.

Thin dotted lines are vouching: a superior's statement about each entity below it, from the trust anchor down. Arrows are delegation: the agent at the tail asks the authorization server for a token for the entity at the head. A plain arrow is one the scenarios expect to be permitted, a red one a refusal, an amber one both, depending on the scenario. A dashed box is a member the federation has dropped; the dot on each leaf says whether its service is answering now. The authorization server and the consent service are members too, but ask for nothing, so they are not drawn.

Every leaf of the federation runs as a service of its own, with its own keys and its own PEP, reached only inside the private network. The list comes from the federation's directory, and each was asked whether it is answering when this page loaded.

ServiceOrganisationKindIn the storyNow
Checking…

4The decision, as deployed

5The model, as deployed

6What the pages are drawn from

7Not shown here

Hostnames and addresses inside the private network, credentials, and the layout of the hosting account. The federation's records are public by design, and its resolve endpoint is where every relier in the demo resolves; the policy engine, the purpose service and the model can be reached only from inside.

Run the demo