Addenda — Clarifications Applied

Two addenda issued by the ATO during the RFI period materially shape the response:

Addendum 2 — Closing date extension

Closing time 2:00 pm 28-May-2026 → 2:00 pm 4-Jun-2026 ACT. Applied throughout key-dates.

Addendum 1 — Q&A clarifications (15 items)

Items that change our position

#	Clarification	Impact on draft
Q1 (LV-6)	Any ILAC-accredited testing lab is acceptable — not specifically iBeta. Must evidence accreditation scope, methodology, version, PAD assurance level, limitations.	sable-fit / Part 3a — broaden lab options
Q2 (TV-3)	Algorithm must be tested using diverse cohort per Digital ID Accreditation Data Standards: disability; diverse abilities including technology ability; diverse age, gender, ethnicity. Applies to vendor’s own algorithm, not FVS.	Part 3a TV-3 — add explicit diversity commitment
Q3 (H-2)	ATO is open to multiple deployment models — vendor-managed SaaS or ATO-managed within ATO AWS environment. Both should be described with infrastructure, ops, security, support, licensing implications.	Part 3a H-2 — add a second deployment-model description
Q4 (IN-4)	IaC required for the deployment model proposed, plus document responsibility split (vendor vs ATO).	Part 3a IN-4 — clarify responsibility matrix
Q5 (IN-1)	If MAUI not available at RFI response time, provide committed delivery approach, timeline, risks, dependencies. Phased delivery acceptable subject to ATO assessment.	Part 3a IN-1 — already a 4-6 week commitment; refine risk/dependency narrative
Q6	Liveness only required at enrolment + reverification + recovery, NOT every login. 95M login figure is total activity, not liveness volume.	Part 3a P-1 / Pricing — clarifies sizing
Q7 (P-1)	10 000/hr is combined projected + observed; applies to enrolments, reverifications, account recovery events.	Part 3a P-1 — explicit
Q8 (P-2)	No growth forecast available — respondents to provide their own Software Capacity Plan with assumptions, scalable architecture, headroom, constraints, scaling triggers, monitoring, commercial implications across contract term.	Part 3a P-2 — strengthen Capacity Plan narrative
Q9 (OP-9)	NV1 clearance needed before personnel access PROTECTED/production systems, no later than production go-live. Interim arrangements possible (restricted access, supervised access, role separation, use of already-cleared personnel, deferral) subject to ATO Security approval. Respondents must provide current clearance status, sponsorship assumptions, lead times, mitigation.	Part 3a OP-9 — add interim arrangement plan
Q10 (SC-6)	IRAP scope includes all components processing/storing/transmitting/administering/monitoring/supporting ATO data: production platform, management plane, support portal, admin tooling, integrations, logging/monitoring, connected environments. Respondents to define proposed scope, current status, residual gaps, timeline; IRAP readiness must align with security assurance + production-readiness milestones.	Part 3a SC-6 — broaden scope statement
Q11 (SC-5)	SC-5 applies across full delivery chain: subcontractors, sub-processors, PAD providers, hosting providers, support providers, telemetry, logging. Foreign-incorporated PAD vendor OK if all PI stays in Australia.	Part 3a SC-5 — already strong (no PI ever crosses boundary); add explicit sub-processor coverage
Q12	Solution must follow privacy-by-design + data minimisation; biometric data must not be retained longer than required.	SABLE’s no-PI-server-side architecture: ideal fit; add explicit alignment statement
Q13 (TV-1)	No volume forecast for offshore NFC verification; phased delivery acceptable.	Part 3a TV-1 — already a 8-12 week phased commitment; add forecast acknowledgement
Q14 (OP-6)	Requirement is for organisational/operational controls, not clinical assessment: security awareness, escalation pathways, welfare/supervision, privileged access monitoring, separation of duties, peer review for sensitive actions, incident reporting, unusual access/behaviour detection.	Part 3a OP-6 — upgrade from Partially Compliant to Compliant with organisational-controls answer
Q15 (ISO 14001)	Must state in RFI response whether currently certified, aligned, or can achieve within 6 months. Must provide certification/alignment evidence, planned uplift, responsible owner, timeframe.	Part 3 General — add ISO 14001 statement

Items confirming our existing position

LV-6 (any ILAC-accredited lab) — strengthens our position (no vendor lock-in to a specific lab)
TV-3 (diverse cohort) — easy to address via test-corpus selection
SC-5 (full delivery chain) — SABLE’s architecture is “no PI in delivery chain at all” — strongest possible position
Q12 (retention) — SABLE matches privacy-by-design by construction; no retention required because no PI is ever held
Q6 / Q7 — liveness scale is enrolment + reverification + recovery only; reinforces feasibility at 10k/hr

Linked notes

