Decisions for ConnectID

Everything on Limitations is a constraint. This page is the subset that is actually a choice, framed so it can be decided rather than discussed.

The recommendations are ours and are meant to be argued with.

#1. Is this verification, or authentication?

The question. Is the wallet path for establishing who someone is once, or for signing them in repeatedly?

Everything else on this page gets easier if the answer is "once". One-shot verification means no returning-user matching, so no identifier problem, so no retained data. Repeat authentication means all three, and delivers an experience heavier than the passkey the relying party could have used instead.

Recommendation: one-shot verification. Establish the identity with the licence, then let the relying party's own credentials carry the relationship from there. This is the cheapest answer and it is also, on the merits, the right one: the technology is good at the first thing and mediocre at the second.

There is external support for this that is worth having in the room. The W3C's Technical Architecture Group published a finding in late 2025 stating that using government-issued credentials as a login credential is inappropriate, that refusing service to someone who cannot or will not present one is unacceptable, and that the web should not become a platform that demands identity documents in ordinary use.

That is the body responsible for the architectural direction of the web, saying in terms that the second answer to this question is the wrong one. If ConnectID answers "authentication", it should expect to be asked about that finding.

#2. What does the Connector retain?

The question. After a successful presentation, what is written down?

The options run from nothing at all (verify in memory, assert to ConnectID, discard) through keeping only a verification record without the underlying data, to keeping a full identity record so users can be recognised on return.

If question 1 is answered "verification", nothing needs to be retained beyond an audit record, and the answer here follows.

Recommendation: retain the minimum that supports audit, and nothing that supports matching. Then say so publicly, because the value of not holding data is mostly in being known not to hold it.

#3. Who holds the reader credentials?

The question. Reading a licence requires credentials issued under some authorising regime. Does the Connector hold one set on behalf of all relying parties, or does each relying party hold its own?

One set is far easier to operate and is the only version in which relying parties need change nothing. It also concentrates risk: a single suspension or revocation takes every relying party offline simultaneously, and it puts ConnectID in the position of vouching for the purposes of parties the issuer cannot see.

Recommendation: one set, held by the Connector, with the concentration risk stated explicitly in the risk register and a documented answer to "what happens if it is withdrawn". The alternative forfeits the pattern's main advantage. But this must be a knowing acceptance rather than an unnoticed one.

#4. How is the assurance difference expressed?

The question. A licence presentation without a face comparison proves less than a bank identity. Does what ConnectID returns say so?

If it does not, relying parties will treat the two as equivalent, because the chooser screen told them to.

Recommendation: say so, in a machine-readable way, from the first release. Relying parties that need the stronger assurance should be able to decline the new tile programmatically. Some will, and that is the system working.

#5. Is a face comparison in scope?

The question. Comparing the portrait in the credential against a live capture closes most of the assurance gap in question 4. It also introduces biometric processing, with everything that follows from it.

Recommendation: out of scope for now, and revisit only if relying parties say the assurance gap is what is blocking adoption. Do not add biometrics speculatively. But answer question 4 honestly in the meantime, rather than using a possible future face check to justify a present-day claim.

#6. What is requested, and who decides?

The question. One broad request that serves every relying party, or a request shaped per relying party?

This is the data request has to be someone's decision. Broad over-collects; specific leaks a signal about the relying party to the wallet.

Recommendation: per-relying-party requests, minimised to purpose, and accept the partial signal. Over-collection is the harder thing to defend, and the signal leaked is weak. Publish the mapping between relying party purpose and requested fields so the decision is inspectable.

One rule inside that: never pair a derived fact with an identifying field in the same request. Asking for age_over_18 and a name together re-identifies the holder while looking like an age check. The credential will not stop it; only the request policy will, and the consent screen is where a user would catch it.

#7. Where is the fallback, and who owns it?

The question. Most users who see the tile will not be able to complete the flow. What happens to them, and whose job is it?

Recommendation: ConnectID owns it, inside the chooser. The user should land back on the chooser with the other providers still available and nothing lost. A dead end inside a redirect the relying party did not control will be attributed to the relying party, then to ConnectID, and it will do more brand damage than the flow does good.

#8. How is the relying party made visible to the user?

The question. On iPhone the wallet consent screen cannot name the relying party. On Android it can, if ConnectID signs the request for the relying party and the wallet honours that signature. What is done about each?

Two surfaces are available. The signed request is the real fix where it works: it puts the relying party's name into the wallet's own consent screen, under ConnectID's authority, with no new field invented. And the Connector's own page, immediately before the wallet is invoked, is the one surface under the Connector's control at the right moment on every platform. It can name the relying party plainly ("Wattlebrook Cellars is asking you to prove you are over 18"), so the user has that context in mind when the wallet screen appears.

Recommendation: do both, from the first release, and pursue the wallet vendors on the first. Sign every request for the relying party even though most wallets will ignore it today — the ecosystem will not build support for a mechanism nobody is using. And treat the Connector page as a designed consent surface rather than a technical waypoint, because on iPhone it is the only place the relying party's name will ever appear. Neither should be described as fixing the structural problem on iPhone. Together they are the difference between a user who understands what is happening and one who does not, and they cost a screen and a signature.

#The one to settle first

Question 1. Everything else on this page is downstream of it, and it is the question most likely to be assumed rather than decided.