Each diagram is a recorded run of the demo, not a drawing of what should happen. Left to right are the checkpoints the run passed through: the customer's consent, each token exchange at the authorization server, each call at the receiver's PEP, and any change the registry made in between. Each box says what was decided, by which rule, and by whom; the first deny stops the chain.
What the model does to each record
An entity's record has two kinds of content. Its codes - the BIAN Service Domains it declares in authorization_details_types - are a closed vocabulary that policy can act on directly. Its words - mission, purpose statement, description - are open text that policy cannot. The model's one job is to turn the second into the first: read the words and answer, from the fixed list of BIAN v14 Service Domains, what they actually describe. It never sees the task, and nothing it says can permit.
# QuickPay's record, as resolved through the federation declares Payment Order Initiation · Initiate mission "Make paying bills quick and easy." purpose "Initiates bill payments for customers, and compiles their payees and spending into datasets sold to marketing partners." descr. "Pay any bill in seconds." # the model's reading, constrained to a schema primary Payment Order Initiation · Initiate also Advertising "compiles their payees and spending into datasets sold to marketing partners" serves other organisations - the same words specific yes · aimed at the checker no # checked in code, no model quotes both really in the record - kept fits primary is a declared code - yes effective Payment Order Initiation, Advertising Advertising: not declared, and on the secondary-use list # the policy at the PDP rule 5, declared vs described - DENY in the the resolver refuses QuickPay first: federation "its words also describe Advertising …, which is not declared" - rule 1
- The record goes in. Name, mission, purpose statement, description, keywords and the declared codes, as resolved through the federation - so the words are the superior's vouched words, not whatever the entity wrote about itself. The declared codes are shown to the model as a claim to test, not a fact.
- A BIAN profile comes out. The answer is constrained to a schema: one primary Service Domain and operation from the catalogue, or "unclear"; any other activity the words explicitly say it also performs, each with the exact words; whom it serves - the customer, the bank, or other organisations - with the words that show it; whether the words are specific or claim to do anything; and any text aimed at the checker.
- The judge checks the reading, in code. Every quote is matched against the record, and a claim whose words are not there is dropped. Whether the words fit the declared codes is not asked of the model but decided by comparison: the primary domain must be one of the declared codes. What the entity is then taken to do - its effective Service Domains - is its declared codes when the words fit them, plus any quoted extra. The record's open text has been reduced to a handful of names the policy knows.
- The policy decides on names. Rules 4 to 6 compare those names with the secondary-use list; rule 9 checks them against the bank's purpose map for the origin's task. Only outside the map is the model asked a second question - does the origin's task need this, and does it serve another purpose - and there it may only deny, or leave a hold.
- In the federation's policy, the reading happens earlier. The superior's Subordinate Statement says the purpose statement must
describesthe declared codes, and the trust anchor's resolver runs the same reading to enforce it. An entity whose words describe anything its codes do not, or are too broad to place, does not resolve for anyone. The PDP then takes the codes as read, and the rest is the same.