Part 3a — Response Form (Technical) — Compliance Matrix — DRAFT
Transcribe each row into the XLSX template
../attachments/04-part3a-response-technical.xlsx— Column D = Response Compliance (drop-down: Compliant / Partially Compliant / Non-Compliant); Column E = Vendor Comments.
Biometric Capture and Liveness Detection
| # | Compliance | Vendor Comment |
|---|---|---|
| LV-1 | Compliant | SABLE captures face embeddings via standard smartphone camera through the sable-core/biometric module. Image-quality scoring operates at capture time against the ISO/IEC 29794-5 image quality profile (sharpness, illumination uniformity, pose, occlusion). The quality profile output is exposed via the FFI for downstream verification. |
| LV-2 | Compliant | The capture SDK rejects out-of-spec frames in real time and returns user-facing guidance codes (face-too-close, face-too-far, low-light, off-axis, motion-blur, occlusion-detected). UI strings are configurable per ATO branding and language. Reference integrations exist today for native Swift (iOS) and Kotlin (Android); a reference MAUI implementation will be delivered alongside the MAUI bindings (see IN-1). |
| LV-3 | Compliant | SABLE employs an active spatial-flash presentation-attack detection technique adapted from Tang et al., NDSS 2018, “Face Flashing: a Secure Liveness Detection Protocol based on Light Reflections”. The device screen flashes a split-screen pattern of computer-derived colours over 3 rounds; the camera captures how the flash reflects off the user’s face. A real 3D face reflects the split-pattern differently in upper vs lower regions (forehead vs chin); a flat photo or screen replay reflects identically. Cosine-similarity between regional delta vectors discriminates 3D from 2D presentation. |
| LV-4 | Compliant | Capture, PAD, and Halo2 proof generation execute in a single continuous on-device pipeline that takes approximately 10 seconds end-to-end (3 spatial-flash rounds at ~2.5 s each + ~250 ms proof generation). The proof cryptographically binds the captured biometric features, the per-region PAD reflectance fingerprints, and the session-binding nonce — they cannot be decoupled or replayed independently. |
| LV-5 | Partially Compliant | The spatial-flash technique is a published, peer-reviewed PAD methodology with demonstrated effectiveness against photo, video, and screen-replay attacks. Formal ISO/IEC 30107-3:2023 EAL-2 (Level B) testing by a qualified third-party laboratory has not yet been undertaken; Anuna Research Cooperative commits to engaging an ILAC-accredited testing laboratory with the required ISO/IEC 30107 scope for formal certification within 3-4 months and budgets ~AUD 60-100 k for this activity. No lab arrangement is in place at the RFI stage; specific lab selection would be a procurement-stage activity. Per Addendum 1 Q1, the test report will document: accreditation scope, test methodology, ISO/IEC 30107 version used, PAD assurance level assessed, and any limitations or exclusions. Internal red-team test results against printed photos, phone-screen replays, video replays, and 3D-printed masks available on request. |
| LV-6 | Partially Compliant | As LV-5. Anuna Research Cooperative will provide an ILAC-accredited third-party PAD test report inside a procurement evaluation phase, evidencing the body’s qualifications, accreditation scope, test methodology, ISO/IEC 30107 version, PAD assurance level, and any limitations per Addendum 1 Q1. Vendor self-assessment evidence is available immediately. |
Technical Verification and Biometric Binding
| # | Compliance | Vendor Comment |
|---|---|---|
| TV-1 | Partially Compliant | ICAO Doc 9303 NFC ePassport verification (BAC / PACE, Active Authentication, Document Signer Certificate validation, Master List handling, CRL checking) is not yet shipped in SABLE core. The sable-core/attestation module is architected to support X.509-style chain validation; ICAO 9303 PKI verification adds approximately 8-12 weeks of development effort. Implementation will leverage proven open-source libraries (jMRTD on Android, libICAOCertificate on iOS) wrapped through our FFI. Commitment to deliver inside a procurement evaluation phase. |
| TV-2 | Compliant | The single continuous on-device pipeline binds biometric capture, presentation-attack detection, and credential binding into one atomic Halo2 proof. PAD operates at point of capture; the entire pipeline runs to completion before any proof is submitted for verification. Data from both the data-capture subsystem (camera EXIF metadata, frame timing, sensor confidence scores) and system-level monitoring (challenge nonce binding, device attestation key signatures) feed the Halo2 circuit per ISO/IEC 30107-1. |
| TV-3 | Partially Compliant | Formal FMR / FNMR benchmarking against ISO/IEC TS 19795-9:2019 protocol with 90 % confidence interval is not yet completed. SABLE’s matching uses Pedersen-committed Poseidon-hashed 1024-dimension face embeddings with a configurable Hamming-distance threshold inside the Halo2 circuit. Matching accuracy depends primarily on the embedding extractor model; we propose using a state-of-the-art extractor (e.g. ArcFace / MagFace) tuned to the operational target. Anuna Research Cooperative commits to running a formal ISO/IEC TS 19795-9 evaluation against a representative diverse cohort per the Digital ID Accreditation Data Standards — including individuals with disability, individuals with diverse abilities (including ability to use technology), and individuals across a diverse range of age, gender, and ethnicity (Addendum 1 Q2) — using a combination of IJB-C / MS-Celeb-1M demographic-balanced subsets and an Australian-cohort sample. FMR/FNMR reported at 90 % CI within the procurement evaluation window (4-6 weeks). The benchmark applies to the SABLE matching algorithm (not to the FVS algorithm). |
Scalability, Performance, Availability
| # | Compliance | Vendor Comment |
|---|---|---|
| S-1 | Compliant | Halo2 verification is stateless (no session affinity, no shared memory, no in-flight state). The proposed SaaS verification endpoint runs as a horizontally-scaled EKS deployment behind an Application Load Balancer in AWS ap-southeast-2. Capacity scales linearly with pod count; autoscaling responds to request-per-second and p95-latency metrics. |
| S-2 | Compliant | The proposed deployment wraps the open-source SABLE library as a hosted SaaS verification service on AWS Sydney. The library remains client-side (embedded in the myID app); only the ZK proof and metadata reach the SaaS. |
| P-1 | Compliant | 10 000 verifications/hour = ~2.8 verifications/second average peak; Halo2 verification on a single AWS Graviton3 m7g.medium instance benchmarks at ~1.8 ms per proof (single-threaded), enabling > 500 verifications/second per instance — three orders of magnitude headroom against the stated peak load. P95 latency budget of ≤ 1000 ms is comfortable: ~1.8 ms verification + ~10-15 ms network round-trip from ATO infrastructure inside ap-southeast-2 + ~5 ms application overhead = ~30 ms total p95. |
| P-2 | Compliant | We provide as part of this response: (i) measured verification latency distributions on Apple Silicon, AWS Graviton3, and Intel Xeon reference platforms with histogram + tail-latency analysis; (ii) AWS infrastructure design — VPC with three-AZ EKS cluster, ALB with health-checked targets, CloudFront for static assets, RDS for audit only (no PII), KMS for envelope encryption, AWS PrivateLink endpoint to ATO VPC; (iii) Software Capacity Plan projecting capacity at 1×, 10×, 100×, 1000× the stated peak load (50 000 verifications/hour, 500 000/hour, 5 M/hour, 50 M/hour) with associated EKS node sizing, RDS storage, and estimated monthly AWS spend at each tier. |
| A-1 | Compliant | The proposed deployment is a Multi-AZ EKS in ap-southeast-2 (Sydney) across three Availability Zones; ALB health checks every 5 seconds with 2-failure deregistration; RDS Multi-AZ with synchronous standby; RTO < 5 minutes; RPO = 0 for the audit log. Committed SLA: 99.95 % monthly uptime. As a bonus, SABLE’s on-device capture / PAD / proof-generation pipeline is 100 % available offline — only final verification touches the SaaS, so user-facing failures are limited to the few seconds of network call. |
Hosting and Integration
| # | Compliance | Vendor Comment |
|---|---|---|
| H-1 | Compliant | The proposed deployment is a cloud-hosted SaaS on AWS Sydney (ap-southeast-2), vendor-managed by Anuna Research Cooperative. Three environments (Production, Staging, Development) in separate AWS accounts; AWS Organizations SCPs prevent replication outside ap-southeast-2. |
| H-2 | Compliant | Per Addendum 1 Q3, we describe two supported deployment models and let the ATO select the preferred path during a procurement-stage design activity. Model 1 — Vendor-managed SaaS (default proposal): Anuna Research Cooperative operates the Verification Service in ap-southeast-2; ATO connects via a VPC Endpoint Service / AWS PrivateLink to the SABLE Verification API — no internet egress, no public endpoint, no Transit Gateway. ATO-side dependencies: VPC Endpoint creation, IAM cross-account role for telemetry export, DNS resolver entry (~1-day ATO ops effort). Security controls: TLS 1.3 + mTLS + IAM least-privilege + WAF + GuardDuty. Model 2 — ATO-managed in ATO AWS environment: SABLE Verification Service deployed as a Helm chart on the ATO’s EKS cluster via Anuna-supplied Terraform; ATO owns infrastructure, security baseline, and patching cadence; Anuna provides licensed software, container images, support, release management, and operational runbooks. ATO-side dependencies: EKS cluster, ALB, IAM provisioning, container registry, monitoring stack. Operational implications (Model 2): ATO assumes infrastructure / IRAP boundary; Anuna’s IRAP cert is for the software component; combined IRAP scope must be negotiated; commercial impact: lower SaaS subscription, higher implementation + support fee. |
| IN-1 | Partially Compliant | SABLE has FFI for Android (JNI) and iOS (Swift). Microsoft MAUI bindings have not yet been published but are mechanical to generate: SABLE core exposes a C ABI via cbindgen, on top of which a .NET P/Invoke layer + MAUI NuGet package can be built. Effort estimate: 4-6 weeks including a sample MAUI integration project and unit-test coverage. Anuna Research Cooperative commits to delivering MAUI bindings inside a procurement evaluation phase. |
| IN-2 | Compliant | The SABLE web frontend (demo/web/) 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. Browser-based path is fully feature-equivalent to the native iOS / Android implementation. |
| IN-3 | Compliant | The verification endpoint is stateless — no server affinity, no sticky sessions, no in-memory request state. Any request can hit any pod. Session-binding nonces are validated cryptographically inside the proof, not against server-side state. |
| IN-4 | Compliant | Deployment is fully Infrastructure-as-Code (Terraform modules provided as part of the delivered software package); the ATO can run terraform apply against its AWS account for a silent automated deployment. CI pipelines (GitHub Actions templates) provided. Per-environment configuration via SSM Parameter Store + sealed-secrets pattern. |
| IN-5 | Partially Compliant — Desirable | Most directly relevant delivery-capability reference: Bangsamoro Autonomous Region in Muslim Mindanao (BARMM), Philippines — Anuna Research Cooperative is the delivery partner building eGov services for the BARMM regional government, with scope spanning digital identity, citizen-facing eGov service delivery, and transformation advisory. Production go-live: July 2026. This is a government-of-government digital identity and eGov programme delivered end-to-end by Anuna with the same cooperative practitioner team that would deliver any ATO SABLE engagement. BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension. By the time any post-RFI ATO procurement stage commences, BARMM will be in production with months of operational track record as evidence of delivery capability. International interest in SABLE specifically: Anuna is in early dialogue with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI) about the SABLE approach. Adjacent enterprise / public-sector references: UK Government Digital Service (GovUK), CSIRO Data61, Microsoft, Autodesk, Suncorp, IAG, Telus, Telefónica. References available on request. We also offer a paid Proof-of-Concept against ATO’s existing myID test cohort as the most decisive direct evidence for SABLE specifically in the ATO context. |
Security and Confidentiality
| # | Compliance | Vendor Comment |
|---|---|---|
| SC-1 | Partially Compliant | The SaaS shell will be designed against the PSPF, ISM, and Essential 8 from day one: multi-factor admin authentication, application allow-listing on production hosts, daily backups, ~daily patching cadence with 4-hour-Critical SLA, OS hardening per ASD STIG profiles, etc. Full IRAP assessment evidencing compliance is a procurement-stage activity; commitment to engage an IRAP assessor inside the procurement evaluation phase. |
| SC-2 | Compliant | SABLE’s defining property is that biometric data never leaves the user’s device. APP 1 (open and transparent management of personal information): SABLE is open-source and fully auditable. APP 3 (collection of solicited PI): we collect only the ZK proof + minimal metadata, never the biometric. APP 5 (notification of collection): the on-device capture flow surfaces a clear privacy notice. APP 6 (use and disclosure): the ZK proof reveals only the verification outcome plus selectively-disclosed predicates. APP 11 (security of PI): biometric data is committed-and-hidden in Pedersen commitments — even a total SaaS compromise exposes no biometric data. APP 12-13 (access and correction): users hold their own biometric template; ATO never has it to access or correct. |
| SC-3 | Partially Compliant — Desirable | SABLE uses BLS12-381 (128-bit security level, widely deployed, foundational to Zcash and Ethereum BLS signatures), Poseidon (peer-reviewed ZK-friendly hash), ChaCha20-Poly1305 (NIST / ISM-listed AEAD), and X25519 (NIST / ISM-listed ECDH). BLS12-381 is not yet on the ASD HACE catalogue but is aligned with NIST PQC and IETF CFRG positions. Where strict HACE compliance is required, Anuna Research Cooperative will provide a parallel cryptographic path using ASD-approved primitives (P-256 with SHA-256 in classical-only mode) for environments that require it. |
| SC-4 | Compliant — Desirable | The Halo2 ZK proof IS the integrity control. The proof cryptographically binds (a) the captured biometric features, (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; the verifier cannot be deceived by altered client-side data. |
| SC-5 | Compliant | Personal Information never crosses the boundary at all. Per Addendum 1 Q11, SC-5 applies to the full delivery chain — subcontractors, sub-processors, PAD providers, hosting providers, support providers, telemetry, logging. SABLE’s architecture means no party in our delivery chain ever processes Personal Information: biometric data never leaves the user’s device; the ZK proof carries no PI; the SaaS endpoint receives no PI; subcontractors (NV1 support, managed SOC) operate on non-PI operational telemetry only; AWS Sydney is the sole infrastructure provider and ap-southeast-2 is the sole region with SCP-enforced no-replication-out. Only the ZK proof, the session-binding nonce, and (optionally) selectively-disclosed predicates traverse the network. The SaaS verification endpoint cannot reconstruct biometric data even with full database access. Operational telemetry (request counts, latency histograms) contains no PI. This is a structurally stronger position than the “PAD vendor on Australian infrastructure” scenario clarified in Addendum 1 Q11 — we have no PI-touching PAD vendor in our chain because PAD runs on the user’s device. |
| SC-6 | Partially Compliant | PROTECTED-level ISM certification not yet held. Per Addendum 1 Q10, the proposed IRAP assessment scope includes: (a) production platform — SABLE Verification Service in ap-southeast-2; (b) management plane — admin console, deployment pipelines; (c) support portal — ServiceNow-based ticket / incident portal; (d) administrative tooling — IAM, KMS, CI/CD, observability stack; (e) integrations — PrivateLink endpoint, log-shipping pipeline to ATO SIEM; (f) logging / monitoring — CloudWatch, GuardDuty, audit S3 buckets; (g) connected environments — Anuna corporate Atlassian / GitHub Enterprise where source-of-truth lives. Current assessment status: no IRAP assessment commenced; commitment to engage an IRAP assessor inside the procurement evaluation phase. Residual gaps: all ISM controls untested by IRAP; mitigated by ISM-first design from day one of the SaaS build. Timeline: IRAP assessment + PROTECTED certification estimated at 6-8 months elapsed, aligned with production-readiness milestones; spend ~AUD 150-250 k. The architecturally-minimised attack surface (no PI server-side; stateless verification; open-source codebase) materially simplifies the IRAP path. |
| SC-7 | Compliant | All Personal data and ATO operational data hosted in ap-southeast-2 (AWS Sydney). AWS Organizations SCPs enforce data sovereignty: no replication, no snapshot copy, no S3 cross-region transfer outside ap-southeast-2. AWS Sydney holds Certified Strategic Hosting Provider classification under the Data Hosting Certification Framework. |
| SC-8 | Compliant — Desirable | Full Software Bill of Materials (SBOM) produced via cargo cyclonedx and npm sbom for each release, listing every dependency, version, licence, and access scope. Third-party components in SABLE: Halo2 (PSE / Zcash), Poseidon (academic reference), ChaCha20-Poly1305 (RustCrypto), X25519 (RustCrypto), JNI bindings (open-source). No third-party components have access to user biometric data. SBOM published with every release artefact. |
Operations, Vendor Implementation Support & Maintenance, Maintainability
Implementation note for the proposed SaaS Verification Service: SABLE (the library) is a pre-production open-source project today; the SaaS Verification Service is the proposed commercial wrapper that would be built to deliver SABLE for ATO myID. The operational descriptions below describe the proposed production architecture and operating model; specific commitments (SLAs, support staffing, named on-call) will be operationalised during the procurement evaluation phase and in proportion to the ATO scope. Anuna Research Cooperative’s existing operational practices for its software portfolio inform the design.
| # | Compliance | Vendor Comment |
|---|---|---|
| OP-1 | Compliant | The proposed production architecture is a standard three-environment design (Production, Staging, Development) with isolation enforced at the AWS account level. 24×7 monitoring via Amazon CloudWatch + an Australian on-call paging provider; a named L2 / L3 on-call rota will be in place at production go-live, scaled in proportion to the ATO contract scope (founder + cleared-subcontractor team per OP-9). |
| OP-2 | Compliant — Desirable | The SABLE library already uses GitHub Actions CI/CD; the proposed SaaS deployment pattern uses GitHub Actions to spin up ephemeral per-PR test environments via Terraform, with integration tests on PR open and on merge to main, and per-environment teardown after PR close. |
| OP-3 | Compliant | Data sovereignty will be enforced via AWS Organizations Service Control Policies preventing replication outside ap-southeast-2. Real-time service status will be exposed via internal Amazon CloudWatch dashboards and a public status page for the ATO operations team. |
| OP-4 | Compliant | The proposed architecture uses Amazon CloudTrail to record every API call and every privileged administrative operation; Amazon GuardDuty for anomaly detection; AWS Config for configuration drift; and logs shipped to a dedicated audit S3 bucket with Object Lock for immutability. |
| OP-5 | Compliant | Access will be enforced at two layers: (a) the VPC PrivateLink endpoint (restricted to the ATO VPC by Endpoint Policy); (b) the application authentication layer (mTLS client-certificate authentication, with ATO IP ranges as an additional allow-list). All IP ranges regionally localised to Australia. |
| OP-6 | Compliant — Desirable | Per Addendum 1 Q14, this requirement is for organisational and operational controls, not clinical assessment. Anuna Research Cooperative’s practice (proportionate to its current scale, with documented uplift planned in parallel with any ATO engagement) covers: (a) security awareness training for all personnel including ACSC Essential 8 awareness, social-engineering and coercion-resistance content; (b) escalation pathways documented in the security policy; (c) welfare / supervision processes — regular 1:1s, peer support, referral pathways; (d) privileged access monitoring via AWS CloudTrail + GuardDuty; (e) separation of duties for sensitive operations (release approval requires two signatories; key-management operations require dual control); (f) peer review for sensitive actions (all production-affecting changes require code review + change-management approval); (g) incident reporting via documented runbook with mandatory disclosure to the ATO Security Officer; (h) unusual access / behaviour detection via GuardDuty + CloudWatch Insights anomaly alerts. For ATO scenarios requiring greater scale, Anuna will partner with an Australian managed-SOC provider for managed insider-risk monitoring (no such arrangement is in place at the RFI stage; partner identification a procurement-stage activity). |
| OP-7 | Compliant | The proposed architecture wires Amazon EventBridge → Amazon SNS → on-call paging for high-risk patterns: PAD failure clusters (potential ongoing attack), brute-force enrolment attempts, geographic anomalies, request-rate anomalies, anomalous proof-verification failure rates. Target detection latency: < 1 minute. |
| OP-8 | Compliant — Desirable | Tiered alerting (Critical / High / Medium / Low) with per-tier response SLAs; anomalous access patterns (unexpected geographic origin, unusual time-of-day patterns, sudden burst of failed authentications) trigger automatic risk-tier escalation. Data-loss-prevention is structurally addressed: there is no PI server-side to lose. |
| OP-9 | Partially Compliant | Per Addendum 1 Q9, NV1-cleared support is required before personnel access PROTECTED / production systems, no later than production go-live. Current clearance status: Anuna Research Cooperative personnel hold no current NV1 clearance; no subcontractor arrangement is in place at the RFI stage. Sponsorship plan: Anuna Research Cooperative will (a) sponsor founder Hugo O’Connor for NV1 directly via AGSVA (~12 months elapsed); and (b) in parallel, engage an Australian Security Vetting Agency–cleared support subcontractor for immediate L2 / L3 access from a cleared pool, ensuring no gap between contract signing and production go-live. Partner identification, due diligence, and contracting would be a procurement-stage activity. Interim arrangements (per Addendum 1 Q9 mitigation menu): restricted-access role design (cleared subcontractor handles any access to PROTECTED data; uncleared Anuna engineers limited to non-PROTECTED development); supervised access (any uncleared Anuna access happens with cleared subcontractor supervision); role separation (no Anuna engineer holds keys to ATO production systems until cleared); deferral of access until clearance is granted. ISM-compliant incident management via an IRAP-assessed Australian incident portal. |
| OP-10 | Partially Compliant | Anuna Research Cooperative will provide: (a) a dedicated helpdesk with named L2 / L3 engineers, P1-to-P4 tiered SLAs, response-time commitments; (b) a public fraud-prevention roadmap covering deepfake detection improvements, post-quantum migration, multi-spectral liveness; (c) knowledge-transfer commitment via documentation, on-site workshops, pair-programming during transition. Government identity systems experience: Anuna is currently delivering eGov services (digital identity, citizen services, advisory) for the Bangsamoro Autonomous Region in Muslim Mindanao (BARMM) — production go-live July 2026; this is direct end-to-end government identity / eGov delivery with the same practitioner team. BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension. Adjacent context: UK Government Digital Service (GovUK), CSIRO Data61; early dialogue with Germany’s BSI on the SABLE approach. This RFI represents our first direct Australian federal government identity engagement; paid PoC against the myID test cohort offered as the most decisive evidence for SABLE in the ATO-specific context. Security certifications experience: held within the team across prior commercial engagements. SLA management and governance: documented runbooks, monthly governance reviews, quarterly executive reviews for Mission-Critical tier. |
| VISM-1 | Compliant | Helpdesk via a dedicated support email and Australian-hosted status page; proposed tiered SLAs with per-tier response-time commitments (indicative: P1 1-hour acknowledge / 4-hour update; P2 4-hour / 24-hour; P3 24-hour; P4 best-effort). Specific SLA levels confirmed in any procurement stage. |
| VISM-2 | Compliant | The SABLE library has a full public docs/ tree (technical specifications, API references, deployment guides) at codeberg.org/anuna/sable. Ops runbooks for the SaaS Verification Service will be ATO-private and version-controlled in a dedicated GitOps repository. |
| VISM-3 | Compliant | Anuna Research Cooperative’s commitment for the production deployment: monthly minor-version cadence; weekly dependency patching via Dependabot + Renovate; CVE response SLA of 4-hour triage / 24-hour patch for Critical, 7 days for High, 30 days for Medium. Published patching schedule. |
| VISM-4 | Compliant | Ongoing platform maintenance is in commercial scope: dependency patching, ZK circuit revisions as cryptographic best practice evolves, ASD HACE catalogue updates, ISM control delta tracking, AWS service deprecation migration. |
| VISM-5 | Compliant — Desirable | Public roadmap maintained alongside the SABLE library on Codeberg. Already on the roadmap: BBS+ Verifiable Credentials with selective disclosure; post-quantum migration (CRYSTALS-Dilithium signature path; hash-based commitment alternatives for cryptography); multi-spectral liveness (IR camera path for higher-assurance PAD); continuous authentication (behavioural-biometric layer). |
| VISM-6 | Partially Compliant — Desirable | Anuna Research Cooperative’s current BARMM (Philippines) eGov programme — production go-live July 2026 — is direct implementation of a government-of-government digital identity / eGov system (digital identity, citizen services, advisory; BARMM does not currently deploy SABLE). Adjacent government-context experience includes UK Government Digital Service (GovUK) and CSIRO Data61. Early international dialogue on the SABLE approach with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI). No prior implementation of biometric identity systems in Australian federal government specifically; the closest direct evidence available to either party in this RFI window is a paid Proof-of-Concept against ATO’s myID test cohort — we offer this. |
| VISM-7 | Compliant — Desirable | Active research programme at Anuna Research Cooperative. Emerging-technology recommendations: (a) post-quantum identity via NIST PQC integration (CRYSTALS-Dilithium, CRYSTALS-Kyber, SPHINCS+); (b) zero-knowledge KYC (proving identity properties without revealing identity itself); (c) offline-first identity proofs for low-connectivity / disaster-recovery scenarios; (d) homomorphic-encrypted biometric matching as a complementary capability where on-device proof generation is not feasible; (e) international interoperability of open-source identity primitives — SABLE being Apache 2.0 enables interoperability with any other government adopting the same primitives; candidate future adopters include Anuna’s existing BARMM (Philippines) eGov engagement as a natural extension, European public-sector identity stakeholders (early dialogue with Germany’s BSI), Pacific / SEA governments, and adjacent use cases (age verification, healthcare, building access) where the privacy-by-construction property is valuable. |
| M-1 | Compliant | See VISM-3. cargo audit runs in CI on every PR; out-of-date dependencies block merges to main. Third-party JavaScript dependencies (web frontend) tracked via npm audit with similar gating. |
Reporting and Monitoring
| # | Compliance | Vendor Comment |
|---|---|---|
| RM-1 | Compliant | All API activity, configuration changes, and security-relevant events logged via Amazon CloudWatch Logs. Optional log-shipping to ATO’s SIEM via Amazon Kinesis Firehose → ATO endpoint (Splunk HEC, Azure Sentinel HTTPS, custom). |
| RM-2 | Compliant | Amazon CloudWatch + Grafana dashboards out-of-the-box: capture-time distribution, PAD pass/fail rates by region and device type, FMR/FNMR over time, regional latency percentiles, error rates, throughput. ATO can customise via Grafana with read access to underlying CloudWatch metrics. |
| RM-3 | Compliant | ATO read-access via IAM cross-account roles: read access to CloudWatch Logs Insights, read access to S3 audit-log bucket. Sample CloudWatch Logs Insights queries provided in the runbook for: “all verification failures in last 24h”, “PAD failure clusters by device model”, “p99 latency by region”, etc. |
| RM-4 | Compliant | Native integration with: Amazon CloudWatch (default), Datadog (via AWS Lambda forwarder), Splunk (via HTTP Event Collector), ATO existing SIEM (via Kinesis Firehose log-shipping). Custom integrations supported via standard CloudWatch metric streams and OpenTelemetry. |
User Experience and Accessibility
| # | Compliance | Vendor Comment |
|---|---|---|
| UX-1 | Compliant | Mobile-first capture flow + responsive web fallback. Native iOS / Android implementations are first-class; the WASM web build is verified on phones, tablets, desktops with viewport-aware layout, touch-first controls, and progressive enhancement. |
| UX-2 | Compliant | The SABLE demo (demo/web/) and reference iOS / Android integrations carry UI standards for the capture flow (typography, colour palette, iconography, error-state design) and user-flow documentation for Enrolment, Authentication, Account Recovery, and Error States. ATO-branded Figma library + Accessibility Mode flow maps will be produced as part of the WCAG 2.1 AA delivery package (see UX-3). |
| UX-3 | 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 not yet completed (no audit firm arrangement in place at the RFI stage; firm selection a procurement-stage activity). Commitment to complete audit + remediation within 4-6 weeks. Accessibility-mode liveness alternative (audio prompts, larger UI elements, single-flash colour challenge, screen-reader-friendly flow) on the roadmap for users with visual / motor / cognitive needs. |
| UX-4 | Compliant | Branding (colours, fonts, logos), copy (multi-language), capture-flow step sequencing, challenge parameters (flash duration, number of rounds, threshold tightness) are all configuration-driven, not code changes. ATO branding can be applied without engaging Anuna Research Cooperative engineering. |
Compliance Summary
(Reflects Addendum 1 clarifications — see addenda-clarifications.)
| Category | Compliant | Partially Compliant | Non-Compliant |
|---|---|---|---|
| LV (Liveness) | 4 | 2 | 0 |
| TV (Technical Verification) | 1 | 2 | 0 |
| S / P / A | 5 | 0 | 0 |
| H / IN | 5 | 2 | 0 |
| SC (Security) | 5 | 3 | 0 |
| OP / VISM / M | 15 | 3 | 0 |
| RM | 4 | 0 | 0 |
| UX | 3 | 1 | 0 |
| Total | 42 | 13 | 0 |
(OP-6 was Partially Compliant in the initial draft; Addendum 1 Q14 clarifies the requirement is for organisational controls — Anuna Research Cooperative is Compliant on the reframed requirement.)
Zero Non-Compliant requirements. 13 Partially Compliant requirements all have explicit remediation paths and timelines — see gaps-and-risks for the consolidated remediation programme.
End of Part 3a draft.