Whether directly involved in Open Banking or not, anyone who makes purchases online or uses financial services like Mint (from Quicken) will be excited about Open Banking. The regulation and the protocol profiles being developed for interactions between financial institutions, online merchants and online financial account aggregations will lead to a more secure solution and give users more control. The existing online buying experience that you are familiar with today, where you give a website your credit card information, is fundamentally flawed.
Open Banking will change this. It will give consumers the ability to explicitly tell their bank whether or not they authorize a purchase, never having to submit the key to their credit account to the merchant. Similarly, for aggregation services like Mint, the user will be able to tell their bank they authorize the service to read their account balance and transaction history. These improvements will give users the control they deserve, and they are completely achievable with today's protocols.
PingFederate Enhanced in Support of Open Banking Standards
PingFederate 8.4 shipped last month and includes features to address Open Banking plus much, much more.
We've added support for the OpenID Connect request parameter to secure data sent in authentication requests. This allows relying parties to transmit data to OpenID Connect providers and protect it against tampering. For Open Banking, this will allow a merchant to send a request to authorize a purchase and the details of that purchase to the bank. The bank will then prompt the user to confirm they want to make the purchase.
JWT Authentication Improves API Security
APIs that support OAuth for scenarios where the user is not directly present but user context is required can leverage the JWT authorization grant added in PingFederate 8.4. This grant type is used in cases where an API call is required but a browser can't be presented to the user, possibly triggered through some sort of automation or scheduled task. This could be an API call to replenish inventory when inventory levels are detected to be too low, a scheduled task to call a SaaS vendor API, or any service that doesn't have a GUI but needs to make an API call. This authorization grant provides a way to submit a JWT and return an access token.
The same RFC (https://tools.ietf.org/html/rfc7523) that defines the JWT authorization grant also defines a way to use a JWT for client authentication. This capability has also been added to PingFederate 8.4. The benefit to JWT client authentication is that it's a form of authentication based on a public and private key pair. The client never needs to share the private key, so it does not have the same risk as client_id and secret, and it doesn't have the certificate infrastructure and validation complexity required for mutual TLS authentication, which is also an option with PingFederate.
Staying Ahead of the Enterprise Scalability Curve
One last thing: we've made significant progress in improving support of PingFederate deployments with thousands of Connections and OAuth Clients. We set a goal of 10 times what our most demanding customers have configured in PingFederate, and we surpassed it. This includes significant administrative UX improvements for searching, paging, filtering and sorting Connections and OAuth Clients. This also includes a new architecture for Connection and OAuth Client storage, retrieval and cluster replication.
To sum it up, at very high numbers of objects what used to be a bit taxing on administrative response times is now negligible. Environments with 10k objects today can grow to 100k objects with very little difference in the administrative experience.
All of this, and much more, wraps up another great PingFederate release. See the release notes for more details.