evaluation-criteria — source requirements
sable-fit — per-requirement position (updated to reflect addenda)
gaps-and-risks — gap remediation plan

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

evaluation-criteria

Evaluation Criteria — Mandatory / Desirable / Optional

Pulled verbatim from sources/src-02-part2-statement-of-requirements.md and sources/src-04-part3a-response-technical.md. Priority codes: M mandatory (failure = unviable), D desirable (materially improves viability), O optional.

Biometric Capture & Liveness Detection (LV)

ID	Priority	Requirement
LV-1	M	Capture biometric images of sufficient quality for biometric comparison, complying with ISO/IEC 29794-5 when generating the image quality profile of the acquired image.
LV-2	M	Implement automated image-quality controls within its biometric capability and provide clear UI guidance to direct a user to capture an image that meets the required image quality profile.
LV-3	M	Employ Presentation Attack Detection (PAD) to determine whether the acquired image originates from a living human subject present at the point of capture.
LV-4	M	Complete image capture and PAD as part of a single continuous process before the image is submitted to the ATO system for online biometric verification, to prevent exploitation via separation of acquisition and PAD.
LV-5	M	PAD technology meets at least Evaluation Assurance Level 2 (Level B) as defined by ISO/IEC 30107-3:2023 and the Digital ID (Accreditation) Data Standards.
LV-6	M	Tested or validated by a qualified third-party biometric testing entity experienced in ISO/IEC 30107 to evidence the PAD meets EAL-2 (Level B).

Technical Verification & Biometric Binding (TV)

ID	Priority	Requirement
TV-1	M	For foreign ePassport technical verification: (a) comply with relevant sections of ICAO Doc 9303 for remote PKI verification; and (b) check published CRLs or equivalents for ePassport cancellation status.
TV-2	M	Online biometric binding MUST: complete binding within a single continuous workflow; include liveness detection as part of PAD; execute PAD at the point of capture; complete capture and PAD prior to submission for binding; use PAD technology incorporating data from both the capture subsystem and system-level monitoring consistent with ISO/IEC 30107-1.
TV-3	M	Biometric matching algorithm achieves FMR ≤ 0.01 % and FNMR ≤ 3 % at a 90 % confidence interval, per ISO/IEC TS 19795-9:2019.

Scalability (S), Performance (P), Availability (A)

ID	Priority	Requirement
S-1	M	Scalable to meet performance requirements under variable and increasing usage.
S-2	M	Support SaaS solution.
P-1	M	Support peak loads of 10 000 verifications/hour with 95th-percentile response time ≤ 1000 ms.
P-2	M	Provide: (i) Licensed Software performance metrics and test regimes used; (ii) infrastructure design specifications; (iii) a Software Capacity Plan and supplier strategies for scaling.
A-1	M	Achieve or exceed 99.95 % availability.

Hosting (H), Integration (IN)

ID	Priority	Requirement
H-1	M	Cloud-hosted SaaS offering, delivered via a secure, scalable, vendor-managed environment.
H-2	M	If cloud-based, describe connectivity with current AWS technologies and services, connectivity methods (e.g. AWS PrivateLink), and resources required from ATO to support connectivity.
IN-1	M	Support the Microsoft MAUI development environment and provide bindings for client API access.
IN-2	M	Support operation through standard web browsers (Chrome, Safari, Edge, Firefox) in addition to mobile platforms.
IN-3	M	Where not hosted within an ATO Software Service, MUST not require server affinity.
IN-4	M	Support silent automated deployments including IaaS, where ATO is responsible for deployment.
IN-5	D	Provide two short case studies demonstrating delivery of similar services in high-volume, large-scale deployments, including references.

Security & Confidentiality (SC)

ID	Priority	Requirement
SC-1	M	Evidence of ability to comply with PSPF, ISM, Essential 8 and other security requirements as defined in the Digital ID Act 2024.
SC-2	M	Demonstrate compliance with the Australian Privacy Principles.
SC-3	D	Secure all collected/held/used data (PI, ATO Data, ATO Material, inter-agency information) in use and at rest using ASD-approved cryptographic algorithms consistent with the Australian Government ISM or NIST.
SC-4	D	Controls to ensure integrity of data generated within the client software or provided to the Facial Verification Service.
SC-5	M	MUST NOT transfer Personal Information outside Australia.
SC-6	M	Capable of meeting relevant ISM controls to allow the ATO’s Information Security Advisor to issue certification at the PROTECTED level.
SC-7	M	All Personal and ATO data hosted and stored in Australia, complying with Australian data sovereignty laws and the Data Hosting Certification Framework.
SC-8	D	List all products used in delivery of Licensed Software, their function, whether third-party, and any access those products have to user data.

Operations (OP), Vendor Implementation Support & Maintenance (VISM), Maintainability (M)

