Limitations

The demo works, so the question is not "can this be done". It is "what are we signing up for". This page is the answer, ordered so that the things you cannot engineer away come first.

Each item states the constraint, what it costs, and what (if anything) can be done about it.

#The wallet thinks it is talking to the Connector

Structural on iPhone. On Android, solvable in principle and dependent on wallets. This is the single most consequential item on the page and everything below it is, to some degree, a consequence.

When the Connector calls the API, the browser tells the wallet the origin that called, and that is the Connector's. The signed device response is bound to that origin. On the iPhone protocol, the reader credentials are the Connector's too, and there is nowhere else for a name to appear. A user proving their age to a bottle shop sees a consent screen naming an identity infrastructure component they have never heard of, and is asked to approve handing it their licence details.

On Android the picture is better, because the protocol carries a signed request, and ConnectID as Trust Controller signs that request for the relying party. A wallet that reads it shows "Wattlebrook Cellars · via ConnectID" — the demo's does, on a device, with the Connector nowhere in the frame. A wallet that does not read it shows the Connector, and is conformant in doing so. So the relying party's identity is in the exchange on one platform, in a slot the wallet may ignore.

What that costs:

• Consent quality. A user who cannot tell who is asking cannot meaningfully agree. This is a legal exposure as much as a design one: informed consent is not a nicety in the Australian privacy regime, and a screen that names the wrong party is hard to defend as informed.
• The wallet cannot help. Wallets are being built to make per-requester decisions: this requester may ask for age, that one may not. If every request arrives wearing the same face, the wallet has nothing to reason about, and the protections it offers users are neutralised across the whole of ConnectID's traffic.
• It may become non-conformant. The direction of travel in wallet governance, here and overseas, is towards more relying party accountability, not less. A pattern whose defining feature is that the relying party is invisible to the wallet is swimming against that current.

What can be done splits by platform. On Android, the federation-signed request is the designed answer, and the work is ecosystem work: getting wallets to trust ConnectID's anchor and to render what the signature says. That is a standards and relationships task, not an engineering one, and it is the single most valuable thing ConnectID could pursue. On iPhone, nothing in the current protocol carries a second party; the Connector's domain and display name can be chosen to carry recognisable meaning, which converts an unknown name into a known one but does not convey which relying party. If the relying party must be named to an iPhone wallet today, the relying party must call the API itself, and the architecture changes.

#A licence carries no account identifier

Structural. A mobile driving licence is a set of attested attributes. It is not an account, and it contains no stable, privacy-preserving identifier for the person holding it.

This breaks something ConnectID's relying parties rely on. They expect a stable subject identifier so that a returning user is recognised as the same user. A bank identity provider supplies one naturally, because there is an account behind it. A licence presentation supplies nothing of the sort.

There are three ways out and all of them cost something:

Every path leads to the Connector retaining personal information. That is the finding here, and it should be stated plainly to anyone who believes this pattern is a routing change: it is not possible to support returning users through this flow without ConnectID holding data about them.

If the flow is only ever used for one-shot verification (prove your age, prove your name once at onboarding), the problem disappears. That constraint is the cheapest answer available.

#The Connector sees everything, in the clear

Structural, and the most significant item on this page for ConnectID specifically. It deserves stating carefully, because it is a change of kind rather than of degree.

Today ConnectID is not in the data path at all. The identity flow runs directly between the relying party and the bank; every protocol endpoint is on a bank domain. ConnectID is the trust root of the federation: it operates the directory, the certification scheme, the chooser component and the rules. It sees transaction metadata pairing relying party with provider, but it does not see, and cannot see, a single personal attribute. That is the property AP+ markets, and it is real.

The connector pattern preserves that for ConnectID's federation role — the Trust Controller signs the request and never sees the response — and breaks it for whoever operates the Connector. The wallet's response is encrypted to the verifier's key, and the verifier is the Connector. It must decrypt and verify to do its job. There is no arrangement in which the Connector performs verification without seeing the contents in the clear.

So the honest statement is: the Connector sits in the data path and sees complete identity documents for every user taking this route, and if ConnectID operates the Connector, then for the first time ConnectID does. Anyone who has been told ConnectID never sees customer data has been told something true, and that choice decides whether it stays true.

