Working explainer
ConnectID and the Digital Credentials API
What it would mean for ConnectID to accept a state digital licence through the browser's Digital Credentials API, using a Connector that joins the ConnectID federation as one more provider.
This site accompanies a working demo. The demo shows a user starting at an ordinary relying party, choosing a new tile on the ConnectID chooser screen, and proving who they are with the digital driver licence already on their phone: no bank login, no app download, no redirect to a government website.
It works. That is the easy part, and the video walkthroughs show it working end to end. The harder and more useful part of this exercise is what the demo reveals about the shape of the problem, and that is what most of this site is about.
The browser's Digital Credentials API is designed for the party that wants the data to ask the wallet directly. In the connector pattern, the party that wants the data is the relying party, but the party that asks is the Connector. ConnectID sits above both as the root of a federation — it signs, it does not route — and its signature is what lets the Connector ask on the relying party's behalf.
The friction shows up wherever "who is asking" has two answers: who the wallet thinks it is talking to, who holds the reader credentials, what comes back, and what the Connector has to start storing. None of it is fatal. All of it needs a decision.
#What we built
A four-part demo, deliberately assembled from the pieces ConnectID already has plus the smallest new component that could work:
1. The relying party
An ordinary web app that wants a verified identity. It integrates with ConnectID exactly as it does today and is unchanged by any of this.
2. The chooser
The provider selection screen, rendered by the relying party from ConnectID's component, with one new tile alongside the banks.
3. The Connector
The new component. To the relying party it is one more provider, reached under ConnectID's federation. To the user's wallet it is a verifier asking to read a credential.
4. The wallet
The digital licence already on the user's phone, reached through the browser rather than through an app switch or a QR code.
#How to read this site
If you have ten minutes, read this page and then Limitations. If you have half an hour, watch the walkthroughs first (the flow is much easier to hold in your head once you have seen it happen), then read the flow, step by step and Limitations.
Decisions for ConnectID is the page to bring to a meeting. It is the open questions only ConnectID can answer, with the consequences of each answer set out.
#The one thing to take away
The Connector pattern lets ConnectID add wallet-based credentials without asking a single relying party to change a line of code. That is a valuable property, and it is the reason to take the pattern seriously.
The cost is that something new sits in the data path: the Connector. Today the identity flow runs directly between the relying party and the bank; ConnectID is the trust root of the federation that lets them talk, and sees no personal data at all. Nothing about the connector pattern changes that for ConnectID itself — it signs the request and never sees the response. But the Connector stands in front of the wallet as the verifier, and verifying a licence means decrypting and reading it in full. It also means taking on the platform relationships, the trust list, and, because a digital licence carries no account identifier, a record of who the user is.
So the question that decides most of what follows is who operates the Connector. If ConnectID does, it is in the data path for the first time, and anyone who has been told ConnectID never sees customer data will need a new answer. If someone else does, under ConnectID's federation, ConnectID keeps its property and the Connector's operator inherits the obligations. Either is defensible — three other jurisdictions have made room for exactly this role — but it should be decided deliberately rather than discovered later.
No Australian digital licence can be added to Apple Wallet or Google Wallet today. Australia's live licences sit in government apps. The wallets this browser API reaches do not yet hold Australian credentials, so the near-term volume argument is weak and the readiness argument is the real one.
Chrome and Safari currently disagree about a detail that decides the architecture. The cleaner design — the relying party embedding ConnectID and granting it permission — works in one browser and fails in the other today. Until that resolves, the redirect model the demo uses is the one that works.
#Status of this document
This is a live working document that grows as the demo does. Pages marked with a status pill are provisional. Every factual claim about specifications, browser versions and platform behaviour is sourced on the Specs and sources page; where something could not be verified it says so rather than guessing.