Part 3 — RFI Response Form — General — DRAFT

Transcribe into the DOCX template in ../attachments/03-part3-response-general.docx. Section structure and headings preserved exactly.

Section 1 — The Conditions for Participation

Judicial decisions relating to employee entitlements

Anuna Research Cooperative confirms that neither it nor any subcontractor identified in this Response has any unpaid claims in respect of judicial decisions (other than decisions subject to appeal) made against it relating to employee entitlements.

In the event of a future procurement stage, evidence will be provided on request.

Workplace Gender Equality

Anuna Research Cooperative is not a “relevant employer” for the purposes of the Workplace Gender Equality Act 2012 (Cth) — its employee headcount is below the 100-employee threshold that triggers WGEA reporting. We confirm we comply with all applicable workplace gender equality obligations.

Satisfactory Statement of Tax Record

Anuna Research Cooperative confirms that it will hold a valid and satisfactory Statement of Tax Record (STR) by the Closing Time of any future procurement process (or receipt of an STR request from the ATO, with a valid STR within 4 business days). Where any subcontractor proposed for a future stage delivers Required Supplies valued over $4 million GST-inclusive, an STR for that subcontractor will be provided at that time.

Indigenous Procurement Policy

Anuna Research Cooperative acknowledges the Indigenous Procurement Policy (IPP) and Commonwealth commitment to Indigenous entrepreneurship. In the event of a future procurement stage:

• Current Indigenous employment rate: to be reported accurately at that time (Anuna Research Cooperative is a small company; the figure will be reported precisely)
• Current Indigenous supplier use: as above
• Proposed Indigenous Participation Plan: Anuna Research Cooperative will commit to an Indigenous Participation Plan addressing the IPP’s minimum mandatory requirements (MMR) appropriate to the scale of the engagement, including subcontracting to Indigenous-owned firms (e.g. via Supply Nation) for delivery components where capability exists
• Prior MMR exposure: Anuna Research Cooperative has not previously been subject to MMR targets

Commonwealth Supplier Code of Conduct

Anuna Research Cooperative acknowledges the Commonwealth Supplier Code of Conduct and confirms it has — and will maintain — policies, frameworks and governance practices appropriate to its size that comply with the Code’s expectations on ethics, corporate governance, business practices, and health, safety and employee welfare. We undertake to extend these expectations to all subcontractors.

ISO 14001 Environmental Management System

(Addendum 1 Q15.) Anuna Research Cooperative does not currently hold ISO 14001 certification and does not currently operate a formally aligned Environmental Management System. Anuna Research Cooperative is able to align business processes to ISO 14001 within six months of contract signing and to maintain that alignment for the term of any contract. Planned uplift activities: engage an Australian ISO 14001 consultant for gap assessment + EMS framework development; document environmental aspects (energy use of cloud infrastructure, business travel, hardware lifecycle); set environmental objectives (carbon-aware cloud deployments via AWS Customer Carbon Footprint Tool; reduction of physical travel via remote-first operations); implement monitoring + measurement (annual carbon assessment); internal audit + management review cycle. Responsible owner: Founder. Expected timeframe: alignment within 6 months of contract signing; certification within 12-18 months if required by procurement scope.

Anuna Research Cooperative will be a signatory to the Australian Packaging Covenant or will comply with the National Environment Protection (used packaging materials) measure if a procurement progresses to a contract — noting that SABLE is software, with negligible physical packaging exposure.

Outcome of this RFI Process

Anuna Research Cooperative acknowledges that the ATO may proceed with a second stage including Shortlist / RFT / RFQ / Limited Tender / Proof of Concept / Product Demonstration / RFI closure, and confirms our interest in participating in any such second stage.

Section 2 — Respondent’s Details

Information about the Respondent

Respondents’ compliance with conditions

General information about the Response

Section 3 — Respondent Information

Details of Response

About Anuna

