Specs and sources

Claims about specification stages, browser versions and platform behaviour age quickly and are easy to get wrong from memory. This page is the audit trail.

Facts in this area have a shelf life of months. Everything below was checked on 2 September 2026 and should be re-checked before it is used in a decision more than a quarter from now.

#Specifications

Three things about this table deserve emphasis in any management conversation.

The browser specification is not finished, and has no date for finishing. It carries no Candidate Recommendation target, it is republished roughly weekly, and its own privacy considerations section is marked as a work in progress. Advancing it is formally gated on separate threat and mitigation work being published first.

It survived two formal objections. One argued the API would increase demand for identity data and centralise it around a few operating systems and wallets. The W3C council overruled it while stating that it shared the concerns and agreed the technology has potential for the described societal harms. A second objection, to the specification's dependency on a paywalled ISO document, was also overruled. Anyone told this is settled and uncontroversial has been told something inaccurate.

The ISO and OpenID tracks are not yet aligned. The published ISO annex profiles a draft of OpenID4VP that the final version is not backwards compatible with. The annex that fixes it is not published.

#Platform support

Usage, as distinct from availability. Chrome's own telemetry puts use of this API at a very small fraction of a percent of page loads — closer to one in ten million. It is shipped. It is not yet used.

Apple's restrictions go beyond protocol. iOS accepts mdoc only, and only a short allowlist of document types. Android restricts neither format nor document type.

Desktop is cross-device only, everywhere. The mechanism is a scanned code plus a short-range proximity check to the phone. A Safari-on-Mac user cannot reach an Android wallet at all, and the platform matrix records no workaround.

One combination is documented as impossible: starting a cross-device flow from an iPhone. iOS does not support presenting from a credential manager on another device.

#Australia

No Australian digital licence can be added to Apple Wallet or Google Wallet. Both programmes are documented for a list of jurisdictions that includes no Australian state or territory. Australia's live digital licences sit in government apps.

The national trust list already has an owner, and it is not ConnectID. Austroads operates a digital trust service that publishes the issuing authorities' keys, using the same list mechanism as the international standard. Multi-jurisdiction testing in late 2024 reported no failures. Its public pages still describe it in future tense and no production launch has been announced, so its live status should be confirmed directly rather than assumed.

ConnectID's own accreditation is confirmed on the public register: accredited as an identity exchange under the Digital ID Act 2024, dated 1 December 2024. "Identity exchange" there is the Act's accreditation category; it does not describe where ConnectID sits technically, which is as the trust root of a federation rather than in the data path. It is not on the separate register of entities participating in the government system, which is expected — private-sector participation opens at the end of 2026.

The rules that will matter are being written on a different track. The Digital ID Act's data standards concern federated sign-in and do not mention verifiable credentials, mobile licences or this browser API at all. The credential rules are coming from a national strategy agreed in February 2026 and a Commonwealth consultation that closed in July 2026. No outcome has been published.

One reported proposal from that consultation is directly relevant and cuts against the international pattern: that verifiers would not be required to register. If that position holds, Australia would be more permissive of an unregistered intermediary than Europe or the United Kingdom. It is reported rather than confirmed, and the final position is not public.

#Unverified

Listed explicitly, because in this field the gaps are load-bearing.

Affects whether the pattern works at all

• Whether an Australian entity can enrol in Apple's verifier programme. No geographic scope is stated either way. Given Apple's wallet carries no Australian credentials, this needs a direct answer from Apple before commitment.
• Whether the licence number changes when a licence is renewed or replaced. This determines whether account matching is viable at all, and it sits in a paywalled standard. It is the single most consequential unresolved fact for the identifier problem.
• Whether Australia's national trust service is in production. Latest public evidence is pre-production testing from December 2024.

Affects the federation design

• ConnectID's live federation surface. This site describes ConnectID's role as the Trust Controller of an OpenID Federation, as briefed. The public federation discovery endpoint on ConnectID's directory did not respond when checked, and the production entity identifiers and the location of the trust anchor's entity configuration are not known to us. The demo runs against a stand-in anchor it operates itself. Nothing here should be read as a claim that the public endpoint is live; it is a question for ConnectID's programme.

Affects cost and terms

• Whether either platform charges for verifier enrolment. Neither publishes pricing; absence of a fee is not a statement that it is free.
• Which jurisdictions' keys are actually in the national trust list today, and whether it can be retrieved publicly or requires onboarding.

Affects the policy picture

• The outcome of the Commonwealth consultation, including the verifier registration question above.
• The credential format and protocol used by the Commonwealth's own credential exchange pilot. No official document names one. It should not be asserted.
• Whether Australia has formally adopted the ISO standards domestically. No adoption instrument was found; the commitment operates through an intergovernmental agreement.

#Corrections

A widely-circulated claim that ConnectID is built on W3C verifiable credentials with zero-knowledge proofs is false. It originates from an automated aggregator page and has contaminated search results. ConnectID runs a profile of OpenID Connect. Its selective disclosure is per-claim consent plus derived boolean age claims. There are no zero-knowledge proofs anywhere in it.

This is noted here because the claim is likely to reach ConnectID management from someone's search, and it is better to have the correction ready.

#Method

Specification stages were taken from the specifications themselves and from W3C version history. Browser data came from platform status APIs and, where those conflicted with commentary, from the browsers' own source trees and preference files — which is how the Firefox and Safari entries above were settled against secondary reporting that said otherwise.

Where a source could not be reached, it says so above rather than being filled in from a plausible assumption.