ATO myID Context

Context for the RFI: what myID is today, where it’s heading, and how a SABLE-class capability complements rather than replaces the existing stack.

What myID is today

Australia’s national Digital ID Provider under the Digital ID Act 2024 (commenced 1-Dec-2024)
An app installed on the user’s smart device — they prove who they are once and log in to government online services thereafter
14 M+ users; 6 M+ at IP3 (Strong) identity proofing
95 M+ uses across 12 months (Aug 2024 – Aug 2025) across 240+ government online services
Three identity-proofing (IP) levels today:
- IP1 (Basic) — verified email + self-asserted name + DOB
- IP2 (Standard) — verified email + name + DOB via 2 documents through DVS
- IP3 (Strong) — verified email + name + DOB via 2-3 documents through DVS + face biometric against source document (Australian Passport / Driver Licence) via FVS
Future IP levels per Digital ID Act:
- IP1+ — 1 document via DVS
- IP2+ — 2 documents via DVS + face biometric (where Passport not used) via FVS, with a liveness check

What the ATO is looking to evolve

“Since the launch of Strong myID in 2021, the technology landscape for identity verification has evolved significantly… To ensure myID continues to meet the highest standards of security, usability, and inclusivity, the ATO is seeking information from technology providers on their capabilities to support future enhancements.”

Three concrete capability streams:

Liveness detection & facial image capture — refresh of the 2021-procured liveness stack
Biometric matching — enable login / account recovery without manual re-proofing (today’s IP3 users sometimes have to re-prove via call-centre support → high cost, poor UX)
Technical verification of credentials — NFC-enabled verification of electronically readable identity documents (ePassports) so offshore users can verify with foreign Passports (today they can’t, because myID only verifies against Australian-issued documents)

Why this is a strategic moment

The Digital ID Act 2024 codifies privacy and minimisation as legal obligations, not best practice
The market has moved on from 2021’s PAD techniques (anti-spoofing is now a moving target as deepfakes mature)
14 M+ users at IP3 represent significant lock-in to the current architecture, so any replacement must be backwards-compatible
Offshore verification is currently a gap — myID doesn’t work outside Australia for foreign-document holders, which limits its use for diaspora / expat / visa-track users

Where SABLE fits

Anuna Research Cooperative brings directly-comparable delivery experience: the BARMM (Bangsamoro Autonomous Region in Muslim Mindanao) eGov programme — currently building digital identity, citizen-facing services, and transformation advisory for a regional Philippines government, with production go-live July 2026 (BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension). Adjacent engagements with GovUK (UK Government Digital Service) and CSIRO Data61 position us in the OECD public-sector context; early international dialogue on the SABLE approach is under way with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI). SABLE is not a drop-in replacement for the current liveness / matching stack — it is a complementary capability with four distinctive properties:

Privacy by construction — biometric data never leaves the device. The 2021-procured stack typically captures the face image, transmits it to a vendor-operated matcher / liveness service, and stores it for audit. SABLE captures, hashes (Pedersen), and proves match locally; only the ZK proof reaches the SaaS endpoint. This is a stronger guarantee than any policy-based access control.
Selective disclosure via BBS+ — once the Digital ID Act starts requiring proof of attributes (over 18 / Australian citizen / not on a sanctions list) the standard approach is to expose the underlying credential. SABLE’s BBS+ pipeline lets the user prove the predicate without revealing the field — directly aligned with the Act’s minimisation principles.
Offline P2P operation — the capture / liveness / proof pipeline executes entirely on-device with no internet dependency. Addresses inclusivity for users in low-connectivity areas of Australia, and provides a path to the offshore-verification capability the ATO has identified as a gap for users abroad.
Open-source regional public good — Apache 2.0 licence means investment in maturing SABLE for myID use compounds beyond the ATO’s direct benefit; see Regional spillover below.

These align especially well with the ATO’s inclusivity and future-readiness vision, and complement (rather than compete with) the FVS-anchored architecture for the current IP3 path. A pragmatic deployment pattern is:

Phase 1 (immediate): SABLE provides the capture + PAD + match pipeline running entirely on-device; ATO’s existing FVS continues to perform the authoritative 1:1 match against the source document via existing channels. SABLE’s proof is an additional integrity / liveness signal alongside the FVS check.
Phase 2 (12-18 months): SABLE handles routine reauthentication (login / recovery) entirely on-device using the user’s Pedersen-committed enrolment, removing 80 %+ of FVS round-trips and call-centre re-proofing escalations.
Phase 3 (24+ months): SABLE’s BBS+ selective disclosure path becomes the default for attribute-only checks (age, citizenship, etc.) per Digital ID Act evolution.

