With the upcoming Privacy Amendment Bill in Australia set for 2026, your OpenID Connect implementation will need more than just a code review. It requires a documented compliance posture.
The OpenID Foundation's Australian Digital Trust Community Group has highlighted a practical issue: modern identity protocols weren't designed with privacy legislation in mind. OAuth 2.0 and OpenID Connect rely on consent screens and token exchanges, while privacy laws focus on data controller definitions and consent requirements. Where these systems intersect, clarity is essential before an auditor comes knocking.
This checklist outlines the technical and operational requirements for running OpenID Connect and OAuth 2.0 implementations under privacy frameworks similar to the Australian model. If you're managing identity services, issuing credentials, or verifying claims in a regulated environment, these are the questions your compliance team will need to address.
Prerequisites
Before diving into this checklist, ensure:
- You operate as an identity provider, credential issuer, verifier, or broker under a trust framework.
- Your implementation uses OAuth 2.0, OpenID Connect, or both.
- You handle personal data subject to privacy regulation.
- You have access to your protocol configuration, consent flows, and data processing agreements.
Compliance Checklist
1. Identify the data controller for each transaction involving multiple organizations
In federated flows, data moves between your authorization server, the client application, and possibly a credential issuer or verifier. Privacy law requires you to pinpoint who controls that data at each stage. Map every flow where data crosses organizational boundaries and document which entity makes processing decisions. Include this mapping in your data processing agreements.
2. Ensure your consent screens meet both OAuth 2.0 and privacy law requirements
Your OAuth consent screen must clearly present scope requests for token issuance. Privacy law demands informed consent with specific purpose statements. Review every consent screen against both the OAuth 2.0 specification and your jurisdiction's consent requirements. Test that users can understand what they're authorizing and what data will be shared.
3. Use per-relying-party identifiers to prevent cross-organization correlation
If your implementation issues the same identifier to multiple relying parties, it creates a correlation risk. Ensure you're using pairwise subject identifiers, not public ones, unless justified. Test that different clients cannot match records using the subject claim alone.
4. Document data retention and processing rules for biometric checks
If you verify identity using biometric data, privacy law treats that data as sensitive. Even if the biometric check occurs on the user's device, document how the verification result is communicated and what data is retained. Map where biometric data is processed and how long you keep verification logs.
5. Implement selective disclosure for credential presentations
Privacy frameworks emphasize data minimization. If you issue or accept verifiable credentials, ensure selective disclosure. Users should share only the claims required for a specific transaction. Review your credential format and presentation protocol to confirm users can choose which claims to disclose.
6. Clarify liability for scheme fees paid through third parties
If your trust framework involves payment processors or intermediaries handling scheme fees, document who is responsible for that transaction data. Identify whether the payment processor is a data controller or processor, and confirm your agreements cover cross-border transfers if applicable.
7. Configure fraud signal exchange using the OpenID Shared Signals Framework
If you participate in fraud detection across organizational boundaries, document what signals you send, receive, and how you use them. Ensure these signals don't include unnecessary personal data and are transmitted securely.
8. Map your implementation's interaction with the Digital ID Act 2024
If you operate under a national digital identity framework, document how your OpenID implementation aligns with its requirements. Identify any conflicts between the privacy bill and the digital identity act, and prepare explanations for resolving them.
Common Mistakes
Assuming OAuth consent equals privacy law consent. OAuth consent authorizes token issuance, while privacy consent authorizes data processing. Document both separately.
Using public subject identifiers for convenience. Public sub claims make debugging easier but create correlation risk. The convenience isn't worth the compliance exposure.
Treating biometric verification as a black box. If you can't explain where biometric data is processed and what's retained, you can't demonstrate compliance. Document it now.
Skipping conformance testing. Use the OpenID Foundation's free, open-source tests for security, privacy, interoperability, and scale. If you haven't run these tests, you're guessing about compliance.
Next Steps
Run your implementation through the OpenID Foundation's conformance tests. These tests are free, open-source, and designed to verify security, privacy, and interoperability properties. If you're planning to operate under an accreditation scheme, consider the Foundation's self-certification program.
Review your data processing agreements with every party in your identity flows. Confirm they address the specific technical patterns in OAuth and OpenID Connect, not just generic data processing language.
Schedule a technical review with your privacy officer. Bring protocol diagrams, consent screen mockups, and data flow maps. Walk through each checklist item with someone who understands both the legal requirements and the technical implementation.
Privacy law is catching up to federated identity protocols. The gap between "technically correct OAuth" and "compliant identity service" is wider than most teams expect. Close it before your next audit.
