Skip to content

USI Registry — External API Reference

1. Purpose and rule compliance

The EXT-API RULE requires a reference doc in docs/ops/ before any external API deploys. This doc covers the USI Registry System operated by the Office of the Student Identifiers Registrar (OSIR). rpl-01-model §4 names this doc as owed before rpl-02-spec touches the registry; the intake-pipeline model carries no registry dependency at launch (capture + format-validation only) and this doc is what the day-two verification build binds behind.

Two-layer honesty: the public documentation carries the architecture-shaping layer (access model, authentication, org checks, versioning); the operation-level contracts live in the request-gated USI Developer Kit. This v1 states what is publicly established and marks the rest [KIT-PENDING]. Nothing below the [KIT-PENDING] line is guessed.

  • The USI exists under the Student Identifiers Act 2014. It is an exclusive 10-character identifier (letters and numbers) linking a student's USI account to their training records.
  • Canon already binds its handling (rpl-01 §4; intake-pipeline §4): student_identifier carries the Act's meaning — a verified, specially-handled identifier, never free text, never in a URL, never in an outbound message body.
  • Collection from students carries a privacy-notice obligation — the Registrar's user guide requires a declaration that the student was given a privacy notice, and publishes a suggested notice. Design consequence for the intake pipeline: the USI capture step on the candidate surface must present the privacy notice; this rides the pipeline's existing consent machinery (intake-pipeline §5). [Exact notice wording per current OSIR guidance at spec time.]
  • Access to registry functions is organisation-typed: the registry checks the Org code is of the correct organisation type (RTO, VET-related body, Higher Education Provider, Tertiary Admission Centre) for the functions called. RTOpacks' clients are RTOs; the functions available are the RTO set.

3. Access model — how anyone connects

Two channels, per the Registrar:

  1. Organisation Portal — human web access, myID (Digital ID) + RAM. Suited to small volumes. Not RTOpacks' surface; noted because client RTOs may hold portal access independently of anything we build.
  2. Web Services (SMS integration) — system-to-system, Machine-to-Machine (M2M) authentication. This is the integration surface this doc exists for.

Prerequisite on the RTO side (all channels): the organisation must be registered on Training.gov.au (TGA), ABN matching registration details, and must have completed a System Access Request with the Registrar. Design consequence: a client RTO's registry access is not something RTOpacks can assume — onboarding captures whether it exists.

4. The credential architecture — CAA, ruled as our path

The load-bearing architectural fact. Two ways a cloud product can authenticate:

  • Per-client M2M: each RTO instals and manages its own machine credential on its own infrastructure. Wrong shape for a cloud platform.
  • Cloud Software Authentication and Authorisation (CAA): the ATO-operated solution for cloud software providers. The host service provider (RTOpacks) uses its own M2M credential to authenticate every connection; the client RTO obtains no credential at all — instead, an authorised business associate of the RTO notifies the ATO (via Access Manager, using their myID/RAM standing, or by phone) that they use our hosted service, quoting our Software ID. On every transmission the ATO verifies the DSP↔business authorisation exists and the Software ID matches.

Ruling for RTOpacks (architecture, to be confirmed in rpl-02): the CAA path. One M2M credential, ours, held under United Central Colleges of Australia Pty Ltd (ABN 59 168 872 535); per-client onboarding includes the client's one-time ATO notification quoting our Software ID. This matches the platform shape exactly and eliminates per-client credential plumbing.

Constraints the CAA path imports:

  • ATO Operational Security Framework (OSF): minimum cyber-security requirements a DSP must meet to access ATO digital services (questionnaire-based; includes requirements such as MFA). This is a real compliance gate before production onboarding — the substrate story (Cloudflare-native, credential isolation, access tiers) must be written up against the OSF questionnaire before CAA onboarding begins, not during. [OSF requirement detail and how it grades for our risk profile: resolve at v2 / onboarding.]
  • Machine credential lifecycle: credentials expire 2 years from creation. Design fork: integrate the renewal function via the machine authentication service certificate manager (MAS CM), or renew manually in RAM before expiry. For a single our-side credential (CAA), manual renewal with a calendar-anchored watch item is defensible at first; MAS CM integration is the durable answer. Decide at rpl-02.
  • Credential custody: the Machine Credential Administrator and the organisation are jointly responsible for storage and use of the credential; failure results in cancellation. Per house credential policy, the credential is Tim-side; it never enters Claude's or Alex's hands, and its storage posture is a credential-isolation item.

5. The two-kit access chain (documentation + test access)

