Context
What everyone else is doing
Europe, the United Kingdom and the United States have all decided how a broker fits into wallet-based presentation. All three made room for one. None of them requires it to be blind — which is the finding that matters most for ConnectID.
Sourced — see Specs and sources
"What is everyone else doing" is a fair question and the answer is more useful than expected, because three jurisdictions have addressed exactly this and reached compatible conclusions.
The direct-presentation model has not excluded brokers. It has re-specified them. Every framework examined makes room for an intermediary — and not one of them requires that intermediary to be blind to the data passing through it.
ConnectID is therefore not unusual in wanting to be a broker. It is unusual in not being in the data path, and that is the property the connector pattern spends.
#The comparison
| Model | Broker in the data path? | Must it be blind? | Who authorises verifiers |
|---|---|---|---|
| ConnectID today | No — the flow runs directly between relying party and bank | Partly, in practice: no personal data, but it retains metadata pairing relying party with provider | ConnectID's own directory and certification scheme |
| Australia's government exchange | Yes | Yes — the exchange must not reveal the relying party to the identity provider | The regulator and system administrator |
| Europe — direct | No | Not applicable | Member state registrar |
| Europe — via an intermediary | Yes, and it sees attributes in the clear | No — end-to-end encryption past the intermediary is explicitly not required | Registrar, on evidence of the contract with each relying party |
| UK — government wallet, in person | No — direct device to device | Not applicable | Wallet certificate authority |
| UK — government wallet, online | Yes, and a certified broker is mandatory — a private relying party may not talk to the wallet at all | No | A register the wallet checks live, at the moment of presentation |
| US — the licence standard | No — bound to the requesting origin and encrypted to its key | Not applicable | Trust list of issuing authorities |
| US — Google's broker tier | Yes — the broker decrypts and forwards to the relying party behind it | No | Google approves the broker's root. Brokers behind brokers are refused |
Four rows are worth reading twice.
#Europe wrote the broker into the rules
Europe defines a relying party intermediary as a role in its own right, treated as a relying party and permitted to act for others, with registration requiring evidence of the relationship with each one.
The instructive part is what it does not require. The framework states plainly that attributes need not be encrypted end to end past the intermediary. The obligation is not to retain, rather than not to see. A European intermediary is expected to be sighted.
The registration burden is real and worth pricing early. Europe's own worked example has an intermediary of moderate size needing certificates in the tens of thousands. Whatever ConnectID builds, the certificate lifecycle is likely to be the operational cost that surprises people.
#The United Kingdom went further and made the broker compulsory
For online presentation from the UK government wallet, a private relying party cannot talk to the wallet at all. It must go through a certified provider, which receives the attributes in the clear and passes them on. The wallet checks that provider against a register at the moment of presentation, which is a genuinely strong control and one worth borrowing.
The UK's certification rules for that broker role contain no data-minimisation, blinding or non-correlation obligation whatsoever.
The UK previously built a blinded identity broker — architecturally close to ConnectID — and retired it. It failed on adoption rather than on principle, but the damage attributable to the blinding is specific and documented: because the broker was blind, it could not carry a record key, so every relying party had to build its own matching service. That integration burden is what killed take-up.
The lesson is not that blinding is wrong. It is that whatever separation ConnectID keeps, it must not push the matching problem onto relying parties. That is the exact mechanism by which the closest international analogue failed, and it connects directly to a licence carries no account identifier, which is the same problem arriving by a different route.
#Google chartered a broker tier, and closed the door behind it
Google's model for reading credentials from its wallet includes an explicit aggregator role: an approved broker holds the trust relationship, signs requests for the relying parties behind it, receives the encrypted response, and passes the result on. This is the closest structural analogue to the connector pattern anywhere, and it was designed recently with full knowledge of the API.
Two things about it matter here.
It is sanctioned but gated — Google approves the broker's root, so the ability to operate the pattern at all is a commercial relationship with a platform vendor, not a technical capability. That is the concentration risk from decisions question 3 with a name attached.
And brokers behind brokers are refused. Google's stated preference is to work with an aggregator and its own direct relying parties, not with resellers beneath them. ConnectID already has at least one relying party that is itself an identity aggregator serving its own customers. Under this rule that arrangement does not extend to wallet presentation, and it is better to know that before someone sells it.
#The Australian complication
Australia's own government exchange is required to blind: it must not disclose the relying party to the identity provider. ConnectID's model does not do that today, and does not need to.
Two dates make this concrete rather than academic. The government system opens to private-sector participants at the end of 2026, and the Commonwealth's verifiable credentials policy work has already settled on aligning with the same international standards this demo uses.
Connecting ConnectID's federation to the government exchange is not a plug-in exercise. They run different profiles of the same underlying protocol, and the government profile carries blinding and identifier obligations that ConnectID's does not currently meet. If that connection is on the roadmap, the connector work and the government-system work are the same conversation and should not be scoped separately — both turn on what ConnectID's trust anchor is allowed to vouch for.
#What ConnectID should take from this
Being a broker is not the risk. Three jurisdictions have deliberately made room for one. Anyone arguing that wallet-based presentation eliminates the intermediary is not reading the frameworks.
Being a blind broker is a choice nobody else is making, which makes it a real differentiator and a real cost. It has to be sold on trust, because no framework will require competitors to match it.
Do not export the matching problem. It is the documented cause of the closest comparable failure, and the connector pattern reintroduces it by a different route.
The sanctioned shape is visible delegation. Where the specification contemplates a third-party verifier, it does so through an explicit, per-page delegation that the relying party grants and the user's browser enforces — a broker the relying party visibly chose, rather than an invisible relay. That is a different architecture from a redirect, and it is worth evaluating properly rather than defaulting to the redirect because it is familiar.