Response to Decision Proposal 182: InfoSec Uplift for Write

The Data Standards Body (DSB) has provided Decision Proposal 182 (DP182) without recommendations to assess the uplift of the Information Security Profile that governs the Data Standards and therefore more broadly the CDR.

Within this proposal there is initial discussion around a transition from the underlying FAPI ID2 (Draft 6) profiles to the FAPI 1.0 (Final) profiles and then further questions with regard to the adoption of FAPI 2.0 family of specifications. As a provider of a software-as-a-service solution for Data Holders (“Biza.io Platform” or “Biza.io HaaS”) we have provided initial feedback with respect to the analysis conducted by the DSB as well as regarding protocol support related to our recommendations.

Standards Evolution

Biza.io feels it is important to point out that the FAPI profiles are the result of evolution occurring within the open data and open banking spaces and, therefore, the naming and approach to their definition has evolved in accordance.

Specifically, within the Context part of DP182, various references to Read vs. Write have been made. The reality is that, as demonstrated by the final naming of FAPI 1.0, the definition of a security profile based on whether the operation was of read or write type is unsuitable for the use cases that jurisdictions (including Australia) are now looking to solve.

A simplified example of this is that accessing (“read”) an individual’s identity information is potentially worth far more to a bad actor than potentially any payment that could be initiated (“write”) by that individual. Further, broadly speaking the FAPI 2.0 Baseline profile effectively starts with FAPI 1.0 Advanced as a baseline.

Because of these observations Biza.io is of the opinion that Standards should follow the sequential nature of their publication. In many respects the CDR InfoSec Profile is an aberration that is neither aligned to the historical international standard (FAPI1 ID2), the currently final standard (FAPI1 Final) or the future standard(s) (FAPI2).

Statements of Support

Biza.io supports the statements made within the GitHub thread for DP182 by:

• The Australian Banking Authority
• The OpenID Foundation
• Commonwealth Bank
• Westpac Bank
• Ping Identity

References

The following documents were used and are referenced during preparation of this analysis:

Towards the Consent of Everything

Biza.io believes that the role of Information Security for Data is becoming increasingly intertwined with the associated Consent of that Data. While traditionally it was possible to look at securing data separately from permission to access the data the world, particularly with respect to consumer data, is quickly merging these concepts together.

Historically the DSB has treated many aspects of the consumer consent in isolation of the information security standards underlying it. This has resulted in only limited success with brittle business rules being implemented at presentation layers (collapsing of data clusters, deterministic behaviour between OpenID scopes and CDR scopes etc) and arbitrary parameters (ie. sharing_duration claims) triggering yet more brittle business rules for claim propagation (ie. sharing_expires_at). Added to this technical isolationism has been the introduction of complex rules frameworks, often driven more by political timelines than business-like common-sense combined with a general apathy to technological realisation.

These factors have resulted in an implementation which, while leading in a legislative context, belies the reality of its inflexibility in implementation. From Biza.io’s perspective the window to correct course on this journey is closing, particularly in the context of international organisations developing solutions to solve the same problems.

In essence, Australia had “the jump” technically some two years ago but is, at best only a “nose ahead” now of other jurisdictions.

Defining a Consent Taxonomy

Biza.io believes that the key to achieving suitably defined consent is the definition of a consent taxonomy that can be uniformly defined, expanded upon, and adopted across industries using existing (RAR) technical standards coupled with an appropriate legal framework.

Biza.io’s preference for the format of such a taxonomy would be in the form of a JSON Schema with sufficient documentation to allow for a decision engine to reliably parse both the request and response content. Once such a taxonomy is defined it would become increasingly easier to appropriately define common use cases such as those hypothesised within DP183.

Biza.io has elected to provide examples of such a taxonomy in its response to DP183 to demonstrate how this could be applied. Biza.io provides examples of potential authorization_details (RAR) with a type of cdr_sharing_arrangement_v2.

It is worth noting that Biza.io already manages CDR Arrangements using a RAR type of crd_sharing_arrangement_v1. That is to say, Biza.io has already defined a consent taxonomy within its own product and effectively bridged the brittle Data Standards approach into it.

Suffice to say that Biza.io’s HaaS environment already supports Rich Authorisation Requests making the potential transition impacts negligible for our customer base.

Tracking Consent State

In addition to the need to be able to uniformly define consent in a machine processable way, Biza.io also believes that the consumer experience will not be complete until it is possible for counterparties (ie. Data Recipients etc) to discover details about existing arrangements.

To solve for this problem Biza.io personnel have developed in collaboration with other FAPI Working Group members the emerging Grant Management for OAuth 2.0 (GM-API) specification. GM-API describes a way, via an OAuth2 extension, of inspecting arrangements (“grants”), both current and expired using their unique identifier, rather than cycling through bound refresh tokens. This allows for a Data Recipient to dynamically receive state changes including extensions to sharing, additions/removals of permissions or basically any other suitably described parameter within the initial RAR response.

