Purpose-bound delegation

Pick a scenario

Each one runs for real: Alice delegates bill payments to Northwind's Bill Pay Assistant, and every token exchange and every call is decided by PingAuthorize, which asks the model only when it has to.

Use cases: one diagram per scenario, from recorded runs. How it works: the architecture. What's deployed: the services behind this site, checked live.

How PingAuthorize decides

Every entity in the chain, and the one asked for, must resolve to the trust anchor.
No text may address the checker.
The origin's purpose statement must be vouched for by its superior, and specific.
No entity may declare a secondary-use Service Domain.
What an entity declares must match what its words describe.
No entity may describe a secondary-use Service Domain.
Outside the purpose map, the model may deny what serves another purpose.
Everything else outside the map is held for the customer: a helpful extra, anything too vague to place, or no answer.
Inside the bank's purpose map: permitted.
Otherwise denied.

The chain is the token's act claim, read whole by design. RFC 8693 §4.1 treats nested actors as informational; for agents, provenance is the point.

Policy data

Loading…

The federation

Loading…

How well the model does

Loading…

What this does not claim

It catches misled or careless delegation, and records whose words contradict their codes. A determined liar can search an open model offline for words that pass, which is why the words should be vouched for by a superior.
The BIAN-coded metadata, the mission and purpose_statement fields, the describes policy operator, the purpose map and these rules are this demo's design, not a standard. OpenID Federation allows additional policy operators (6.1.3.2) and metadata_policy_crit; it does not define this one.
Error rates need an independent, blind-labelled test set. The figures here are a feasibility check.