Evidence: Your own assistant
Your own assistant. Trusted by your bank.
A customer wants their own assistant to reach their bank. What does the bank trust, and who decides?
Available Raidiam Connect
The bank admits the software on its first call
-
Raidiam Connect
The authority
- Raidiam Connect to The connector: Subordinate statement And a connector trust mark
-
The connector
One federation entity for every instance
- The connector to Your bank: First call Its client ID resolves through federation
-
Your bank
Resolves the connector up to Connect
Client record in advance None
Raidiam Connect publishes a subordinate statement about the connector and a connector trust mark.
How the admission works
On the first call, the bank resolves the connector's client ID through federation, so it needs no client record for it in advance.
This is OpenID Federation automatic registration. After the first resolution the bank may keep a cached client entry. The connector is one federation entity, and the bank's authorisation server names the same authority. An instance is not a federation entity. It has its own key, and the bank admits it for a customer only after that customer paired it on the phone.
A metadata policy in the federation narrows the grants the connector may request. The policy is configured on the live estate. Its narrowing effect was proven in a test harness against a stand in for Connect, not observed live.
Pairing, and the grant it approves
-
The connector
One instance on your Mac
-
Your phone
Your bank's app
-
Your bank
Server and gateway
-
Step 1
Checked by your bank. The connector to Your bank: Asks for a device code Bound to its attestation key
-
Step 2
Your bank to The connector: A device code and a user code
-
Step 3
The connector to Your phone: QR code Scanned in your bank's app
-
Step 4
Checked on your phone. Between Your phone and Your bank: Looks up the request The instance key matches the QR code
-
Step 5
Between Your phone and The connector: Bluetooth step Signs a proximity token
-
Step 6
Checked on your phone. The connector and Your phone: Same code on both screens You compare them 48 29 15
-
Step 7
Your phone: Choose accounts
-
Step 8
Your phone: Face ID
-
Step 9
Checked by your bank. Your phone to Your bank: Consent Signed by the phone's key, with the proximity token
-
Step 10
Checked by your bank. Between The connector and Your bank: Collects the token Its DPoP key matches the attestation key
-
Step 11
Between The connector and Your bank: Reads your accounts Read only
Pairing is how the customer approves one OAuth 2.0 Device Authorization Grant.
Each step, and who checks it
The customer approves it on the phone, not at a web address. It is not CIBA.
The connector asks for a device code and authenticates with its instance attestation, so the bank binds the code to the instance key. The phone scans the QR code and looks up the request at the bank. The bank returns the instance key, and the phone checks that it is the key the QR code names.
In the Bluetooth step, the instance key signs a proximity token for the phone. The bank checks that token inside the consent. It does not show where the phone was, and the review of the pairing code found that it is not yet bound to the approving phone.
The bank never sees the matching code. Both screens compute it, and the customer compares them. The customer then chooses accounts and approves with Face ID, and the phone signs the consent with its own key. The bank checks the consent against the phone's registered key, the user code and the instance key. At the token, the bank checks that the connector's DPoP key is the attested instance key.
These checks come from a review of the pairing code at named branch heads. They are not each verified on the live estate.
Two keys, vouched for differently
Only the phone's key is attested.
The phone's key
Held by your bank's app
- Used by
- Your bank's app, after Face ID
- Signs
- The consent and DPoP proofs
The instance key
Held for the connector on your Mac
- Used by
- Any process of your Mac user
- Signs
- Its attestation proof and DPoP proofs
Each device holds its own key.
Who holds each key, and who vouches for it
Only the phone's key is attested.
Raidiam's hosted attestation service attests the bank's app on the phone with the phone platform's own app attestation. By default the bank requires that level for the phone.
The attester signs a statement that binds the Mac's instance key to the connector at the asserted level. The Mac sends no hardware evidence that the bank can check, so this site does not call the Mac key attested. Any process that runs as the same Mac user can ask the key to sign.
On the live run on 28 September, both keys were held in their device's hardware. That is deployment evidence, stated by the operator. Raidiam holds neither private key.
Connect accredits the attester that vouches for an instance
The statement names the key. The pairing decides which customer it acts for.
-
Raidiam Connect
The authority
- Raidiam Connect to The attester: Trust mark Accredited as an attester
-
The attester
Publishes its keys through federation
- The attester to One instance: Signed statement Asserted for this key
-
One instance
Its own key on your Mac
- One instance to Your bank: Presents it At authentication
-
Your bank
Reads the attester's keys through federation
An attester holds a trust mark that Connect publishes, and it publishes its attestation keys in its own entity configuration.
What the attester's statement shows
The bank reads those keys through federation.
The attester binds each instance key to the connector at the asserted level. Any process that reaches the attester gets such a statement for its own key, so the statement does not show that an instance is a genuine connector. The pairing decides which customer an instance may act for.
What this page proves
Each claim, its label and the artefacts behind it.
This use case is Available and carries no row in the capability matrix yet. No capture of the live pairing is linked, because every capture names the bank tenant it ran on.
This page carries no declared read. The evidence page lists every read the site declares.
The working
What the figures above leave to words.
What it means for the business
A customer already uses an AI assistant, and wants it to read their own accounts at their own bank. The bank needs two things before it lets that happen: to know what the software is, and to hear the customer approve it on their own phone.
The connector gives the bank both. The assistant reaches the bank only through the connector. The bank admits the connector as a governed identity, and the customer approves the connection on their phone, in their bank's app.
Where the authority comes from
The bank admits the connector the same way it admits any agent from outside: it resolves the connector's trust through federation, with no client record at your bank in advance. Then the customer's pairing on the phone decides which instance may act for them.
The software is the governed identity. An instance is one running copy of it. The publisher builds the connector, and federation vouches for it. Connect accredits the attesters that vouch for an instance, and the customer's consent decides which connection the bank holds.
The inbound use case walks the same admission for an agent that arrives at a platform for the first time.
Ten terms
- anchor
- The root entity of a trust domain whose key a consumer pins from configuration.
- authority
- A Connect entity that publishes signed subordinate statements, marks and policy about the entities it governs.
- trust domain
- The set of entities that chain to one anchor.
- entity configuration
- The self signed statement an entity publishes at its own identifier.
- subordinate statement
- The statement a superior signs about a subordinate: keys, policy, marks.
- trust mark
- The signed projection of an active accreditation, with a status endpoint.
- envelope
- The set of authorization detail types and grant types an authority permits an agent to request. The registered ceiling.
- resolve
- Walk the chain from a leaf to a pinned anchor and fold the policy.
- pin
- The anchor key a consumer holds in configuration, written at deploy time, as the pair of anchor identifier and key.
- recognition
- The governed act by which an authority becomes a superior of an entity that already publishes its own configuration, minting nothing.
What this page does not show
This page does not show payment approval, revoking a connection, stopping an instance or withdrawing the publisher. None of these is the claim here, and none is shown as live.
Why the label reads Available
Raidiam Connect admits the connector through federation today, and the same attestation software already runs for clients' wallets. No capture of the live pairing is linked, because every capture names the bank tenant it ran on. So nothing on this page is marked Observed.
Which of your customers would bring their own assistant first, and what would your bank need to trust it?
Ninety minutes, on the shape of your estate: which systems resolve first, which anchor each pins, and which key each party holds.
Book a working sessionExplore further