How this is being scrutinised

Everything on Limitations is about whether the pattern works. This page is about whether it will remain acceptable, which is a different question and on current evidence the more dangerous one.

#The specification says the quiet part out loud

The Digital Credentials API specification is a W3C Working Draft, most recently updated in August 2026. It now carries a threat model and a substantial privacy considerations section, and those sections concede most of the criticism the API has attracted.

The specification explicitly names over-asking as a problem: its own worked example is a site collecting an entire identity document when a selective age check would have done. It names exclusion of users who cannot or will not present a credential. It discusses the chilling effect of being asked, noting that the possibility of surveillance changes behaviour whether or not surveillance occurs. And it raises prompt fatigue: users habituated to approving requests stop reading them.

This matters for the connector pattern in a specific way. A pattern that puts one intermediary in front of many relying parties concentrates exactly the conditions the specification warns about: a single requester, asking often, for a request shape that has to serve many purposes.

#Browser vendors are not united

Support is not uniform, and the disagreement is about principle rather than scheduling.

Apple's browser team has supported the API, while recording concerns about users being asked for identification where a simpler mechanism would do, and about the issuer learning where a credential was used.

Mozilla has recorded a negative standards position. Its stated objection is that a web consistent with its principles respects the individual's choice about what identity to present, that few online interactions genuinely require identity, and that people may be excluded when they cannot or will not produce credentials. It also raises interoperability: a proliferation of formats risks excluding people whose wallet or provider is not among the ones a site chose to support.

That last point is the same finding the demo hit from the engineering side, arrived at from the opposite direction. See "the DC API" is not one API.

#Civil society has named the mitigations, and they all identify the requester

The Electronic Frontier Foundation's critique of the API is direct: the technology arrived without limits on what verifiers may ask, and the incentive is to ask for more than is needed simply because it is possible. Its objection to the trust model is that it assumes the verifier is trustworthy, asks narrowly, and does not retain. None of that is enforced.

The three mitigations the EFF asks for read as a checklist, and a connector answers two of them awkwardly:

The Center for Democracy and Technology frames the same territory around four harms to be prevented: over-asking, coercion, exclusion, and breach, with meaningful consent and accountability as the requirements. Its central observation is uncomfortable and applies squarely here: making it easy to present identity makes it equally easy to demand it.

A W3C editors' document on user considerations, co-authored from within CDT and Google, raises a further risk it calls consolidation: that user choice gets squeezed by the policies of intermediaries. It is written about platforms and operating systems rather than identity exchanges, but the mechanism it describes is the one the connector pattern deliberately creates.

#Europe legislated on this, and the result cuts both ways

Through 2026, European digital rights organisations campaigned for mandatory registration certificates, a mechanism whose purpose is to let a wallet check whether the party asking is entitled to ask for what it is asking for. In mid-2026 that campaign succeeded, and the European wallet framework now carries a protection against over-asking that had been optional.

Registration certificates work by binding a request to an identified, sector-classified relying party with a declared entitlement. On the face of it, a pattern in which one registered entity asks on behalf of undisclosed parties is what the mechanism exists to close.

But the same framework, in the same period, did two things that run the other way. It defines a relying party intermediary as a first-class role, treated as a relying party in its own right and permitted to operate. And it states explicitly that attributes need not be encrypted end to end past that intermediary — the obligation placed on intermediaries is to delete, not to be blind.

There is a third move worth knowing about, because it is the opposite of what most people assume. An earlier draft required the wallet to display the intermediary's name to the user. A mid-2026 revision removed that requirement. The drafting direction is towards showing the user less about the intermediary, not more.

So Europe has not built machinery to stop this pattern. It has built machinery to license it, on terms that assume the intermediary sees the data.

#What this means for the decision

None of the above is legal advice, and none of it says the connector pattern is prohibited. Three things follow.

