The live demo

#A note on honesty

Demos usually contain simulated parts, and a reader is right to ask which. In this one the answer is unusual: there are none. Every scenario either runs end to end against real components on a real device, or it has not been built and says so.

That is deliberate. A demo with convincing stubs produces decisions a production system cannot support, and this exercise exists to find the places where reality does not cooperate. Stubbing those places would defeat the purpose.

The same discipline applies to failures. When a scenario fails, the demo records the exact error the page received and keeps it. Failures are results here, not defects.

#What is deployed

The demo is live at connectid-connector-production.up.railway.app.

It is now styled to ConnectID's published brand guidelines, which makes the journey feel authentic and creates an obligation to be unmistakable about what it is. Every page carries a notice that it is a demonstration and not an official ConnectID service, running on test credentials and test data, plus the required trademark attribution. The ConnectID symbol is not redrawn anywhere, because the guidelines prohibit recreating brandmark elements.

Please do not circulate screenshots of it without that context attached. A convincing-looking ConnectID screen showing a licence being read is exactly the sort of image that travels further than its caption.

#The Connector AS

Throughout this site, Connector AS is the name for the role: the component the relying party reaches as one more provider on the chooser, under ConnectID's federation, and that turns around and acts as a verifier towards the user's wallet.

Its job has three parts. It resolves the relying party's trust chain through ConnectID to learn who is asking and what they are entitled to. It has ConnectID, as Trust Controller, sign the credential request for that relying party. And it runs the presentation ceremony, verifies what comes back, and returns the claims.

In this demo the role is implemented as an authorisation server with an adapter that turns a wallet presentation into a login, plus a stand-in for the Trust Controller's signing step. That is an implementation detail and other implementations are possible.

#The three axes it tests

Format — the mobile driving licence format, against the other major credential format. Protocol — the ISO path that iPhone speaks, against the OpenID path that Android speaks. Surface — same-device in a browser, native app to app, and cross-device by QR.

Testing the full grid rather than one happy path is what produced the findings on Limitations. Most of them only appear when you try the combinations that do not work.

#The cross-origin experiment

The demo includes a purpose-built test of the one unresolved question that decides the architecture: when the call is made from inside an embedded frame, which origin does the browser bind?

The page states its prediction before it runs — Chrome should verify, Safari should fail — and records either outcome. That is the right way round. A test that only records the result it expected is not a test.

Either result is a data point on an open specification issue, which is worth more than a citation. Background on why it matters is under Chrome and Safari disagree about which origin counts.

#What works today

Proven on a real device, not in a simulator:

• A licence presented from a phone wallet to a website through the browser API, and verified cryptographically — on both platforms. The iPhone path runs the full journey on a real device: the system picker offers the licence, the consent sheet leads with the requester's origin, and the presentation verifies.
• Issuance of credentials into the wallet, in both major formats.
• The older cross-device path, by QR, which remains the fallback.
• Both protocol families, which is what it takes to reach both platforms.

#What is still being built

A native iOS verifier, the empirical runs of the cross-origin experiment on both platforms, and the full round trip on the Android app-to-app surface — which currently completes the consent step and then fails on the response leg, where the protocol binds the response to the calling application's identity. That failure is recorded in the matrix as a result, not hidden. The browser path is where the full verification is expected to go green once the emulator's browser can be updated.

#The Trust Controller stand-in, and what it proved

The Trust Controller is a small service holding the demo's "ConnectID" anchor key, publishing the federation statements for the relying party, and signing credential requests on its behalf. The signing authority sits there, not in the Connector — the Connector never holds the key that names the relying party. The federation machinery underneath (resolving trust chains, validating statements) was already built and tested in the platform against a three-tier test federation, including forged and expired chains; the stand-in wires it to this journey.

It is wired and running, and the Android wallet walks the chain to the anchor on the device. The same ceremony run under a Connector-signed request produces a consent sheet reading "Unknown requester"; run under the Trust Controller's signature it reads "Wattlebrook Cellars · via ConnectID". Both frames are on the walkthroughs page.

Two points of accuracy that should travel with any use of those frames. The name on the consent sheet is rendered by the wallet framework's own consent interface, fed by a real trust-resolution hook; it is not an overlay painted for the camera. And the wallet's federation validation is demo code written for this exercise, not a stock feature of the wallet framework — the demo wallet was built to trust the demo anchor, and the frame carries a banner saying so. That shows the mechanism works. It does not show that a platform wallet would do the same.

One more thing worth recording: the change that wired this in went through the platform's review gate, and the reviewer caught a real weakness — the check on the request's metadata was comparing a label rather than the whole canonical structure — and it was fixed before merge. That is evidence the demo is being built to the standard the findings depend on, not as a happy-path toy.

#Why the demo uses its own wallet

This looks like a shortcut and is not. No Australian digital licence can be added to Apple Wallet or Google Wallet. For an Australian credential, a purpose-built wallet is not a stand-in for a platform wallet that would otherwise work — it is currently the only thing that works at all.

#Trying it yourself

The prerequisites are not trivial: a supported phone, a supported operating system version, and a wallet with a test credential provisioned from the landing page. That the list is this long is not an inconvenience around the finding. It is one of the findings.