The architectural case for moving biometric data off centralised servers

The case for an on-device, never-leaves-device architecture is reinforced by a decade of breach evidence. Internationally, the 2019 Suprema BioStar 2 incident exposed approximately 27.8 million biometric records — fingerprints and facial-recognition templates — through an unsecured database. The 2014-15 US Office of Personnel Management breach exfiltrated approximately 5.6 million fingerprint records to a state-sponsored adversary as part of a larger 21.5-million-record compromise of background-check files. The 2023 23andMe breach affected approximately 6.9 million users’ genetic-biometric profiles via credential stuffing. In Australia, the Notifiable Data Breaches scheme has recorded large-scale identity-document exposures at Optus (September 2022, approximately 9.8 million customers including passport and driver-licence data), Medibank (October 2022, approximately 9.7 million customers including health and identity data), and Latitude Financial (March 2023, approximately 14 million records including approximately 7.9 million driver licences and 53 000 passport numbers).

The pattern across these incidents is consistent: any system that aggregates biometric or identity-document data into a central store creates a high-value target whose breach risk is structural, not merely operational. Hardening procedures, access controls, encryption-at-rest, and post-breach disclosure regimes can each be improved — but none of them retire the target class. SABLE retires the target class by design. There is nothing for an attacker to exfiltrate at scale because the biometric data never leaves the user’s device; even total compromise of the SaaS verification endpoint yields no biometric data, because none is held there. For an identity service of myID’s scale and visibility, this architectural property is materially more defensible than any defence-in-depth posture built on top of centralised storage.

Trust in large-scale government identity infrastructure is a maintained asset, not an inherent property. The broader Australian public-sector experience over the last decade — the parliamentary scrutiny that shaped the Digital ID Act 2024, ongoing public commentary on the use of biometric and identity-document data, and the demonstrated reputational consequences when government data systems lose public confidence — has shown that the social licence to operate national identity infrastructure is contingent on demonstrable privacy posture, not just on legal compliance with the privacy framework.

myID’s scale (14 million-plus users, 95 million-plus logins per year, 240-plus services) means it now functions as critical national infrastructure, with the public-trust expectations that come with that status. Architectural privacy — where biometric data verifiably never leaves the user’s device — is not only a security control; it is a social-licence asset. It makes the ATO’s privacy commitments empirically verifiable rather than rhetorically assertable: a user can inspect the open-source code, an independent cryptographer can verify the zero-knowledge property, a journalist or parliamentary committee can verify the architectural claim without specialist access. Each of these closes off a channel through which the social licence to operate can be challenged.

For the ATO specifically, this matters in two ways. Operationally: each future incident in the broader biometric / identity-data sector creates pressure on every operator of identity infrastructure, including myID; architectural privacy makes it possible to credibly answer “that class of incident is structurally impossible for us” rather than “we have controls in place to mitigate that risk”. Strategically: the ATO’s wider authority — its capacity to administer the tax system at scale — depends on continued public confidence that it holds and uses citizen data appropriately. Reducing what it holds, by design and not just by policy, strengthens that wider authority directly. Investment in privacy-by-construction biometrics is, in this sense, also investment in the ATO’s social licence to operate at the scale and trust level the modern tax system requires.

Regional spillover — additional public value

A distinctive feature of an ATO investment in SABLE: the work is Apache 2.0 open-source, so any production-hardening work the ATO funds — third-party ISO/IEC 30107-3 EAL-2 (Level B) PAD certification, ISO/IEC TS 19795-9 FMR/FNMR benchmarking, Microsoft MAUI bindings, IRAP / PROTECTED-level certification, ASD-HACE-compliant cryptographic pathway, WCAG 2.1 AA accessibility audit — becomes immediately and freely available to any other government deploying the library.

Candidate future deployment contexts for SABLE that would directly benefit from ATO-funded maturation:

BARMM (Philippines) — Anuna’s existing eGov delivery engagement provides a natural deployment pathway for SABLE; the same practitioner team is in position
European public-sector identity — early dialogue under way with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI) about the SABLE approach
Other Pacific island nations — many actively scoping or building national digital ID; on-device privacy-preserving primitives are a natural fit
ASEAN member states — multiple jurisdictions with active digital-identity programmes
Adjacent use cases beyond national digital identity — age verification for online services; healthcare patient verification (telehealth, prescription authorisation); building / facility access control; employer / contractor on-site identity; peer-to-peer credential verification — wherever holding biometric or identity-document data centrally is a liability that an architectural alternative could retire

This dimension aligns with several Commonwealth foreign-policy priorities:

