The Digital ID Act 2024 and the Australian Government Digital ID System: Private-Sector Onboarding

Most firms treat identity verification as something they must build and own. As the Australian Government Digital ID System opens to the private sector, that assumption is about to cost them money they do not need to spend.

The Digital ID Act 2024 received Royal Assent on 30 May 2024 and commenced on 1 December 2024. It put a permanent legislative framework under what had been a voluntary scheme, appointed the ACCC as the Digital ID Regulator, and gave the Information Commissioner an expanded privacy role. For a technology function, the point of interest is not the Act’s structure. It is a single design question that the Act finally makes answerable: can you stop building bespoke identity proofing and instead consume an assured identity that someone else has already verified to a government-backed standard?

What actually changes for a firm that consumes identity

The Australian Government Digital ID System — AGDIS — is being expanded in phases. Government-to-citizen use came first. Participation opens to the private sector from December 2026, subject to the rules made under the Act. That date is the one to design against, because it changes what a relying party can architect for.

Today, a regulated firm onboarding a customer typically runs its own stack: document capture, a liveness or biometric check, a data-source match, a fraud model, and a manual review queue for the exceptions. Every one of those components is something you procure, integrate, monitor, and answer for when it fails. The AGDIS proposition is that a customer who already holds an accredited Digital ID can present it, and you consume the resulting assertion rather than re-running the proofing yourself. You stop being the party that establishes the identity and become the party that relies on an established one.

That is a materially different cost and risk position. The bespoke stack does not just cost licence fees; it costs the engineering time to keep it current, the fraud losses when it is wrong, and the supervisory exposure when a data source or a vendor model behaves in a way you cannot fully explain.

Accreditation and AGDIS participation are two different gates

This is the distinction most early readings blur, and it drives the architecture. The Act separates accreditation from participation in AGDIS, and the ACCC maintains a public register for each.

Accreditation is a quality mark for identity providers. The scheme accredits three roles: identity service providers, which establish and manage the Digital ID; attribute service providers, which verify additional attributes such as a qualification or a company directorship; and identity exchange providers, which broker the flow between providers and relying parties without the relying party seeing the underlying documents. An entity can be accredited without being connected to AGDIS at all.

AGDIS participation is the separate right to operate inside the government system — as a provider, or as a relying party consuming identities from it. When you plan to consume assured identities, you are planning to join AGDIS as a relying party, and the accredited provider on the other side has cleared the accreditation gate. Keep the two straight when you scope the work, because the obligations, the onboarding process, and the register you appear on are not the same.

Design for the assurance level, not the document

The value of consuming an assured identity is that you receive a graded statement of how strongly the identity was proofed, rather than raw documents you then have to assess. The framework describes proofing at ascending levels — broadly a basic tier, a standard tier requiring at least two verified identity documents, and a strong tier that additionally binds the person to those documents. Confirm the exact level names and requirements against the current AGDIS data standards before you build, because they are set by rules that can be amended, and amendments were made through late 2025.

The engineering consequence is that your onboarding policy should be expressed as a required assurance level per product, not as a list of documents. A high-value account might demand the strong tier; a low-risk service might accept the standard tier. Your integration then reduces to a single test: did the assertion come back at or above the level this product requires? That is a far cleaner control to operate, and to evidence to a supervisor, than a pile of document-verification logs.

The integration is an OpenID Connect flow

The AGDIS data standards build on OpenID Connect, so consuming an assured identity is an authorisation-code flow with the assurance level carried as a claim. The relying party redirects the user to the exchange, receives an authorisation code, exchanges it for tokens, validates the ID token, and reads the proofing level before deciding what the customer may do. The pattern below is the shape of that integration; treat the specific claim and endpoint names as placeholders to confirm against the published standards.

# Consume an accredited Digital ID assertion via OpenID Connect (authorisation-code + PKCE)
# Pseudocode using an Authlib-style client. Confirm endpoint and claim names
# against the current AGDIS data standards before relying on this.

from authlib.integrations.requests_client import OAuth2Session

client = OAuth2Session(
    client_id=CLIENT_ID,
    client_secret=CLIENT_SECRET,
    redirect_uri="https://app.example.com.au/callback",
    scope="openid profile",
    code_challenge_method="S256",   # PKCE is mandatory; never omit it
)

# 1. Send the customer to the identity exchange. acr_values asks the exchange
#    to proof to at least our required assurance level for this product.
auth_url, state = client.create_authorization_url(
    AUTHORISATION_ENDPOINT,
    acr_values="urn:id.gov.au:tdif:acr:ip3",  # placeholder: strong tier
)

# 2. On return, swap the code for tokens (PKCE verifier sent automatically).
tokens = client.fetch_token(TOKEN_ENDPOINT, authorisation_response=CALLBACK_URL)

# 3. Validate the ID token signature, issuer, audience and expiry against the
#    exchange's published JWKS. Reject anything that does not verify.
claims = verify_id_token(tokens["id_token"], jwks=EXCHANGE_JWKS,
                         issuer=EXPECTED_ISSUER, audience=CLIENT_ID)

# 4. Enforce the assurance level as a control. Do NOT trust the flow completing;
#    trust only a proofing level at or above what this product requires.
if claims.get("acr") not in ACCEPTED_ACR_FOR_PRODUCT:
    raise OnboardingRejected("Assurance level below policy for this product")

# 5. Persist the assurance level and the assertion reference for the audit trail,
#    not the underlying identity documents you never received.
record_onboarding(subject=claims["sub"], acr=claims["acr"],
                  verified_at=claims["auth_time"])

What you still own after you outsource the proofing

Consuming an assured identity removes the proofing burden. It does not remove your own obligations, and this is where firms will get it wrong. Three things stay firmly yours.

Your regulatory obligations do not transfer. If you are subject to AML/CTF customer due diligence, the Digital ID gives you a strong, standardised input, but the accountability for satisfying your obligation remains with you. Map the assurance level you accept to the diligence standard you must meet, and document that mapping, because a supervisor will ask why a given level was sufficient for a given product.

You still hold and secure whatever you retain. You will not receive the customer’s documents, which is the point, but you will hold the assertion reference and any attributes you requested. That data attracts the same security expectations as anything else, and Australian regulators have made clear that reasonable security steps are now actively enforced — a theme covered in the OAIC’s sharper enforcement posture. Consuming identity is not a reason to be careless with what comes back.

You still owe a fallback and a transparent decision. Not every customer will hold an accredited Digital ID, so an onboarding path that assumes one is a design failure; keep the bespoke route alive for the exceptions and route only what qualifies through AGDIS. And where the assurance level feeds an automated accept-or-reject, that is an automated decision your customer can question — the transparency expectations set out in Australia’s Privacy Act reform apply to it. If you route onboarding through a hosted identity flow, the accessibility of that journey also remains your responsibility, in the same way the European Accessibility Act makes the digital journey the obligation of the firm offering the service, not the vendor behind it.

The decision to make before December 2026

The honest question is not whether AGDIS is technically elegant. It is whether the bespoke verification stack you maintain is genuinely cheaper and stronger than a government-backed, standardised assurance you could consume instead. For most firms it is not — it is a legacy of a time when there was no alternative to build against. That time is ending. Model the cost of your current stack against the cost of an OpenID Connect integration and a fallback path, decide which products can accept which assurance level, and be ready to join as a relying party when the system opens. The firms that treat this as a procurement afterthought will still be paying to rebuild what the state now offers to verify for them.