Security & data handling at openfeed

openfeed is built by the team that operates production CDR infrastructure — security is foundational, not bolted on. This is the platform posture your app inherits when you build on openfeed.

openfeed in the Consumer Data Right ecosystem

openfeed is a software product operated by Biza Pty Ltd, an Accredited Data Recipient under Australia’s Consumer Data Right. openfeed is registered on the CDR Register maintained by the Australian Competition and Consumer Commission (ACCC), and has completed the Conformance Test Suite for data recipients.

When you build on openfeed, you’re building on top of a validated CDR Software Product inside the CDR ecosystem, you don’t need to become an ADR yourself.

What openfeed handles for you

The CDR ecosystem is many-sided and evolving. openfeed absorbs that complexity so your app can stay focused on your product:

• 100+ data holder connections: Every bank and energy retailer implements the CDR against their own systems, with their own access, endpoint quirks, and edge cases. openfeed maintains those connections continuously so you code against one interface. Users encountering issues with their providers can resolve them via openfeed and have all the downstream apps reap the benefits.
• CDR mandated requirements: Mutual TLS, dynamic client registration against the CDR Register, participant PKI issuance and rotation, and per-holder discovery — all handled centrally by openfeed.
• Data normalisation: Each holder implements the CDR Data Standards with subtle differences. openfeed normalises accounts, transactions, meters, usage, and DER into a consistent shape you can code against once — the same call works across every holder and openfeed continuously improves how it maps data on a per-holder basis.
• Availability and resilience: openfeed tracks holder health, retries with backoff when specific holders are degraded, and monitors published rectification schedules so your app isn’t caught out by known issues upstream. We will publish individual data holders we identify as having ongoing data quality issues.
• Standards evolution: The CDR Data Standards change over time. openfeed tracks the versions and adapts ingestion so your integration doesn’t churn every release.

Data flow at a glance

CDR Consumers authorise their Data Holder, their bank or energy retailer, to share data with openfeed under the Consumer Data Right. When a consumer chooses to share with your app, openfeed brokers an onward disclosure grant and your app fetches the shared data over a FAPI 2.0 hardened API. Your app never touches raw CDR credentials or upstream data holder connections.

Security in Depth

The openfeed Sharing API is FAPI 2.0 compliant, the highest standard of security profile published by the OpenID Foundation, purpose-built for financial-grade data sharing. Your app inherits that bar simply by authenticating against openfeed.

The Quickstart covers the configuration but for those interested in the deeper complex parts this section is for you.

Token handling in the platform

The openfeed Sharing API is a FAPI 2.0 resource server. The platform issues sender-constrained tokens through a hardened authorisation flow and enforces grant state live on every request. New client registrations default to the Recommended profile (private_key_jwt + DPoP).

Confidential clients

• Confidential-only clients: There are no public clients on openfeed. All profiles require a server-side credential. The resource-owner password grant is rejected outright.
• private_key_jwt client authentication (Recommended): Client-authentication assertions are signed with your app keypair (PS256/RSA) and verified by the auth-server against your published jwks_uri or your staticly uploaded public keyset.

Authorisation request hardening

• Pushed Authorization Requests (PAR), mandatory for all clients: Every authorisation request is pushed server-to-server over an authenticated back channel and exchanged for a single-use request_uri. A plain authorisation redirect without a prior PAR is rejected. Request parameters — including redirect_uri, scopes, PKCE challenge, and grant-management instructions — never traverse the browser, so they cannot be inspected, tampered with, or replayed in transit.
• Short-lived, single-use request_uri: The PAR response carries expires_in: 60. The request_uri is one-time-use at the point of authorisation. This shrinks the window for request-leak CSRF and browser-swapping attacks to seconds.
• PKCE with S256, required: Every authorisation code is bound to a per-request PKCE challenge (code_challenge_method=S256). An intercepted authorisation code is useless without the matching verifier, and the verifier never leaves your server.
• redirect_uri carried inside the authenticated PAR: Redirect URIs are validated at runtime from the authenticated PAR body rather than from a pre-registration list. This closes open-redirect vectors while eliminating the pre-registration foot-gun — the dashboard registration form has no redirect URI field for this reason.
• Authorization code binding to DPoP key: When using the Recommended profile the authorisation code is cryptographically bound to your DPoP key at issuance, so it cannot be exchanged by a different client even if intercepted.
• Issuer identification in the authorisation response: The authorisation response includes an iss parameter (RFC 9207) which clients must verify, preventing mix-up attacks where a malicious authorisation server substitutes its response for a legitimate one.
• Authorization codes are single-use and short-lived: A code that has already been presented to the token endpoint is permanently invalid; a code that is never presented expires within ~60 seconds.