Pacific Step-Up — Australian-developed digital-trust infrastructure deployable across the Pacific
Indo-Pacific Endeavour — supporting regional digital sovereignty without dependence on US or Chinese vendor stacks
ASEAN digital cooperation — interoperable identity primitives across the region
The Quad’s cyber resilience agenda — open, audit-able, sovereign-controlled identity capability
DFAT Cyber and Critical Tech Cooperation Program — capacity building in regional digital trust

The ATO procures an audited, certified production stack for myID. The by-product is a public good — an Australian-developed open-source identity capability that strengthens the regional digital-trust posture more broadly. This is genuine additional public value the ATO can claim from the procurement spend, beyond the direct benefit to myID users.

Linked notes

opportunity-overview — the RFI itself
sable-fit — per-requirement capability mapping
gaps-and-risks

Backlinks

Linked Pages

gaps-and-risks

Gaps & Risks — Honest Disclosure

Consolidated view of every requirement where SABLE is Partially Compliant today, what remediation is needed, and what timeline.

Certifications & accreditations (largest gap cluster)

ID	Gap	Remediation	Effort
LV-5 / LV-6	No ISO/IEC 30107-3:2023 EAL-2 (Level B) third-party PAD test report yet	Engage an ILAC-accredited PAD testing laboratory; no lab arrangement in place at RFI stage	3-4 months elapsed; ~AUD 60-100 k spend
SC-1	Full ISM / Essential 8 compliance evidence not yet produced for SaaS shell	Build SaaS to ISM controls from day 1; engage IRAP assessor	6-8 months elapsed (overlaps with SC-6)
SC-6	PROTECTED-level IRAP certification not yet held	Engage IRAP assessor; remediate findings; cert at PROTECTED	6-8 months elapsed; ~AUD 150-250 k spend
OP-9	No NV1-cleared Australian support staff today; no subcontractor arrangement in place	Sponsor founder NV1 clearance + subcontract via an Australian Security Vetting Agency–cleared support partner	12+ months for direct NV1; immediate via partner once contracted

All four are standard procurement-stage activities in Australian federal identity tech — none are blockers. The RFI explicitly notes evidence is not required at this stage; we acknowledge the work is needed and commit to completing it inside any second-stage timeline.

Technical gaps with clear remediation

ID	Gap	Remediation	Effort
TV-1	ICAO Doc 9303 ePassport PKI verification (with CRL checking) not in core	Add via existing OSS libs (jMRTD wrapper, Apache Santuario for PKI); design slot exists in `attestation` module	8-12 weeks dev
TV-3	Quantitative FMR / FNMR not measured against ISO/IEC TS 19795-9 protocol	Run formal benchmark against LFW / IJB-C / MS-Celeb-1M corpora; report at 90% CI	4-6 weeks
IN-1	Microsoft MAUI bindings not shipped (Android JNI / iOS Swift exist)	Generate via cbindgen → C ABI → MAUI .NET bindings + sample app	4-6 weeks
UX-3	WCAG 2.1 AA audit not yet performed	Engage an accredited Australian accessibility audit firm; remediate findings	4-6 weeks
SC-3	BLS12-381 not currently on ASD HACE catalogue	Either (a) ASD HACE assessment / acceptance pathway, or (b) provide parallel ASD-approved cryptographic path (e.g. P-256 + SHA-256 classical-only mode) for environments requiring strict HACE compliance	4-8 weeks for parallel path

Track-record gaps

ID	Gap	Compensating evidence
IN-5	SABLE specifically has no prior large-scale government deployments	(a) Anuna’s current BARMM eGov programme — government identity, citizen services, advisory, production go-live July 2026 — is the most directly relevant delivery-capability reference (BARMM does not currently deploy SABLE; future deployment a candidate natural extension); (b) early international dialogue on the SABLE approach with Germany’s BSI; (c) adjacent: GovUK, CSIRO Data61, Microsoft, Autodesk, Suncorp, IAG, Telus, Telefónica, Kellogg, University of Wollongong — references available on request; (d) Tang et al. NDSS 2018 published methodology with academic validations; (e) offer of a paid Proof-of-Concept against ATO’s myID test cohort as the most decisive direct evidence for SABLE specifically
VISM-6	No prior implementation of biometric identity systems in Australian federal government specifically	BARMM is direct government identity / eGov delivery by the same practitioner team (SABLE not yet deployed at BARMM); GovUK + CSIRO Data61 cover OECD public-sector posture; this would be Anuna’s first direct Australian federal identity engagement
OP-10	First direct Australian federal government identity-system delivery	As IN-5; BARMM (in production July 2026) provides the closest delivery-capability analogue — same practitioner team, same delivery shape; ATO would be Anuna’s first Australian federal engagement and SABLE’s first government deployment
OP-6	(Re-reading Addendum 1 Q14: requirement is for organisational controls, not clinical assessment)	Anuna has these — separation of duties, peer review, security-awareness training, privileged-access monitoring, incident-reporting runbooks. Now Compliant — see addenda-clarifications