Anuna Research Cooperative (“Anuna”) is an Australian cooperative working on trustworthy AI systems. Anuna positions as “applied AI research, done through the work itself” — integrating AI engineering, organisational design and governance as one unified practice, and conducting research through live client engagements so that each piece of work improves our tools and methods.

Anuna’s practitioner team holds a small set of complementary disciplines:

Anuna’s prior client engagements (representative, in addition to others not listed): Microsoft, Autodesk, CSIRO Data61, Telus, Kellogg School of Management, Suncorp, IAG, the UK Government Digital Service (GovUK), Telefónica, University of Wollongong.

Directly-relevant current engagement (delivery-capability reference): Bangsamoro Autonomous Region in Muslim Mindanao (BARMM), Philippines — Anuna is the delivery partner building eGov services for the BARMM regional government, with scope spanning digital identity, citizen-facing eGov service delivery (forms, portals), and transformation advisory. Production go-live: July 2026. This is the most directly relevant reference for RFI-15434 as a delivery-capability proof: 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. By the time any post-RFI ATO procurement stage commences, BARMM will be in production with months of operational track record available as direct evidence of delivery capability. Note: BARMM does not currently deploy SABLE; future SABLE deployment at BARMM is a candidate natural extension of the existing engagement.

The GovUK and CSIRO Data61 engagements provide complementary OECD-grade public-sector context — UK government digital service work shares the standards bar, public-sector data sovereignty constraints, and accessibility requirements that the ATO operates under.

International interest in SABLE and adjacent use cases. The SABLE open-source library has attracted interest from public-sector stakeholders beyond the Pacific / Southeast Asian context. Anuna is in early dialogue with Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI) — the German federal cyber-security authority and natural OECD counterpart to ASD / ACSC — about the SABLE approach for European public-sector identity. Other plausible deployment contexts include other Pacific island nations, ASEAN member states, and OECD-allied digital-sovereignty initiatives. Beyond national digital identity, the underlying privacy-by-construction architecture extends to adjacent use cases: age verification for online services, healthcare patient verification (telehealth, prescription authorisation), building / facility access control, employer / contractor on-site identity, and peer-to-peer credential verification — wherever holding biometric or identity-document data centrally is a liability that an architectural alternative could retire.

Anuna’s open-source projects (publicly available at codeberg.org/anuna) include:

• SABLE — zero-knowledge biometric proofs (the subject of this Response)
• hence — defeasible logic for agent planning (used internally to coordinate this Response)
• spindle — non-monotonic logic engine in Rust
• sense — ambient retrieval across portfolios
• vibe harness — AI pacing to humans
• ebs — HRV research instrument
• cbcl — agent communication language
• cbcl-runtime — process-to-agent router
• zetl — sourced wiki for agents
• ar-crawl — agent-focused web crawler (used to retrieve the RFI documents in preparing this Response)

The breadth across cryptography, agent systems, knowledge representation, organisational design and adaptation reflects the cooperative’s practice of working across the full stack of trustworthy-AI delivery rather than operating as a point-solution vendor.

About SABLE

SABLE — Secure Attested Biometric Library for Edge is Anuna’s open-source (Apache 2.0) library for privacy-preserving biometric verification using Halo2 zero-knowledge proofs and active spatial-flash liveness detection.

Headline numbers for SABLE:

• 519 tests passing in the core library (89 % code coverage); 77 Halo2-specific tests
• ~250 ms proof generation on a modern smartphone; ~1.8 ms verification; 2 KB proof size
• Apache 2.0 licensed; full source publicly available at codeberg.org/anuna/sable
• Built on transparent-setup Halo2 (no trusted setup ceremony — eliminating a major class of cryptographic risk associated with older ZK systems), BLS12-381 / BN254, Poseidon hash, Pedersen commitments
• Active spatial-flash liveness detection adapted from the published Tang et al. NDSS 2018 methodology