The available answers are about retention and separation, not about avoiding sight: process in memory and discard, hold the verification result but not the data, or segregate the Connector so that its data holdings are legally and operationally distinct from ConnectID's federation role. All three are viable. None of them restores the current property, and the marketing claim would need revisiting whichever is chosen.

Note the tension with the item above. The identifier problem pushes towards retaining data; this item pushes towards discarding it. They cannot both be satisfied, which is why the "one-shot verification only" option keeps looking better.

#The chooser implies an equivalence that does not hold

Structural, and mostly about assurance. A bank identity provider asserts an identity it verified at account opening, maintains, and can revoke. It also knows that the person authenticating is the account holder.

A licence presentation asserts something narrower: that this device holds a genuine licence credential and was unlocked to present it. Unless a face comparison is performed against the portrait in the credential, nothing establishes that the person presenting is the person the licence describes. A device that is unlocked by a family member presents just as successfully.

Two tiles side by side on the same screen say to the user, and to the relying party consuming the result, that these are alternatives of equal standing. They are not, and if the difference is not carried through in what the Connector asserts, relying parties will make decisions on a stronger footing than the evidence supports.

There is a fix, but it is not free: assert the difference honestly in what comes back (a lower assurance indication, an explicit statement of what was and was not checked) and let relying parties decide. That means some relying parties will decline the new tile, which is the correct outcome.

#"The Digital Credentials API" is not one API

Platform, and not converging soon. This is the finding most likely to surprise people, including technical people, and it comes straight out of building the thing.

Apple and Google have implemented the browser call with the same shape and different insides. iOS and Android use different request protocols, with different cryptography, and the two are incompatible by design rather than by accident. A verifier cannot write one implementation and reach both. It writes two, and maintains two, and tests two, forever. Or it picks one and excludes the other half of the market.

The demo proves this the hard way: the verifier implements both protocol families because there was no other way to reach both platforms.

What that costs:

• Roughly double the verifier engineering, in the least interesting place: cryptographic plumbing that delivers no product value and cannot be skipped.
• Two sets of failure modes to diagnose, on platforms that report failures vaguely (see below).
• A permanent dependency on two vendors' roadmaps, either of which can change its half without reference to the other.

This is an argument for the connector pattern, and it should be made. If every relying party had to solve this individually, most would solve it once, badly, for one platform. Solving it once centrally and correctly is arguably the clearest engineering justification the pattern has.

#Chrome and Safari disagree today about which origin counts

Platform, unresolved, and the most important technical fact on this page for anyone choosing an architecture. It is also the least widely known, so it is worth setting out carefully.

The specification contemplates a broker. Its own worked example is a relying party embedding a third-party verification service in a frame and granting it permission to make the call. That is close to what ConnectID would want, and it has a property the redirect model lacks: the delegation is visible, granted by the relying party, and enforced by the browser.

The problem is that the two shipping browsers currently bind a different origin when the call comes from an embedded frame. One binds the frame's origin — the broker. The other binds the page's top-level origin — the relying party. The signed response commits to whichever the browser chose.

The consequence is not subtle. The same deployment works in one browser and fails in the other, because the verifier prepared its request against one origin and the wallet signed to the other. This is a known, tracked defect with a proposed fix, and the fix is not merged. Part of what blocks it is that the cross-device path can only carry one origin at all, so there is a lower-level constraint underneath the specification problem.

What follows for ConnectID:

• Do not commit to the embedded-frame architecture yet. It is the better design on governance grounds and the specification points at it, but it does not work reliably across browsers today.
• The redirect model the demo uses sidesteps this, because there is only one origin involved. That is an accidental advantage rather than a designed one, and it is worth knowing that the safer-looking architecture is currently the one that works.
• Watch this specific issue. When it resolves, the architecture decision should be revisited, because the embedded model answers several of the governance objections that the redirect model cannot.

#What it takes to be allowed to read a licence at all

Governance, and it is two commercial relationships rather than a technical task. Neither platform lets any website read a credential. Both gate it, by different machinery, and neither gate is operated by the body that issued the licence.

Apple's path runs through a business programme: register a brand, prove ownership of a limited number of domains, declare the document types, the regions and the specific data fields wanted, evidence the existing verification process, and receive a certificate that expires annually. Changing the use case, adding a region or asking for another field requires going back for approval.