Strategic risks (for ATO to weigh)

Risk	Mitigation
SABLE is pre-production; bugs / vulnerabilities possible	(a) Open-source, fully auditable; (b) 519 tests passing with 89% coverage; (c) commitment to a security audit (e.g. Trail of Bits, Kudelski) before any production cutover; (d) phased PoC → pilot → rollout deployment model
Halo2 is a 2020-2021 cryptosystem; comparatively new compared to legacy PKI	Halo2 has rigorous academic review; deployed at production scale by Zcash; transparent-setup eliminates the trusted-ceremony class of failures
BLS12-381 quantum-vulnerable by 2030-2035	Post-quantum migration on the published roadmap (CRYSTALS-Dilithium signature path; hash-based commitment alternatives); ATO’s deployment timeline likely aligns with industry-wide PQ rollout
Anuna Research Cooperative is a small Australian company	(a) Open-source codebase removes vendor-lock-in / business-continuity risk; (b) source-escrow agreement available; (c) partnership model with an Australian systems integrator acceptable for delivery scale if procurement warrants it (no such arrangement is in place at the RFI stage)

What this RFI is buying

The ATO is buying market intelligence and option value on innovative biometric solutions. SABLE’s distinctive value isn’t a 99 %-vs-95 % match-rate improvement — it’s privacy by construction, which the existing 2021-procured stack architecturally cannot offer. Even if the ATO ultimately proceeds with an incumbent for the SaaS reverification stack, SABLE’s on-device proof + selective-disclosure model is a strategic capability worth understanding for the next 5-10 years of Digital ID Act evolution.

Linked notes

sable-fit — per-requirement detail
evaluation-criteria — source requirements
ato-myid-context — why the strategic capability matters

sable-fit

SABLE Fit — Per-Requirement Position

Maps every M / D requirement in evaluation-criteria to SABLE’s current capability and the gap (if any). Source: ../sable/README.md, ../sable/IMPLEMENTATION_STATUS.md, ../sable/docs/. Compliance values use Part 3a’s drop-down options: Compliant / Partially Compliant / Non-Compliant.

Biometric Capture & Liveness Detection (LV)

ID	SABLE Position	Compliance	Commentary
LV-1	✅ SABLE captures face embeddings via standard smartphone camera; image-quality controls operate at capture time	Compliant	We extract 1024-dim face embeddings; image-quality scoring against ISO/IEC 29794-5 profile is integrated in the capture pipeline (sable-core `biometric` module). Quality profile output is exposed via the FFI.
LV-2	✅ Automated quality controls + UI guidance for re-capture	Compliant	The capture SDK rejects out-of-spec frames and returns user-facing guidance codes (face-too-close, low-light, off-axis, motion-blur). UI guidance text is configurable per ATO branding.
LV-3	✅ Spatial-flash PAD based on Tang et al., NDSS 2018	Compliant	Active liveness via screen-flash challenge-response. The screen flashes split-screen colours over 3 rounds; the camera captures how light reflects off the face. A real 3D face reflects differently in upper vs lower regions; a flat photo/screen reflects identically.
LV-4	✅ Capture + PAD in a single continuous workflow	Compliant	The Halo2 ZK proof binds capture and PAD into a single composite proof (~250 ms generation). The PAD fingerprints feed directly into the same circuit as the face-match check — they cannot be decoupled or replayed.
LV-5	⚠️ Defensible against current photo/screen replay attacks, but not yet ISO/IEC 30107-3 EAL-2 (Level B) tested	Partially Compliant	The technique (controlled-illumination reflectance analysis) is published peer-reviewed methodology; engagement of an ILAC-accredited testing laboratory for formal EAL-2 (Level B) certification is planned and can be completed inside a typical procurement timeline (3-4 months). No lab arrangement in place at the RFI stage.
LV-6	⚠️ Pending third-party PAD test report (see LV-5)	Partially Compliant	We will provide vendor self-assessment evidence now (NDSS 2018 paper, internal red-team testing against printed photos / phone-screen replays / video replays) and commit to producing an ISO/IEC 30107-3 third-party test report by end of any procurement evaluation phase.

