For regulators
One trip. Six patterns. Seven controls.
Each pattern puts the authority, the enforcement and the technical work at a different party. This page shows where each pattern places them. It assesses only P1, the pattern that runs live, against the seven controls.
This chapter sets out the agent as wallet design as one choice among several, so that a supervisor can compare the choices on the same terms. Each pattern on this page uses open standards on the same federation. This page assesses only P1 against the seven controls, because only P1 runs here. The patterns differ in two things: where the authority and the enforcement sit, and how much technical work each party does. When the technical work moves, the trust decision moves with it. A simpler implementation often gives more delegated authority to one party. This can be the right choice. The tables show where each choice places that authority.
The seven controls
The same seven controls apply to each pattern. A pattern that carries no identity attributes, such as P3 or P5, leaves control 7 to each merchant.
- The agent is identified, and its operator and publisher are known.
- The person who gave the authority is identified.
- The authority has limits: amount, purpose, counterparty and time.
- A named party enforces the limits, not the agent.
- The person can revoke the authority, and the next request sees the change.
- Each action leaves evidence that a third party can verify later.
- Each party receives only the data it needs.
The six patterns
Only P1 runs live on this site. P2 to P6 are explained on the same trip, with the same parties, so the patterns can be compared on one scenario. P6 is a layer that a regulator or a scheme can add to any of P1 to P5.
| Pattern | Standards | Where the authority is held | Who enforces the limit | Technical burden | Where the design places trust and liability |
|---|---|---|---|---|---|
| P1. Agent as wallet (this demonstrator)Runs live on the demonstrator page |
|
Credentials in the agent, from independent issuers. | Each issuer for its own facts. The bank for spend. | High on the agent. Medium on each relying party, which must verify. | Spread across the issuers, the relying parties and the accredited Wallet Provider. No single party vouches for everything. |
| P2. Human wallet, one approval for each stepExplained, not run |
|
In the wallet of the person. | The person, at each step. | Low on the agent. The most work for the person. | Stays with the authentication of the person. The least delegated authority. |
| P3. Mandate held by the bank, OAuth onlyExplained, not run |
|
A grant at the authorisation server of the bank. | The bank. | The lowest. The agent is an OAuth client, and nothing else changes. | Concentrated at the bank. Identity attributes stay at the bank, so each merchant collects them separately. |
| P4. Approval on the bank channel for each actionExplained, not run |
|
At the bank, for each action. | The bank, through the approval of the person. | Low on the agent. Medium on the bank. | At the bank, for each authenticated approval. The agent has little autonomy. |
| P5. Operator issues delegated tokensExplained, not run |
|
At the authorisation server of the operator. | The operator. | Low on each relying party, which reads one token. | Moves to the operator, which vouches for its own agent. The operator needs strong accreditation. |
| P6. Nested ceilings published by the federationExplained, not run |
|
Three ceilings: a supervisor sets one for the agent type, the provider attests one for the running copy, and the person grants one for the task. | Each relying party checks all three ceilings. The request must fit inside the smallest one. | Low. The relying party resolves the ceilings and does not build them. | Each ceiling names the party that set it. A higher accreditation level can carry a higher ceiling, so delegated authority increases with accountability. |
P1 against the seven controls
The table shows P1 as this demonstrator builds it. A control reads shown only while the demonstrator page shows it, from a live or a recorded reading. When the logs of the relying parties hold no run of that step, the control reads shown after a run.
| Control | State | What the demonstrator does | Which party provides it |
|---|---|---|---|
| 1. The agent is identified, and its operator and publisher are known. | Partly shown | The Wallet Provider attests the agent instance, and the wallet scheme accredits the Wallet Provider. The Wallet Provider also names its authority in the Connect directory. A relying party that resolves the operator and the publisher of the agent is a later step. | Wallet scheme, Wallet Provider |
| 2. The person who gave the authority is identified. | Shown | The traveller signs in at the bank. The airline and the hotel check that the task mandate names the passport holder or the guest. | Bank, airline, hotel |
| 3. The authority has limits: amount, purpose, counterparty and time. | Partly shown | The bank enforces the amount, the payee, the purpose and the service dates that the agent approved, inside the mandate limit and trip window. The airline and the hotel check the purpose and the trip window. The mandate names no counterparty, so it does not limit the payee. | Bank, airline, hotel |
| 4. A named party enforces the limits, not the agent. | Shown | When the bank stops a payment that is more than the limit, it names itself and both amounts (run N3). | Bank |
| 5. The person can revoke the authority, and the next request sees the change. | Not shown | Not shown in this demonstration. | None |
| 6. Each action leaves evidence that a third party can verify later. | Not shown | Not shown yet. The relying parties keep their results in memory, and the open view keeps no presentation. | None |
| 7. Each party receives only the data it needs. | Shown | The minimisation matrix and run N2. | Each relying party, and the agent |
What the federation gives each pattern
Each pattern needs the same two statements from the federation, whatever carries the authority. The first statement says who the agent, its operator and its publisher are, and what each one is accredited to do. The second statement says which issuers, banks and schemes a relying party can trust, and for what.1 A regulator can therefore choose to supervise at the federation layer, through accreditation levels, trust marks and ceilings, in addition to or in place of a review of each implementation.
Where the design places liability
This page describes where each design places trust and liability. Scheme rules, contracts and regulation set legal liability. The technology does not set it.
Engineer notes on P5
P5 is the token exchange path with an act chain.2 The relying party reads one token, in which the act claim names the agent that acts for the subject. This page explains P5 and does not run it.
Questions for schemes and supervisors
The comparison raises four questions for schemes and supervisors. Each question applies to every pattern.
1. Which accreditation level does an agent, its operator and its Wallet Provider need before a relying party accepts it, and which party sets that level?
2. Which party records the evidence of each action, so that a third party can verify it later (control 6)?
3. How does a change or a withdrawal of the authority of the person reach the next request (control 5)?
4. Which party sets each ceiling in P6, and how does a relying party find it?