ID	Priority	Requirement
OP-1	M	Secure, isolated non-production environments coupled with 24×7 monitoring.
OP-2	D	Dynamic, automated test environments with integration testing.
OP-3	M	Maintain data sovereignty and provide internal real-time service status visibility.
OP-4	M	Continuously monitor access and privileged activities.
OP-5	M	Assurance that system access is limited to approved IP ranges that are regionally localised.
OP-6	D	Mechanisms to detect early indicators of stress or coercion among personnel interacting with sensitive systems.
OP-7	M	Real-time alerts for high-risk or policy-violating behaviours, including biometric failures.
OP-8	D	Tiered alerting based on risk severity; detect abnormal access or potential data loss incidents.
OP-9	M	Australian-based NV1-cleared support, ISM-compliant timelines, governance reporting, secure incident management via an iRAP-certified portal.
OP-10	M	Dedicated helpdesk, roadmap for fraud prevention, knowledge transfer; demonstrate experience with government identity systems and security certifications, plus SLA management and governance.
VISM-1	M	Solution-specific support and troubleshooting via a formal helpdesk function.
VISM-2	M	Documented processes, manuals and operational instructions.
VISM-3	M	Ongoing support to keep software up-to-date with regular patching and updates.
VISM-4	M	Ongoing platform maintenance services.
VISM-5	D	Roadmaps and planned updates in fraud prevention and identity technology.
VISM-6	D	Demonstrate proven experience in successful implementation of similar systems in other government agencies.
VISM-7	D	Describe emerging technologies and recommendations based on vendor research.
M-1	M	Keep Licensed Software up-to-date through maintenance and patches (including security patches) for the Licensed Software and any third-party components.

Reporting & Monitoring (RM), User Experience & Accessibility (UX)

ID	Priority	Requirement
RM-1	M	Centrally log system activity (security settings, verification activities) and support shipping logs to ATO’s logging system.
RM-2	M	Configurable metrics, dashboards and drill-down visualisations (e.g. capture-time statistics, failure-to-enrol/acquire rates).
RM-3	M	Provide ATO with appropriate access to view logs (requests, response payloads, processing status) for troubleshooting.
RM-4	M	Describe monitoring capability or integration options.
UX-1	M	Support Mobile First and Responsive Web Design methodologies.
UX-2	M	Provide UI standards, UI screen designs, and UX documentation including user-flow mappings.
UX-3	M	Conform to WCAG 2.1 Level AA for mobile and web browser experiences.
UX-4	M	Ability for the ATO to customise user experience elements.

Cross-cutting headline business requirements (from §6 Overview)

Secure — detect/prevent spoofing, deepfakes, identity threats; biometric match rates (FAR/FRR) per Digital ID Act 2024
User-friendly — quick, simple, accessible for all users including those with accessibility needs
Device compatibility — wide range of mobile devices, platforms, browsers, OSes
Accessible — meets minimum WCAG requirements as defined in Digital ID Act 2024
Scalable — high volumes, consistent performance, reliability, uptime
Cost-effective — sustainable pricing aligned with Commonwealth procurement frameworks
Compliant — Digital ID Act 2024 liveness/biometric verification standards and disclosure requirements
Integratable & maintainable — seamless integration with existing ATO infrastructure and future architectures
Value for money

Linked notes

key-dates

Key Dates

Date	Event
23-Apr-2026	RFI-15434 published on AusTender
2026 (after publish)	Addendum 1 issued — see `attachments/08-addendum-1.pdf`
2026 (after Addendum 1)	Addendum 2 issued — see `attachments/09-addendum-2.pdf`
4-Jun-2026 14:00 ACT	RFI close — responses must be lodged via AusTender by this time
TBD (post-RFI)	ATO analyses responses; may proceed to Shortlist / RFT / RFQ / LT / PoC / PD or close

Lodgement

Channel: AusTender Lodgement Page — https://www.tenders.gov.au/Atm/ResponseLodgeForm/cea1b989-ceb0-4b36-8b48-ac1330062362
Physical address (for hard-copy): 26 Narellan Street, Canberra City ACT 2601 (electronic via AusTender is the normal channel)

Internal milestones (working back from close)

Internal date	Milestone
2026-06-01 (Mon)	Draft v1 of Part 3, Part 3a, Part 4, Part 4a, FOCI complete
2026-06-02 (Tue)	Internal review by Hugo + co-signatory; technical accuracy pass
2026-06-03 (Wed)	Final edit + dry-run lodgement (upload to AusTender as draft)
2026-06-04 09:00 ACT	Submit — minimum 5-hour buffer before 14:00 ACT close

Note: the AusTender Helpdesk is closed Mon 1-Jun-2026 for Reconciliation Day public holiday. Plan around that.