Technical Verification & Biometric Binding (TV)

ID	SABLE Position	Compliance	Commentary
TV-1	⚠️ ICAO Doc 9303 ePassport NFC reading is not yet in SABLE core	Partially Compliant	The SABLE architecture has an `attestation` module designed for X.509-style chain validation; ICAO 9303 PKI verification including CSCA/Master List handling and CRL checking is a planned addition (estimated 8-12 weeks). Existing open-source libraries (e.g. jMRTD, BSI) can be wrapped.
TV-2	✅ Single-continuous-workflow capture + PAD + binding is the SABLE flagship feature	Compliant	The Halo2 composite proof binds biometric capture, PAD, and credential binding in one atomic operation. PAD operates at point of capture; the entire pipeline runs before any proof is submitted for verification. Data-capture-subsystem signals and system-level monitoring (frame timing, sensor metadata, challenge nonce binding) all feed the circuit per ISO/IEC 30107-1.
TV-3	⚠️ Quantitative FMR/FNMR benchmarking against ISO/IEC TS 19795-9:2019 protocol is planned	Partially Compliant	SABLE’s matching uses Pedersen-committed Poseidon-hashed embeddings with a configurable Hamming-distance threshold inside the Halo2 circuit. The underlying face embeddings are based on a 1024-dim feature extractor; matching accuracy depends on the embedding model. We commit to running an ISO/IEC TS 19795-9 evaluation against a standard test corpus and reporting FMR/FNMR at the 90 % confidence interval within the procurement evaluation window.

Scalability, Performance, Availability

ID	SABLE Position	Compliance	Commentary
S-1	✅ Architecturally horizontally scalable — verification is stateless	Compliant	Halo2 verification is ~1.8 ms per proof. The SaaS verification endpoint is stateless (no session affinity, no shared memory) and trivially horizontal — capacity scales linearly with EC2/EKS instances.
S-2	✅ A SaaS verification endpoint is the deployment target	Compliant	The proposed deployment wraps the open-source SABLE library in a hosted SaaS verification service on AWS Sydney. The library itself remains client-side (in the user’s myID app instance) — only the proof reaches the SaaS.
P-1	✅ 10 000 verifications/hour at p95 ≤ 1000 ms is comfortable	Compliant	10 000/hour = ~2.8/sec average; SABLE verification at 1.8 ms means a single t3.medium handles this with >99 % headroom. Proof generation (~250 ms, on-device) is amortised across millions of devices, not on the server. Full performance numbers in P-2 narrative.
P-2	✅ Documented benchmark methodology in `sable/bench/`	Compliant	We provide a Software Capacity Plan with: (i) measured verification latency distributions on Apple Silicon + AWS Graviton3 reference instances; (ii) AWS infrastructure design with EKS auto-scaling group + ALB; (iii) capacity-curve projection at 10×, 100×, 1000× peak.
A-1	✅ 99.95 % uptime achievable on AWS Sydney with multi-AZ design	Compliant	Multi-AZ EKS deployment behind ALB; data plane is stateless (no DB writes per verification); RTO < 5 min, RPO = 0. Bonus: SABLE’s on-device proof generation means the user-facing capture/liveness flow is 100 % available even if the SaaS endpoint is degraded — only final verification needs the SaaS.

Hosting, Integration

ID	SABLE Position	Compliance	Commentary
H-1	✅ SaaS wrapper on AWS Sydney	Compliant	Vendor-managed, secure, scalable. Library is open-source (Apache 2.0); SaaS shell + integration + ops is the commercial scope.
H-2	✅ AWS PrivateLink-ready	Compliant	We propose a VPC Endpoint Service in `ap-southeast-2` so the ATO’s AWS account connects to SABLE Verification API via PrivateLink — no internet egress, no public endpoint. Resources required from ATO: VPC Endpoint creation in their account, IAM cross-account role for telemetry export, DNS resolver entry.
IN-1	⚠️ MAUI bindings not yet shipped; Android JNI + iOS Swift are in core today	Partially Compliant	SABLE has FFI for Android (JNI) and iOS (Swift). Generating .NET/MAUI bindings on top of the C ABI (sable-core exposes via cbindgen) is mechanical and estimated at 4-6 weeks including sample MAUI integration project. We commit to delivering MAUI bindings inside a procurement evaluation phase.
IN-2	✅ Browser support via WASM Halo2	Compliant	The demo web frontend (`demo/web/`) already runs Halo2 proof generation in-browser via WASM, with camera capture via getUserMedia and spatial-flash liveness via the browser canvas. Verified working in Chrome, Safari, Edge, Firefox on desktop and mobile.
IN-3	✅ No server affinity required	Compliant	Stateless verification; any request can hit any pod. No sticky sessions.
IN-4	✅ IaC-driven deployment	Compliant	Deployment is fully IaC (Terraform modules provided); ATO can run `terraform apply` against their AWS account for fully silent deployment. CI pipelines provided (GitHub Actions templates).
IN-5	⚠️ SABLE specifically is pre-production; Anuna Research Cooperative is currently delivering directly-relevant government eGov work	Partially Compliant	SABLE itself is pre-production (519 tests passing; demo deployed; no live government deployments). Anuna is currently delivering eGov services for the Bangsamoro Autonomous Region in Muslim Mindanao (BARMM) — digital identity, citizen-facing services, advisory — production go-live July 2026 (so live well before any plausible ATO post-RFI procurement stage). BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension of the existing engagement. Early international dialogue on the SABLE approach is under way with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI). Adjacent government-context engagements: UK Government Digital Service (GovUK); CSIRO Data61. Adjacent large-scale enterprise: Microsoft, Autodesk, Suncorp, IAG, Telus, Telefónica, Kellogg, University of Wollongong. PoC against ATO’s myID cohort offered as the most direct evidence for SABLE in the ATO-specific context.