Strict order, per the Registrar:

  1. DPO Authentication Kit (ATO Digital Partnership Office) — obtained first. It authenticates and connects the organisation and its authorised individuals with the ABN and Org code in RAM. Prerequisites: myID at Standard identity strength, the myID app on a mobile device, access to ATO Online services for DSPs and RAM. Enquiries: dpo@ato.gov.au. Terms and conditions must be accepted before the USI kit can be requested.
  2. USI Developer Kit (OSIR) — requested by form only after (1). Contains: the Technical Services Contract (TSC) for the USI Web Service (v5.0, effective July 2022 — confirm current at receipt), WSDLs/interface specs, M2M authentication and org codes for the third-party test (3PT) environment, and generic test data (including mock DVS data for creating test accounts). Updates to an already-issued kit go via IT@usi.gov.au.

Status ledger (update in place): - [ ] myID (Standard) + RAM claim of the Pty Ltd — Tim (may already exist via ATO dealings; check before creating) - [ ] DPO Authentication Kit — Tim, via dpo@ato.gov.au / Online services for DSPs - [ ] USI Developer Kit — Tim, form on usi.gov.au (gated on the above) - [ ] v2 pass of this doc on kit receipt — Claude

6. Operations catalogue (public-source level)

From the Registrar's published user guide for training organisations. Exact request/response contracts, error codes, and the full operation list are TSC material — [KIT-PENDING]. Publicly established operations:

Operation What it does Relevance to us
Verify USI Confirms a supplied USI matches the student's identity details The day-two rpl-01 §4 verification; the reason this doc exists
Find USI Locates an existing USI from identity details Candidate-assist path; consent/authority conditions [KIT-PENDING]
Create USI (on a student's behalf) Org creates a USI with the student's permission and evidence of identity; DVS-checked Ruled (Tim, 2026-07-07): committed capability, two stages. Launch: the intake surface's no-USI path is guided self-create (candidate creates their own USI at usi.gov.au and returns on the same resumable token — no registry call). Day-two, sequenced after Verify: org create-on-behalf for candidates who cannot self-serve — a registry write carrying DVS identity evidence, a recorded permission, and the privacy-notice declaration, all riding the intake pipeline's §5 consent machinery. OSF answers and identity-document retention posture must be settled before this operation enables [KIT-PENDING]
DVS Override / DVS Results Handling for students without standard proof-of-identity documents Edge-path awareness only
Transcript services Authenticated VET transcript access The credit-transfer authentication path rpl-00 1.7-2 names (CT is day-two; rpl-01 §11)
Bulk upload / bulk verify High-volume channels the registry provides to SMS integrations Sizing question for rpl-02 [KIT-PENDING]

Launch boundary, restated: RTOpacks at launch captures and format-validates the USI (10 chars, alphanumeric; the published check-character validation to be pinned at v2 — format rules are in the TSC). No registry call exists in any launch path. Everything in this table is day-two, behind this doc's v2.

7. Environments and versioning

  • 3PT (third-party test) environment: access via the Developer Kit's test M2M credential and org codes. Production URLs are enumerated in TSC §4.2.2 [KIT-PENDING].
  • Web service versioning: MM.NN scheme, published policy. Minor versions are non-breaking and only the latest minor within a major is supported; major versions are breaking, with a minimum 12-month migration window before retirement. Version 3 is decommissioned; v4+ is the floor, TSC v5.0 is the current contract version publicly named — pin the exact current version at kit receipt.
  • Design consequence: the integration worker carries the target major version as configuration, and the 12-month migration window becomes a calendar-anchored watch item the day we go live against any version.

8. What this doc tells rpl-02-spec (the constraints, gathered)

  1. CAA is the credential architecture: one our-side M2M, Software ID in per-client onboarding, client's one-time ATO notification as an onboarding step with UX.
  2. The OSF questionnaire is a pre-production compliance gate — schedule it before CAA onboarding, answered from the substrate story.
  3. Credential expiry (2 years) needs an owner: calendar watch item at minimum, MAS CM integration as the durable design — rpl-02 decides.
  4. Client-side prerequisites (TGA registration, System Access Request, RAM standing) are onboarding facts to capture per client, never assumed.
  5. USI capture on the candidate surface carries the privacy-notice declaration — rides the intake pipeline's consent machinery.
  6. Verification, find, create, transcripts are all day-two operations behind this doc's v2; the launch surface is capture + format-validation only — plus the guided self-create no-USI path (no registry call; the resumable intake token is the mechanism). Small-RTO persona ruling: the platform never strands a candidate without a USI, and never assumes the RTO has an SMS to handle it.
  7. Server-side only, per canon: no registry call ever originates from a candidate-facing surface; the USI never appears in URLs or message bodies.

v1 from public sources, read 2026-07-07. The [KIT-PENDING] markers are the v2 worklist; the kit chain (DPO → USI) is Tim-side and in flight. Filed to satisfy the EXT-API RULE ahead of rpl-02-spec, per rpl-01-model §4.