To our knowledge, SABLE is the first open-source library to combine all of: true zero-knowledge proofs over biometric data, fully offline capable operation, no special hardware required, selective credential disclosure via BBS+ Verifiable Credentials, transparent ZK setup, and an Apache 2.0 licence.

How SABLE works — concrete walkthrough

This section gives a plain-language model of what SABLE is and how it works end-to-end. It is intended to be readable by an evaluator who is not a cryptographer; the underlying cryptographic primitives are summarised in the Technical building blocks table below, and documented in detail in the public SABLE codebase at codeberg.org/anuna/sable.

Components and where they run

 ┌─────────────────────────────────────────┐
 │           USER'S DEVICE                 │
 │  (myID app, browser, native iOS/Android)│
 │                                         │
 │   Camera ──▶ Image-quality control      │
 │              + spatial-flash liveness   │
 │              + 1024-dim face embedding  │
 │              + Pedersen commitment      │
 │              + Halo2 proof generation   │
 │              + (optional) BBS+ selective│
 │                disclosure of credential │
 │                attributes               │
 │                                         │
 │   Result: ~2 KB ZK proof + nonce        │
 │           + optional disclosed predicates│
 └────────────────┬────────────────────────┘
                  │
                  │  Only the proof + minimal
                  │  metadata cross this line.
                  │  No biometric data, no PI.
                  ▼
 ┌─────────────────────────────────────────┐
 │     SABLE VERIFICATION SaaS             │
 │      (AWS Sydney, ap-southeast-2)       │
 │                                         │
 │   Verify Halo2 proof  (~1.8 ms)         │
 │   Check session-nonce binding           │
 │   Record audit log (no PI)              │
 │                                         │
 │   Result: pass / fail + verified        │
 │           disclosed attributes          │
 └────────────────┬────────────────────────┘
                  │
                  │  AWS PrivateLink
                  ▼
 ┌─────────────────────────────────────────┐
 │     ATO myID + FVS / DVS infrastructure │
 │     (ATO AWS environment)               │
 │                                         │
 │   Consume pass/fail + disclosed attrs   │
 │   Continue existing IP3 flow as today   │
 └─────────────────────────────────────────┘

What is actually proven (plain language)

When a user authenticates, SABLE generates a single proof asserting all of the following at once:

1. The person in front of the camera right now has the same face as the person originally enrolled
2. The person is a real living human present at the point of capture — not a printed photo, a video replay, or a screen replay of a previously-captured face
3. The proof is cryptographically bound to this specific verification session and cannot be replayed against another session
4. (Optionally, if a Verifiable Credential is presented) the selectively-disclosed credential attributes are validly issued and correspond to the same person who enrolled the biometric

The verifier learns the outcome (pass / fail) plus any attributes the user explicitly chose to disclose. The verifier does not learn the face image, the face embedding, the enrolled template, or any credential attribute the user chose to hide.

The user journey — enrolment

The user enrols once. From the user’s perspective:

1. Open the myID app (SABLE embedded), select “Enrol biometric”
2. Frame face within the on-screen oval; the app guides re-capture if image quality is below threshold (ISO/IEC 29794-5 profile)
3. App captures the face image, extracts a 1024-dimension feature embedding on-device, hashes it with a ZK-friendly hash function (Poseidon), and generates a Pedersen commitment to the hash
4. App stores the cryptographic blinding factor (the “private side” of the commitment) in the device secure enclave / Android Keystore
5. App publishes the public Pedersen commitment as the user’s “biometric public key”
6. Original image and embedding are discarded; only the secure-enclave blinding factor and the public commitment remain

Total time: ~30 seconds. Nothing leaves the device except the public commitment.

The user journey — authentication

When the user later authenticates to a service:

1. Open the myID app, select “Verify identity for [service]”
2. App receives a verification challenge from the verifier (random session nonce)
3. App generates its own random nonce, commits to it (commit-reveal protocol), sends commitment to verifier
4. Verifier reveals its session nonce; combined HKDF derives a deterministic but unpredictable spatial-flash pattern
5. App displays 3 rounds of split-screen colour flashes (top vs bottom colour, ~2.5 s each); camera captures the user’s face under each flash
6. App detects 3D geometry by comparing how upper vs lower face regions reflect each flash colour; a real 3D face responds differently to the split pattern, a flat photo or screen replay responds uniformly
7. App recaptures a fresh face embedding, generates a Halo2 zero-knowledge proof in ~250 ms that simultaneously asserts all four claims above
8. App sends the ~2 KB proof + nonce + (optional) selectively-disclosed credential predicates to the verifier
9. Verifier checks the proof in ~1.8 ms, validates the nonce binding, learns only the pass/fail outcome + disclosed attributes

Total user-perceived time: ~10 seconds (3 spatial-flash rounds + proof generation + network round-trip). The full flow runs on-device; the only network traffic is the challenge / response and the final proof.

Selective disclosure example

If the user holds a Verifiable Credential (BBS+) issued by, say, the Australian Passport Office, the user controls exactly what the verifier learns:

The same Halo2 proof binds the biometric match and the credential predicate, so the verifier knows the predicates relate to the same person who is currently authenticating, not somebody else’s credential.

What is in scope of SABLE / what is in scope of integration

In scope of the SABLE library (Anuna’s open-source offering, what the ATO would consume):

• Capture pipeline (camera access, image-quality control, frame validation)
• Spatial-flash liveness protocol (challenge generation, flash display, reflectance analysis)
• Cryptographic primitives (Halo2 proving system, Pedersen commitments, Poseidon hash, BLS12-381 curve operations, BBS+ selective-disclosure layer)
• ZK proof generation (on-device)
• ZK proof verification (server-side)
• Cross-platform bindings (Android JNI, iOS Swift; MAUI bindings to be delivered per IN-1)
• Web build via WASM for browser-based verification

In scope of the proposed SABLE Verification SaaS (Anuna’s commercial wrapper):

• Hosted verification endpoint on AWS Sydney (ap-southeast-2)
• AWS PrivateLink endpoint for ATO connectivity
• Operational telemetry, audit logging, metrics dashboards (Amazon CloudWatch + Grafana)
• IRAP / PROTECTED-level certification (to be undertaken per SC-1 / SC-6)
• 24×7 monitoring, tiered support, SLA management
• Release management, dependency patching, CVE response

In scope of integration work (joint Anuna + ATO during procurement):

• Embedding SABLE in the myID app build (engineering integration)
• Wiring the SaaS endpoint to ATO’s existing FVS / DVS infrastructure
• Joint UAT, runbook handover, operational onboarding
• ATO branding of capture UI, copy localisation, accessibility-mode customisation

Out of scope (ATO retains):

• The myID app itself and the broader IP3 identity-proofing flow
• The Document Verification Service (DVS) and Face Verification Service (FVS) integrations to source agencies
• User account management, session handling, downstream service authentication
• Helpdesk for end-user identity queries unrelated to biometric verification

The trust model

This is the structural inversion of conventional biometric verification: in the standard model, the user trusts the verifier with their biometric data and trusts the verifier’s data-handling practices; in SABLE, the verifier trusts the cryptographic system and cannot be entrusted with biometric data because there is none to entrust.

Technical building blocks

All primitives are peer-reviewed, transparent (no trusted setup), and either NIST/IETF-standardised or aligned with NIST PQC and IETF CFRG positions. Implementations are pure-Rust (no FFI dependencies on untrusted third-party crypto libraries) and audited via the public test suite (519 tests, 89 % coverage).

What SABLE proposes for myID:

A two-component deployment:

1. On-device — SABLE library embedded in the myID app handles biometric capture, image-quality control (ISO/IEC 29794-5), presentation-attack detection (single-continuous-pipeline spatial flash liveness), and Halo2 ZK proof generation. Biometric data never leaves the device.
2. SaaS — A hosted verification endpoint on AWS Sydney (ap-southeast-2) verifies the ZK proof in ~1.8 ms; integrates via AWS PrivateLink to the ATO’s existing infrastructure; provides metrics, logging, alerting, and ongoing platform maintenance.