Security & Confidentiality

ID	SABLE Position	Compliance	Commentary
SC-1	⚠️ ISM / Essential 8 alignment work to be done	Partially Compliant	The SaaS shell will be designed against ISM and Essential 8 from day one (multi-factor admin auth, application allow-listing, patch-management cadence, daily backups, etc.). Full IRAP assessment is a procurement-stage activity.
SC-2	✅ Privacy by construction	Compliant	SABLE’s defining property is that biometric data never leaves the user’s device. APP 1 (open and transparent management): open-source codebase. APP 3 (collection of solicited PI): we collect only the ZK proof + minimal metadata, never the biometric. APP 11 (security): biometric data is committed-and-hidden in Pedersen commitments; even an SaaS breach exposes no biometric data.
SC-3	⚠️ Uses NIST-aligned primitives, ASD HACE catalogue review pending	Partially Compliant	SABLE uses BLS12-381 (128-bit security), Poseidon (peer-reviewed ZK-friendly hash), ChaCha20-Poly1305 (NIST/ISM-listed). BLS12-381 itself is not yet on the ASD HACE list but is widely deployed and aligned with NIST proposals. We commit to replacing any primitive that fails ASD/IRAP review with an ASD-approved equivalent (e.g. P-256 with SHA-256 in pure-classical mode, alongside the BLS12-381 ZK path).
SC-4	✅ Halo2 proof IS the integrity control	Compliant	The Halo2 ZK proof cryptographically binds (a) the captured biometric, (b) the PAD liveness fingerprints, (c) the session-binding nonce, and (d) any selectively-disclosed credential attributes — a single ~2 KB proof. Tampering with any component invalidates the proof.
SC-5	✅ Personal Information never crosses the boundary at all	Compliant	Biometric PI never leaves the user’s device. Only the ZK proof, the session nonce, and (optionally) selectively-disclosed predicates traverse the network. ATO’s SaaS endpoint receives no PI.
SC-6	⚠️ PROTECTED certification not yet held	Partially Compliant	We commit to engaging an IRAP assessor for PROTECTED-level certification of the SaaS shell + integration within the procurement evaluation phase. Open-source codebase + minimised attack surface (no PI server-side) materially simplifies the IRAP path.
SC-7	✅ AWS ap-southeast-2 (Sydney) hosting	Compliant	All operational data (verification logs, audit trail, configuration) hosted in `ap-southeast-2`. Data Hosting Certification Framework: AWS Sydney holds the Certified Strategic Hosting Provider classification.
SC-8	✅ Full SBOM provided	Compliant	Open-source SBOM produced via `cargo cyclonedx`; every dependency, license, and access scope documented. Third-party components: Halo2 (PSE/zcash), Poseidon (academic), ChaCha20-Poly1305 (RustCrypto).

Operations, Vendor Implementation Support & Maintenance, Maintainability