The broker role is safe. The blinding is the exposure. Every major framework has made room for an intermediary; none requires it to be blind. ConnectID's not-in-the-data-path property is therefore a genuine differentiator rather than a compliance baseline — which cuts both ways. Nobody will force ConnectID to give it up. Nobody will give it credit for keeping it either, and keeping it costs money that competitors do not spend. See what everyone else is doing for how each jurisdiction has landed.

The exposure is to ConnectID's own story, not to a regulator. The uncomfortable question is not "is this permitted". It is what AP+ says to a customer who was told ConnectID never sees their data, about a flow in which the Connector sees all of it — if ConnectID is the one operating the Connector. That is a positioning problem with a communications answer, and it is much more tractable than a compliance problem, provided it is decided rather than discovered.

There is a version of this that survives, and we now know how far it reaches. If the Connector can pass the relying party's identity through to the wallet, most of this evaporates: the pattern becomes a technical intermediary rather than a substitute identity, while keeping the integration advantage that makes it attractive. We investigated exactly that, and the answer splits by platform.

#Can the relying party be named to the wallet?

This was the most valuable question the exercise raised, so it was put to the implementation rather than argued from first principles. The answer is a qualified yes on Android and a flat no on iPhone.

#On Android: possible, with three conditions

The protocol used on Android carries a signed request, and the signature can be checked against a trust framework rather than only against the web origin. This is the same machinery as the European registration certificates discussed above, which is a strong signal that it is the right place to look.

ConnectID's federation gives that slot a concrete use. The Connector does not sign the request itself; it asks ConnectID, as Trust Controller, to sign the credential query for the relying party. The request the wallet receives therefore names the relying party as the verifier, under ConnectID's anchor. No "on behalf of" field has to be invented — the relying party simply is the named party, and the Connector is the origin running the ceremony.

Three conditions attach:

1. The wallet has to trust ConnectID's anchor. A wallet checks the signature against trust roots it knows. Getting ConnectID's federation onto that list is ecosystem work with each wallet vendor, and it has not been done.
2. Whether the wallet uses it is the wallet's choice. The specification leaves it to the wallet's discretion. A wallet that ignores the signed request shows the user the Connector's origin and nothing else, and it is conformant in doing so.
3. It therefore cannot be relied on unilaterally. ConnectID can sign the request. It cannot make anyone display what the signature says.

The demo shows this working, on a device. The same ceremony was run twice on the Android wallet: once with a request the Connector signed itself, once with the request ConnectID's stand-in Trust Controller signed for the relying party. The first consent sheet reads "Unknown requester". The second reads "Wattlebrook Cellars · via ConnectID", with the wallet stating that the requesting application is trusted — and the Connector appears nowhere in the frame. The name is produced by the wallet's own consent interface, fed by a real trust-resolution hook that walked the chain to the anchor; it is not painted on.

That pair of frames is on the walkthroughs page and it is the most important image on this site. It is also the limit of the finding: the demo wallet was built to trust the demo anchor, so it demonstrates that the mechanism exists and functions, not that a platform wallet would honour it in the field.

#On iPhone: no, structurally

The protocol iOS uses carries the verifier's identity as a certificate chain and has no field for a second party of any kind. The operating system hands the wallet the browser-authenticated origin of whoever called the API, and that is what the wallet has to show.

There is no profile that fixes this and no cooperative wallet that works around it. On iPhone, the consent screen names the Connector, and the argument on this page applies in full and without qualification.

#What follows

The pattern is defensible on one platform, conditionally, if wallets come to trust ConnectID's anchor and choose to render what its signature says. On the other platform it is not defensible at all with today's protocol.

That is a position ConnectID can act on, unlike "this is a governance risk". It says: if ConnectID wants the connector pattern to have a future, the work is standards and ecosystem work (getting a profile agreed and getting wallets to render it), not engineering work. And it says that until Apple's path changes, a material share of users will see a consent screen that does not name the party they are actually dealing with.

That question is the eighth item on Decisions for ConnectID, and this page is the argument for treating it as the first.