Google's path runs through a relying party programme: build against a sandbox, record a video of the complete flow, submit for review, and receive both a certificate and a per-party token that must accompany every request. Its terms reserve approval of use cases to Google, prohibit deviation after launch without written agreement, and permit termination at any time.

Three things follow, and management should hear all three.

This is a commercial dependency, not an engineering one. The ability to run this flow rests on two agreements with two platform vendors, either of which can be withdrawn.

The concentration is real. If the Connector holds one identity under each programme on behalf of every relying party, a suspension takes them all down together. That is decisions question 3 with a price attached.

Whether an Australian entity can enrol at all is not confirmed. Apple's programme is documented without a stated geographic scope, and its wallet currently carries no Australian credentials. This is a question to put to the vendors directly before any commitment is made, and it is listed as unresolved on Specs and sources.

#On iPhone, only one credential format works

Platform, and it constrains the roadmap rather than the demo. Third-party wallets on iOS can present mdoc credentials (the format a mobile driving licence uses) and cannot present the other major credential format through this API.

For the flow described on this site, that is survivable: a driving licence is an mdoc, so the demo works on iPhone. The consequence is for what comes next. Any ambition to carry other credentials through the same channel (a qualification, a concession entitlement, a proof of employment, most of which are heading towards the other format) excludes every iPhone user until Apple changes position.

Worth knowing before a roadmap is drawn that assumes this channel generalises. It generalises on Android. On iPhone it currently carries licences and not much else.

#The in-app browser problem

Platform, but stubborn. A large share of traffic to relying parties arrives inside an embedded browser: a link opened from an email client, a social app, a messaging app. These embedded browsers frequently do not expose the API.

The redirect model makes this worse rather than better. Because the user is redirected into the Connector, the Connector inherits whatever browsing context the journey started in, and neither ConnectID nor the relying party chose it. The user taps the tile, arrives at the Connector, and the API is simply not there.

What can be done: detect the absence and fall back gracefully; where the platform allows it, prompt the user to reopen in a full browser, accepting that this is an unpleasant thing to ask mid-flow. What cannot be done is control the context, which is why this belongs in a plan rather than in a backlog.

#Errors are opaque by design

Platform, and unlikely to change: the opacity is the point. When the call fails, the site is told very little. It cannot reliably distinguish "this user has no digital licence" from "this user changed their mind" from "the wallet errored".

That is a deliberate anti-fingerprinting measure and it is the right call for the web, but it has two practical consequences for ConnectID:

• Graceful degradation is guesswork. After a failure the Connector must choose between sending the user back to the chooser and offering a different route, without knowing which failure it just had.
• The tile cannot be shown conditionally. There is no way to ask "does this user have a licence" before offering the tile, so it must be offered to everyone, including the majority who cannot use it. Every one of those users experiences a dead end.

This bit the demo, and the episode is worth keeping because it is exactly what production will look like. Getting the iPhone path working took reissuing the verifier's reader certificates: the deployed certificate lacked one identifier field, so the phone could not match the request to any credential it held. The symptom was "no eligible IDs" — no error, no log line, nothing on either side saying why. The first diagnosis blamed a different certificate and was wrong; the fix only landed once someone worked out that the wallet had been finding the root all along and was failing one step later. A silent failure with a one-field cause, on a platform that reports nothing, is the operating reality this item describes, and it should be budgeted for.

The design response is to treat the new tile as an offer that must always be abandonable, and to make abandoning it cost the user nothing. Never let it become a path a user can get stuck in.

#It is an accelerator for a minority, not a replacement

Platform, and in Australia the position is starker than "a minority". A user needs a digital licence, provisioned into a wallet the browser can reach, on a supported operating system version, in a supported browser. Each is a filter and they multiply.

Here is the part that changes the planning conversation, and it took verification against primary sources rather than assumption:

One Australian jurisdiction has a licence built to the international standard and available at scale; a second is in limited early access; others are committed with dates ranging from late 2026 to late 2027, and several have not committed at all. The detail, with sources, is on Specs and sources.

So the honest position today is not that a minority of users can complete this flow through a platform wallet. It is that essentially none can, and the route that works runs through a government app rather than through Apple or Google. The demo works because it uses a purpose-built wallet.

Two planning consequences, and they point in different directions.

Do not build a business case on volume. For the foreseeable future every journey needs a complete non-wallet path, and this one sits alongside it. Anything assuming displacement rather than addition is wrong.