ID	SABLE Position	Compliance	Commentary
OP-1	✅ Standard SaaS architecture	Compliant	dev / staging / prod environments, all monitored 24×7 via CloudWatch + PagerDuty integration.
OP-2	✅ CI/CD with ephemeral test environments	Compliant	GitHub Actions pipelines spin up per-PR test environments via Terraform; integration tests run automatically.
OP-3	✅ AWS Sydney + CloudWatch Service Health	Compliant	Data sovereignty enforced via IAM SCPs preventing replication outside `ap-southeast-2`; real-time status via internal CloudWatch + public status page.
OP-4	✅ CloudTrail + GuardDuty	Compliant	All access to ATO data and all privileged operations logged via CloudTrail; GuardDuty monitors for anomalous patterns.
OP-5	✅ ATO IP allow-list at VPC PrivateLink	Compliant	Access enforced at the VPC endpoint level + at the API authentication layer (mTLS); IP ranges configurable per environment.
OP-6	⚠️ Personnel coercion-detection is a specialist domain	Partially Compliant	We do not currently operate behavioural-analytics tooling for personnel monitoring. We will partner with an Australian managed-SOC provider for managed insider-risk detection if required (no such arrangement in place at the RFI stage), or accept this as a desirable-not-met.
OP-7	✅ Real-time alerting on biometric failure patterns	Compliant	EventBridge → SNS → PagerDuty for high-risk patterns (PAD failure clusters, brute-force enrolment attempts, geographic anomalies).
OP-8	✅ Tiered alerting via severity tags	Compliant	Critical / High / Medium / Low alert tiers route to different channels with different SLAs; data-loss-prevention covered by abnormal-access detection on the verification API.
OP-9	⚠️ NV1-cleared staff and iRAP-certified portal not yet held	Partially Compliant	Anuna Research Cooperative will engage an Australian Security Vetting Agency–cleared support subcontractor for NV1-cleared L2 support, and sponsor founder NV1 clearance in parallel, inside a procurement evaluation phase. Incident management via an IRAP-assessed Australian incident management portal. No subcontractor or portal arrangement is in place at the RFI stage.
OP-10	⚠️ No prior government identity-system deliveries (see IN-5)	Partially Compliant	We offer: (a) dedicated helpdesk with named L2/L3 engineers; (b) public fraud-prevention roadmap; (c) knowledge-transfer commitment via documentation, on-site workshops, and pair-programming during transition. We acknowledge limited prior government identity-system delivery history (see IN-5).
VISM-1	✅ Helpdesk via dedicated email + status page	Compliant	Tiered support (P1/P2/P3/P4) with SLA-bound response times; AusGov.au-hosted ticketing portal.
VISM-2	✅ Open-source documentation + ops runbooks	Compliant	All `docs/` is public; ops runbooks for the SaaS shell will be ATO-private and version-controlled.
VISM-3	✅ Monthly security patch cadence, weekly minor updates	Compliant	Documented patching schedule; CVE response SLA: 4 hours triage / 24 hours patch for Critical, 7 days for High.
VISM-4	✅ Ongoing maintenance is the commercial subscription scope	Compliant	Subscription tier includes platform maintenance, dependency patching, ZK circuit revisions as cryptographic best practice evolves.
VISM-5	✅ Public roadmap	Compliant	Codeberg-hosted public roadmap; quarterly stakeholder review cycles. Items already on roadmap: BBS+ selective disclosure rollout, post-quantum migration (CRYSTALS-Dilithium signature path), multi-spectral liveness (IR), continuous authentication.
VISM-6	⚠️ Limited government track record (see IN-5, OP-10)	Partially Compliant	Honest disclosure. We propose a paid PoC against ATO’s myID test cohort as the most decisive evidence.
VISM-7	✅ Active research programme	Compliant	Anuna Research Cooperative publishes on identity, biometrics, and digital trust. Recommendations include: BBS+ for selective disclosure; post-quantum identity (NIST PQC integration); zero-knowledge KYC; offline-first identity proofs.
M-1	✅ Patching is a published SLA commitment	Compliant	See VISM-3. Third-party components are tracked via `cargo audit` in CI; out-of-date dependencies block merges.

Reporting & Monitoring, User Experience & Accessibility