Grant management via authorisation

• Grants are established through the authorisation request itself: Per the OIDF Grant Management for OAuth 2.0 spec, grants are created, queried, and replaced via grant_management_action (and grant_id) in the PAR body — not a mutable side API that can be called independently. See Grant management & lifecycle for the PAR attributes table.
• grant_id claim on every data token: Access tokens carry a grant_id claim identifying the bound disclosure grant. A token without a grant_id cannot call any data endpoint.

Token binding and properties

• DPoP sender-constrained (bound) access tokens (Recommended): Every access token is cryptographically bound to your DPoP keypair (RFC 9449). Tokens are presented under the DPoP scheme — not Bearer — and each API call must include a fresh, single-use DPoP proof signed over the HTTP method and request URL, with an ath claim hashing the exact access token. A token exfiltrated from a log, proxy, or wire capture is useless without your DPoP private key. See the Authorization: DPoP example in the Quickstart.
• Two separate keypairs for two separate jobs: Client-assertion signing uses your app keypair (PS256/RSA); DPoP proof signing uses a distinct DPoP keypair (PS256 is rejected for DPoP). The DPoP private key is never published in your JWKS. Compromising one keypair does not compromise the other.
• Audience-bound tokens: Access tokens are minted for api.openfeed.au implicitly bound at request establishment. A token issued without this audience binding fails validation on every data call. A token issued for another resource cannot be replayed against the sharing API.
• Minimum 128-bit entropy on all credentials: Authorisation codes, access tokens, and refresh tokens are generated with at least 128 bits of entropy, making brute-force guessing computationally infeasible.
• Short access-token lifetimes paired with refresh tokens: Access tokens are short-lived (on the order of an hour). Refresh tokens carry the long-lived session, keeping the blast radius of a leaked access token small. Refresh tokens also let you rotate your sender-constraining DPoP keypair without losing the user’s grant.

Runtime enforcement

• Live grant state resolved on every request: Both consumer consent (grantStatus) and metering state (meteringState) are resolved at the API boundary on every call — there is no cached authorisation. A revoked or suspended grant fails immediately before any data leaves the platform.
• Minimal introspection surface: Introspection responses expose only {active, grant_id} — no authorisation_details, no personal information, no account identifiers. Nothing sensitive is reachable through introspection.

Data pipeline controls

openfeed’s ingestion pipeline applies controls to Consumer Data as it enters and moves through the platform — including but not limited to data masking and redaction of sensitive fields. Sensitive identifiers are neutralised before data reaches sharing-API responses, so your app receives fields fit for storage and use.

Consent & grant safety

• openfeed manages the consumer’s consents end-to-end. Grants are the durable, revisioned handle for each share; consent events are recorded against each grant.
• Revocation is live: When a consumer revokes a grant, subsequent data calls return 403 disclosure_grant_required immediately — no cached authorisation.
• State is enforced per request: Both consumer consent (grantStatus) and metering state (meteringState) are resolved live at the API boundary; you can’t accidentally read data on a stale grant.

See Grant management & lifecycle for the developer’s side of the model.

Independent assurance

Beyond the CDR accreditation covered above, Biza Pty Ltd maintains:

• ISO 27001: information security management standard including ISO27017 and ISO27018 extensions.
• SOC 2 Type 2: independent assurance of security, availability, and confidentiality controls.
• ASAE 3150: assurance audits underpinning Biza’s CDR Data Recipient accreditation.

The same infrastructure powers openfeed.

Your side

The platform gives you a secure foundation; your app closes the loop. See Stage 4 of Path to production for openfeed’s expectations of how you handle the data your app receives — token storage, retention, and Privacy Act obligations.