Open Banking Pilot for a Leading Canadian Bank

• Prove compliance with FAPI 1.0 Advanced and OIDC without re-platforming the bank's AuthHub
• Enable Dynamic Client Registration (DCR) using SSAs and x.509 certificates for TPP onboarding
• Demonstrate interoperability with FDX APIs; explore Rich Authorisation Requests (RAR) readiness
• Stand up multiple AWS environments (Dev, SIT, UAT, Prod) quickly and repeatably
• Handle multi-brand routing and brand-specific consent experiences
• Operate within evolving/ambiguous FDX guidance vs. prescriptive UK/Brazil models

We implemented a brand-aware routing model: the left-most FQDN segment encodes brand (e.g., https://{brand}.{bank}.example/pf/...) and maps to a brand-scoped authorisation server instance and consent flow. Dev, PoC, and higher environments used consistent patterns to ensure parity and ease of testing.

• Brand scoping: distinct PingFederate adapter instances and consent resume paths per brand
• Repeatability: infrastructure and configuration automated to reproduce across Dev→UAT→Prod
• Separation of concerns: commissioning/trust material isolated from brand orgs (see "Trust & Onboarding")

The Trust Platform (Raidiam Connect) handled software statement issuance and certificate lifecycle. TPPs onboarded via DCR using their software statements and transport/signing certificates. This delivered a provable, auditable onboarding process.

• Self-service onboarding: TPPs used SSAs + certs to register via DCR endpoints exposed by the federation layer
• Interoperability: DCR aligned with internationally proven patterns to reduce vendor lock-in
• Governance: roles and claims configured to enforce capability boundaries per TPP and brand

PingFederate acted as the OIDC OP/AS and integrated with the bank's existing AuthHub for PSU login. Consent was externalised using the PingFederate Reference ID Adapter pattern. We wrote a lightweight Golang consent adapter to bridge PingFederate with the consent backend and a JavaScript frontend to exercise the PSU consent flow end-to-end (also used by a demo TPP application).

• OP/AS functions: token issuance, introspection, revocation (RFC 7009), and well-known discovery
• Consent externalisation: PingFederate issues a reference, redirects to consent app; upon completion, PingFederate resumes the flow
• Brand-specific consent: adapter instances and UI themes per brand, routed by FQDN

Ping Federate reference ID Adapter Documentation

Early builds used JWT access tokens; we then moved to opaque tokens for better centralised control. This involved switching PingFederate Access Token Managers, updating DCR service settings, and promoting changes via CI/CD.

• Update PingFederate to use opaque token managers for selected AS instances
• Adjust DCR microservice configuration (Helm/ConfigMap) to register clients against the new token manager
• Rollout sequence: Dev first, validate E2E, then UAT/Prod

# [Example snippet: Kubernetes ConfigMap fragment for DCR settings]
data:
  ACCESS_TOKEN_MANAGER_ID: "opaque_manager"
  ID_TOKEN_MANAGER_ID: "jwt_manager"
  # ...

# [Example snippet: kubectl commands used during pilot]
kubectl -n obp edit configmap dcr-config
kubectl -n obp rollout restart deployment dcr-service

The browser authorization request was packaged as a signed request JWT including PKCE parameters and brand-specific ACRs. The consent service returned the user to PingFederate via a brand-scoped resume endpoint; issued tokens carried the required identifiers.

{
  // [Example snippet: Request JWT header]
  "alg": "PS256",
  "typ": "JWT",
  "kid": "{masked-key-id}"
}
--
{
  // [Example snippet: Request JWT payload]
  "client_id": "{tpp-client-id}",
  "redirect_uri": "https://{tpp}.{example}/cb",
  "scope": "openid accounts consent fdx:read",
  "response_type": "code",
  "code_challenge_method": "S256",
  "code_challenge": "{masked}",
  "acr_values": "urn:ca:ob:brand:{brand}", 
  "state": "{masked}",
  "nonce": "{masked}"
}

# [Example snippet: Brand-aware PingFederate resume path]
https://{brand}.{bank}.example/pf/as/{brand}/resume/as/authorization.ping?REF={masked-ref}

{
  // [Example snippet: ID Token claim shape]
  "iss": "https://{brand}.{bank}.example/pf",
  "aud": "{tpp-client-id}",
  "sub": "{ecif-xref}",
  "azp": "{tpp-client-id}",
  "consent_id": "{masked-consent-id}",
  "channel_id": "{brand}",
  "nonce": "{masked}",
  "auth_time": 1690000000
}

• mTLS at ingress with OCSP/CRL checks for client certificate validity
• Least-privilege scopes aligned to approved capabilities per TPP and brand
• Auditability: consent decisions and token events logged for traceability

• Refactored client-lookup code to avoid iterating over all clients at scale
• Resolved environment-specific quirks (e.g., CDN/cipher alignment in non-Dev tiers)
• Improved trust framework hygiene: split "commissioning org" (critical CA/SSA assets) from brand orgs; locked down permissions to avoid accidental deletion
• Kept a brand-specific "do not delete" convention for trust assets; automated as much as possible via pipelines

We built a lightweight TPP app and a Postman-driven toolkit to prove end-to-end flows (SSA → DCR → PSU login → consent → FDX API call). The app doubled as a demo vehicle for stakeholders and a template for external partners.

• Minimal variables required; discovery endpoints handled automatically
• Private Key JWT and PKCE built-in; reduces setup friction for partners

• OpenID Foundation FAPI profile tests executed against brand-scoped endpoints
• End-to-end UATs covering consent, token issuance, and FDX resource access
• Operational readiness: log/monitoring checks, SOPs for support teams

Opendata Consult led architecture and hands-on engineering, co-hosting workshops with Canadian stakeholders on authentication, authorisation, and consent. We collaborated across identity, security, and API teams to land a multi-brand pilot that mirrored production realities.