As part of this authorship participation and in part due to a parallel build of our HaaS platform, Biza.io already manages arrangements internally using this mechanism and as a consequence can commit to support for this specification immediately.

Ensuring Multi-Device and Holder Trusted App Support

Biza.io believes a critical component of continuing enhancement of trust within the CDR ecosystem is the integration of secondary factors into existing, trusted, digital experiences Holders already provide. A simplified example of this is the use of a push notification for approval of sharing, payment or otherwise via a customers existing internet banking experience. Such a pattern is quite familiar to users, particularly with the rapid adoption of authenticator applications such as those within the Microsoft Office 365 environment.

Because of this believe, Biza.io supports the adoption of the OpenID Connect Client-Initiated Backchannel Authentication Flow (CIBA) into the Data Standards. While Biza.io does not currently support CIBA within its technology stack it is considered a high priority item on our backlog and, consequently, we expect to achieve such support within the recommended adoption windows of this feedback.

Question Responses

What are the existing gaps or concerns with the information security profile?

As an actively contributing member of the FAPI Working Group and co-author of the emerging Grant Management API specification, Biza.io and its personnel strongly believe in the value of international standards alignment. Through such alignment an ecosystem can benefit from the lessons learned from other jurisdictions and combine this with a pool of talented specialists who are able to bring together centuries of accumulated experience to consider interoperability problems in the context of security ones.

Consequently, Biza.io’s key concern with the existing information security profile is that it does not currently align with the internationally accepted specification and, due to ambiguity introduced during its authorship, is now difficult to maintain with respect to the evolution of security best practice.

Key gaps that exist within the existing information security profile include:

1. Lack of PKCE support
2. Lack of enforcement of PKCE with PAR
3. Lack of explicit constraints of request object lifespans

Nonetheless, Biza.io wishes to repeat once again, categorically, that we do not support cherry-picking of components of the FAPI profiles and instead strongly recommend complete alignment with the FAPI 1.0 Final specifications as a high priority task.

Finally, Biza.io is uncomfortable with the level of oversight the CDR InfoSec Profile currently has. It is not aware of a formal information security assessment having been conducted on the profile for some years nor is it aware of any published and credentialed involvement of information security experts in the continued development of the profile beyond the volunteer work conducted by parties such as specialists within institutions or solutions providers such as Biza.io.

What gaps or concerns with the information security profile would prevent voluntary extension to write operations by a data holder?

Biza.io does not consider information security in the context of read vs. write as read operations can have just as much, if not higher, impact as write operations. Indeed, such archaic separation is one which is deprecated thinking within working groups but an oversimplification of the problem space.

What we would instead highlight is that voluntary use cases are more likely in an environment with international alignment (along with easier implementation) which the realignment of the CDS to the FAPI 1.0 profile would deliver (particularly the adoption of PKCE).

What aspects of version 1.0 of the FAPI Advanced Security profile, if any, should be prioritised for adoption by the CDR?

Biza.io provides the following high-level summary of prioritisation while incorporating further enhancements within the timeline.

Immediately:

• We do not believe these changes will have any significant impact on the ecosystem at this stage:
  • Mandate Request Object lifespan constraints immediately
  • Mandate PAR request_uri reuse restrictions
  • Mandate multiple brands as separate issuers
• Introduce PKCE support and therefore response_type of code only (without ID Token)

Within 3 months:

• Mandate PAR only Request Object submission

Within 6 months:

• Mandate PKCE+PAR support
• Align PAR adoption to Draft-09
• Introduce optional FAPI CIBA support

Within 9 months:

• Mandate complete alignment to FAPI 1.0 Part 1: Baseline (Final) and FAPI 1.0 Part 2: Advanced (Final) profiles;
• Formally adopt as Optionally supported the FAPI 2.0 specifications :
  • FAPI 2.0: Baseline Security Profile
  • Grant Management for OAuth 2.0
• Deprecate FAPI 1.0 profiles

Within 15 months:

• Mandate complete adoption of FAPI 2.0 profiles;
• Retire FAPI 1.0: Final

What priority should be given to transitioning to FAPI 2.0?

Biza.io believes that the CDR is currently flirting with being “left behind” as other ecosystems are very close to achieving CDR feature equality already. In addition, we believe that the DSB has an opportunity to embrace the FAPI 2.0 family to solve challenges it is already aware of (fine-grained consent, “purpose based” consent, consent status and discovery).While the DSB could develop solutions to these challenges outside of the FAPI 2.0 process, doing so would alienate the international community further and likely lead to already limited vendor adoption being reduced to negligible as vendors instead seek to find larger markets (such as the U.S) which are already moving towards the international standards being developed.