ID	SABLE Position	Compliance	Commentary
RM-1	✅ CloudWatch Logs with optional log-shipping to ATO’s SIEM	Compliant	All API activity, configuration changes, and security-relevant events logged; Kinesis Firehose for ATO log-shipping.
RM-2	✅ CloudWatch / Grafana dashboards	Compliant	Out-of-the-box dashboards for: capture-time distribution, PAD pass/fail rates, FMR/FNMR over time, regional latency, error rates. ATO can customise via Grafana.
RM-3	✅ ATO read access via IAM cross-account roles	Compliant	Cross-account read role for ATO to query CloudWatch Logs Insights directly; sample CloudWatch Logs Insights queries provided in the runbook.
RM-4	✅ Monitoring integration options documented	Compliant	Native integration with: CloudWatch (default), Datadog (via Lambda), Splunk (via HEC), ATO’s existing SIEM (via log-shipping).
UX-1	✅ Mobile-first capture flow + responsive web fallback	Compliant	Native iOS / Android first-class; responsive web demo verified on phones, tablets, desktops.
UX-2	✅ UI standards + Figma + user-flow docs	Compliant	Brand-customisable UI; Figma library; user-flow maps for enrolment, authentication, account recovery, error states.
UX-3	⚠️ WCAG 2.1 AA audit not yet completed	Partially Compliant	Capture flow uses standard form patterns + ARIA labels + sufficient contrast ratios. Formal WCAG 2.1 AA audit by an accredited Australian accessibility audit firm is planned and can be completed in 4-6 weeks (no audit firm arrangement in place at the RFI stage). Accessibility-mode liveness alternative (audio prompts, larger UI elements) on roadmap.
UX-4	✅ Customisable UI via configuration	Compliant	Branding (colours, fonts, logos), copy (multi-language), capture flow steps, and even challenge parameters are configuration-driven, not code changes.

Cross-cutting business-requirement narrative

Secure — Halo2 ZK proof gives cryptographic guarantees stronger than any statistical match-rate threshold. Spatial-flash PAD defeats current photo/screen/replay attacks; ongoing R&D into deepfake / 3D-mask defences. FMR/FNMR benchmarking against ISO/IEC TS 19795-9 commitment per TV-3.
User-friendly — Capture flow is ~10 seconds (face capture + 3 spatial-flash rounds); no special device required; no internet required for capture; biometric data never leaves device.
Device compatibility — Any smartphone with a front-facing camera and modern browser; specifically tested on iOS 14+, Android 9+, Chrome / Safari / Edge / Firefox.
Accessible — WCAG 2.1 AA commitment (UX-3); accessibility-mode liveness alternative on roadmap; multi-language support.
Scalable — Stateless verification at ~1.8 ms; capacity scales linearly with EKS pods.
Cost-effective — Open-source library means no per-seat ZK proof licence; commercial scope is SaaS shell + integration + ops. Pricing model in Part 4a covers both perpetual and subscription tiers.
Compliant — Aligned with Digital ID Act 2024 data-minimisation principles by construction; ISM / Essential 8 / Australian Privacy Principles addressed in SC-* responses.
Integratable & maintainable — MAUI bindings (IN-1, 4-6 weeks); IaC deployment (IN-4); public SBOM (SC-8).
Value for money — The privacy-by-construction architecture removes the need for expensive ongoing breach-mitigation, data-sovereignty audits, and consent-management infrastructure that traditional biometric solutions accrue over their lifecycle.

Linked notes

opportunity-overview

Opportunity Overview

ATM: RFI-15434 — Biometric Verification Capability Agency: Australian Taxation Office (ATO) Type: Request for Information (non-binding) Closes: 4-Jun-2026 14:00 ACT (4 calendar days from 2026-05-31) Contact: Alison Buchanan — RFI15434@ato.gov.au

Why the ATO is asking

The ATO operates myid, Australia’s national Digital ID provider under the Digital ID Act 2024 (commenced 1-Dec-2024). myID has 14 M+ users, 6 M+ at IP3 (Strong) identity proofing, used 95 M+ times in the last 12 months across 240+ government online services.

myID’s current liveness-detection stack was procured in 2021. Since then biometric tech has moved on (anti-spoofing, deepfake defence, NFC-document binding). The ATO is now scoping a refresh and an expansion into offshore identity verification via NFC ePassports — neither covered by the existing stack.

What the ATO is asking for

Three streams of capability:

Liveness detection & facial image capture — detect spoofing, deepfakes, presentation attacks; capture biometric images of adequate quality for matching.
Biometric matching — authentication during service access and account recovery without manual re-proofing.
Technical verification of credentials — NFC-enabled verification of electronically readable identity documents (ePassports) for offshore users.

Solution must be SaaS, AWS-hosted, MAUI-compatible, Australian-data-resident, ISM-PROTECTED-certifiable, WCAG 2.1 AA, with 99.95 % availability and ≥10 000 verifications/hour @ p95 ≤ 1000 ms. See evaluation-criteria.

Where this could go

“As a direct result of this RFI, the ATO may proceed with a second stage that includes any of the following … Shortlist, RFT, RFQ, Limited Tender, Proof of Concept, Product demonstration/trial, or RFI closure.”

ATO myID Context

What myID is today

What the ATO is looking to evolve

Why this is a strategic moment

Where SABLE fits

The architectural case for moving biometric data off centralised servers

Social licence to operate

Regional spillover — additional public value

Linked notes

Backlinks