But the timing argument is stronger than the volume argument. The standards, the national trust list and the state rollouts are all moving. Being ready when coverage arrives is a defensible reason to do this work now. Being ready is not the same as launching, and the two should be costed separately.

#Desktop needs a second device, and we could not make it work at all

Platform. Desktop browsers have no wallet, so a desktop user must involve their phone, typically by scanning a code, which is the experience this API was partly meant to replace.

The stronger finding is from trying it. The cross-device path (desktop browser hands off to a phone over a short-range transport) did not work in our environment, and we do not currently expect to be able to demonstrate it. That is not proof it never works, and the walkthroughs will show the attempt rather than assert the conclusion. But a path that a well-resourced team could not get running on purpose is not a path to build a business case on.

Given how much relying party traffic is desktop, this materially narrows where the flow is viable. It is at its best on a phone, in a real browser, for a user who already has a licence provisioned. That is a specific and much smaller population than "our users".

#Every use needs a fresh consent

Structural, and easy to underestimate. There is no stored token, no silent re-presentation, no refresh. Each use is a fresh, user-consented, biometric-gated presentation.

For establishing identity once, that is correct and desirable. For repeat authentication (the thing relying parties actually want after the first visit), it is heavier than a password and much heavier than a passkey. Positioning this as an authentication method rather than a verification method will disappoint everyone.

#The data request has to be someone's decision

Governance. The request names the fields wanted. So does the Connector ask for one broad set that serves every relying party, or vary it per relying party?

Ask broadly and you over-collect for almost every journey, which forfeits the selective disclosure advantage that is one of the best things about this technology. Vary it per relying party and the shape of the request starts telling the wallet what kind of relying party is behind it (a request for age_over_18 alone is a fairly clear signal), which erodes the blinding the pattern exists to provide.

There is no clean answer. There is a defensible one: vary the request, accept the partial signal, and be able to explain why. What is not defensible is asking for everything because it was simpler.

One trap deserves naming, because it is invisible on the wire and easy to fall into. Minimal disclosure is a choice the verifier makes on every request, not a property the credential enforces. A verifier can ask for the single fact age_over_18 and the holder's name from the same credential; the request is valid, the response is complete, and the holder has been re-identified while the verifier keeps the branding of not having done so. The demo requests only the boolean, deliberately. The consent screen is the one place this shows — one line, or three — which is why the request shape belongs where the holder can see it and not only in a policy document.

#What worked better than expected

A page of nothing but problems is not a fair account and does not get believed, so four things that went right.

The redirect model fits the API well. After the wallet finishes, control returns to the original browser tab. There is no lost context, no orphaned window, no "return to your browser" instruction. The connector pattern depends on a redirect round trip, and the API happens to accommodate that cleanly.

Selective disclosure is real and it is good. Proving a single fact and revealing nothing else works exactly as advertised, and it is a clear improvement on photographing a licence. Whatever is decided about the architecture, keep this capability.

For a relying party already on ConnectID, the integration burden is zero. This was the claim most likely to collapse on contact with implementation, and it did not. A new provider registration is the whole of it. (A relying party joining for the first time integrates once, as it would for any provider.)

It fails closed. The demo deliberately offers an unencrypted response mode as a comparison probe, to see what happens when a verifier asks for something it should not have. It is refused. Responses stay encrypted whether or not the request was signed, and the refusal is a flat rejection rather than a silent downgrade.

That is worth more than it sounds. A protocol that quietly degrades when one party misconfigures itself is a protocol that will be misconfigured in production and nobody will notice. This one stops.

#Reading the list back

Five are structural and will not improve with time: the wallet cannot see the relying party, the licence carries no identifier, the Connector sees the data in the clear, the chooser overstates the equivalence, and every use needs a fresh consent. Design around these or change the architecture. Do not wait them out.

Seven are platform constraints that will improve, but on Apple's and Google's timetable rather than ConnectID's: the two incompatible protocols, the origin disagreement between browsers, the iPhone format restriction, in-app browsers, opaque errors, overall availability, and desktop. Plan for today's behaviour and re-check the support matrix each planning cycle rather than assuming either progress or stasis.

Two are decisions rather than problems — what gets requested, and who holds the platform relationships that make reading a licence possible at all. Both sit with the rest of what needs answering on Decisions for ConnectID.