What additional patterns or normative standards should be considered for adoption to reduce the risk of write operations?

Once again, Biza.io believes risks are equal regardless of operation but that the infosec profiles for consent operations are more than security controls and increasingly pathways to complex consumer consent behaviours and aspirations.

Consequently, Biza.io recommends the adoption of the following Standards:

1. Proof Key for Code Exchange (PKCE):
   To ease implementation complexity and enhance security
2. Rich Authorisation Requests (RAR):
   To deliver a platform for fine grained consent
3. Grant Management for OAuth 2.0 (GM-API), of which Biza.io personnel are co- authors:
   To deliver arrangement discovery capability
4. Financial-grade API: Client Initiated Backchannel Authentication Profile:
   To allow for additional authentication mechanisms to achieve higher levels of authority

In addition Biza.io recommends the evaluation of the following Standards:

• OpenID Shared Signals and Events Framework (OID-SSE):
  As a potential framework for signal processing
• OpenID Continuous Access Evaluation Profile (OID-CAEP):
  As a potential profile for state change notifications between parties
• OpenID Connect for Identity Assurance 1.0 (OIDC-IDA):
  As a potential framework for Identity Assurance and/or KYC requirements

What additional changes, if any, that should be considered for maximising international operability?

Despite various assurances by the DSB, there has been a minimal amount of observed engagement between key data standards bodies (notably OpenID Foundation) and the DSB itself. There has been tacit interaction by the ACCC and a number of minor workshops but limited continuing engagement.
While the government may be engaging other government agencies in its endeavours, there continues to be a technical void in engagement with leading international standards bodies.

Biza.io remains disappointed by the DSB’s apparent lack of engagement with these bodies and ultimately sees a missed opportunity for Australia to lead the world in the definition and adoption of complex consent patterns for consumer data sharing.

What steps could be taken by the DSB to assure the efficacy of the information security profile?

Biza.io recommends that the DSB re-baseline the Standards in a format which acts as a derivation of the underlying Standards rather than its current form which ambiguously redefines it. The Data Standards with relation to authorisation and consent should, in Biza.io’s opinion, be a profile of those underlying standards and seek to therefore copy the structure and approach of those standards.

Put more bluntly, the DSB should ditch Slate and adopt markdown2rfc or similar tools to produce IANA aligned Standards documents. Roughly paraphrasing a starting point for such a document:

The authorisation server shall support the provisions specified in clause 5.2.2 of Financial- grade API Security Profile 1.0 – Part 2: Advanced. In addition, the authorisation server
1. shall……
2. shall…..
3. may….

In addition, Biza.io recommends that the DSB focus on conformance tools to ensure both Data Holders and Data Recipients implement solutions which deliver and enforce robust security controls.

Appendix 1: Upstream Standards Analysis

Biza.io thanks the DSB for the analysis conducted between FAPI 1.0 ID2 and FAPI 1.0 Final and PAR Draft-01 and Draft-08. As this analysis appears to make a number of statements regarding what is considered breaking changes, it seems important to provide commentary on these documents, particularly the parts highlighted as a change as they represent potential build impacts to implementers.

FAPI Part 1 (“Baseline”)

Authorisation Code Reuse

Support for OAuth2 Metadata (RFC8414)

Scopes in Token Response

Clients missing openid scope

BCP212 Withdrawal

Content-Type Header Requirement

Resource Server x-fapi-customer-ip-address Behaviour

TLS & DNSSEC Considerations

Multiple Brands as Separate Tenants

FAPI Part 2 (“Advanced”)

ID Token and JARM

Request Object Expirations, Audience and Not Before Claims

PAR with PKCE

JARM Support

PAR Draft-8

Endpoint Auth Method

Request Reuse

Client Redirect URIs

Mandatory PAR Support

About Biza.io

Biza.io are the market leaders in Data Holder solutions to the Consumer Data Right and are the only pure-play CDR vendor in Australia. Founded by the former Engineering Lead of the Data Standards Body (DSB), Biza.io has been involved in the Data Standards setting process since the very beginning and its personnel remain the largest non-government contributors to the consultations. In addition to its participation within the CDR, Biza.io is also a contributing member of the Financial-grade API (FAPI) Working Group, contributors to the FAPI 1.0 information security profile and co-authors of the Grant Management for OAuth 2.0 specification.

About Our Customers

As of July 2021, Biza.io is directly responsible for delivering, or heavily involved in, the verification of one in three of all active Data Holders. Beyond just a contractual engagement Biza.io considers all of its customers partners in the journey toward open data. Our customers choose us to not only achieve compliance but to compete then command the consumer data ecosystem.