The technical compliance matrix for every requirement (LV-1..6, TV-1..3, S-1..2, P-1..2, A-1, H-1..2, IN-1..5, SC-1..8, OP-1..10, VISM-1..7, M-1, RM-1..4, UX-1..4) is set out in Part 3a — Response Form (Technical) and accompanies this submission.

Respondent’s responses in relation to Part 2 — Statement of Requirements

(See Part 3a — Response Form (Technical) — the technical-compliance matrix is provided in the requested XLSX form, with one row per requirement.)

For the cross-cutting business requirements:

• Secure — Halo2 ZK proofs provide cryptographic guarantees stronger than statistical match-rate thresholds. Spatial-flash PAD defeats common photo / video / screen-replay attacks; FMR/FNMR benchmarking against ISO/IEC TS 19795-9 committed.
• User-friendly — ~10-second capture flow; no special device; no internet dependency for capture; biometric data never leaves device.
• Device-compatible — iOS 14+, Android 9+; Chrome, Safari, Edge, Firefox on desktop and mobile via the WASM build.
• Accessible — WCAG 2.1 AA commitment (audit + remediation in 4-6 weeks); accessibility-mode liveness alternative on roadmap.
• 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, and ongoing operations.
• Compliant — privacy by construction directly aligns with Digital ID Act 2024 data-minimisation; ISM / Essential 8 / Australian Privacy Principles roadmap mapped requirement-by-requirement in Part 3a.
• Integratable and maintainable — MAUI bindings sized at 4-6 weeks; IaC deployment; public SBOM; documented patching SLA.
• Value for money — privacy-by-construction architecture removes the ongoing cost of breach mitigation, data-sovereignty auditing, and consent management that statistical-match biometric stacks accrue. Additional public value: SABLE is Apache 2.0 open-source — any work the ATO funds to mature it (third-party PAD certification, FMR/FNMR benchmarking, MAUI bindings, IRAP/PROTECTED assessment, ASD-HACE-compliant crypto pathway, WCAG 2.1 AA audit) becomes immediately freely available to any other government adopter. Candidate future deployment contexts include Anuna’s existing BARMM (Philippines) engagement as a natural extension, early-dialogue with Germany’s BSI for European public-sector identity, other Pacific / Southeast Asian governments, and adjacent use cases beyond national digital identity (age verification, healthcare patient verification, building access). ATO investment compounds across this surface at zero marginal cost — aligned with the Commonwealth’s Pacific Step-Up, Indo-Pacific Endeavour, ASEAN digital cooperation, and the Quad’s cyber resilience agenda.

Section 4 — Respondent’s Declaration

On Anuna Research Cooperative letterhead, signed by Hugo O’Connor as authorised representative.

I, Hugo O’Connor, in my capacity as authorised representative of Anuna Research Cooperative (Trust Engineering), declare on behalf of Anuna Research Cooperative that:

1. The information contained in this Response is, to the best of our knowledge and belief, true, accurate, and complete.
2. We have read, understand, and accept the Conditions for Participation set out in Part 1 of RFI-15434.
3. We acknowledge that this Response is not a binding offer and that no contract is formed by submission or evaluation of this Response.
4. We have no actual or perceived conflict of interest in relation to this RFI.
5. We will comply with the Commonwealth Supplier Code of Conduct in any future contractual relationship with the ATO.
6. We consent to the ATO’s use of the information in this Response for the purposes stated in Part 1, including disclosure to ATO staff, advisers, and other Commonwealth agencies where required.
7. We acknowledge the confidentiality regime described in Part 1 and have separately identified any Confidential Information.

Signed: ____________________________ Hugo O’Connor — Trust Engineering, Anuna Research Cooperative Date: 4 June 2026

End of Part 3 draft.