Decision Proposal 79 - July Draft Feedback Cycle 1

[Technical-DSB]

This thread has been created to accept feedback on the July 2019 working draft. This thread is for feedback on information security profile and the overall standards, API URIs and payloads.

[deboraelkin2]

In request headers, x-fapi-interaction-id is now listed as mandatory, however its description states:

If provided, the data provider must "play back" this value in the x-fapi-interaction-id response header.

which seems to indicate it is optional. The description of the corresponding response header points to it being optional as well:

The data provider must set the response header x-fapi-interaction-id to the value received from the corresponding fapi client request header or to a new RFC4122 UUID value if the request header was not provided to track the interaction.

Please clarify whether it is mandatory or not.

[deboraelkin2]

Also x-fapi-auth-date and x-fapi-customer-ip-address are mandatory request headers for authenticated calls. They should be included in the specifications of such endpoints (i.e: all except Get Products and Get Product Details)

[perlboy]

Related to my previous comments on consent the latest decisions related to the infosec profile are no longer in line with the initial directions which specifically called out an alignment with international initiatives. As noted by @RalphBragg in October 2018 the "request object" referenced in FAPI RW is one way to tackle the requirement for complex consent. Since that time further development has occurred within the UK with a more structured consent model in progress.

Further the proposed path is similar to the one the UK started with (when there was no standard at all) and now the Australian standard appears to be reinventing the wheel rather than aligning with what is now an international standard managed and maintained by a non-profit standards body (ie. OpenID).

Directly attaching these with the regulatory environment under which ADI's must operate under. Within APRA's Prudential Practice Guide CPG 234 Information Security there are a number of references which are of note.

Information security capability (starting Page 10) outlines a number of expectations are defined:

17. APRA-regulated entities often place reliance on information security capabilities of third
    parties and related parties to provide a targeted information security capability, or as
    part of a wider service-provision arrangement. Accordingly, entities would have a view as
    to the sufficiency of resources, skills and controls of third parties and related parties.
    This could be achieved through a combination of interviews, service reporting, control
    testing, certifications, attestations, referrals and independent assurance assessments.
    Any capability gaps identified would be addressed in a timely manner.

Further it is noted that this is normally the responsibility of the Board:

20. Under CPS 234, an APRA-regulated entity must actively maintain an information security
    capability with respect to changes in vulnerabilities and threats. Accordingly, an entity
    would typically adopt an adaptive and forward-looking approach to maintaining its
    information security capability, including ongoing investment in resources, skills and
    controls. This would commonly be achieved through the execution of an information
    security strategy which responds to the changing environment throughout the year. The
    strategy could be informed by existing and emerging information security vulnerabilities
    and threats, contemporary industry practices, information security incidents, both
    internal and external, and known information security issues. Oversight of execution of
    the strategy is normally the responsibility of the Board or a delegated governing body
    with representation from across the organisation.

In Attachment D, Section 2(d) there is guidance provided on software selection which specifically calls out alignment to industry standards (JARM adoption is one of these, separation of auth from consent is another):

d) standards and guidelines — the body of knowledge for developing secure software
would typically be embodied in a set of standards and guidelines. Typically, standards
would exist for each programming language, taking into account known
vulnerabilities and what is considered to be good practice. It is important that
standards remain aligned with industry developments such as emerging
vulnerabilities/threats and associated compensating controls.

What is the governments intention with respect to certification of software implementations which implement the altered international standards? Will the government be establishing a security software certification body? Will this be established prior to the proposed Feb 2020 go-live of live customer data?

Finally, repeating my previous comment:

As per "the onus should be on those who wish to make changes", please provide information and justification as to why Consumer Data Standards Australia has elected to not collaborate with the OpenID Connect Working Group and Open Banking UK to align to the existing International Standards and the emerging FAPI Lodging Intent proposal.

I implore Consumer Data Standards Australia and, by proxy, the Chair of the Data Standards Body to reconsider the decisions made with respect to the alteration and/or non-adoption of established and formally certified international standards.

[tpk1971]

Availability of Historical Transactions under authorization scope bank:transactions:read

Currently the standards are ambiguous on the maximum available period of historical transactions under the scope bank:transactions:read. The API /transactions endpoint has a default setting of 90 days if no value for oldest-time parameter is provided. Is this the maximum period of historical transactions that is required to be provided by a Data Holder to a Data Recipient? Additionally, is the oldest time parameter limited to the period of consent?

Consider the use case of a Lender accessing the Consumer as part of the assessment of a credit application. Under the ASIC responsible lending guidelines (https://download.asic.gov.au/media/2243019/rg209-published-5-november-2014.pdf), a minimum of 90 days is required to assess a consumers statement history (RG 209.66) , however most lenders have implemented a policy of 6 months to assess the income and expense profile for a loan applicant.

If a Data Recipient requests a short-term period of consent for a consumer’s data e.g.(1-7days), under the API what would be the earliest “oldest-date” that could be valid?

Additionally, consider a tax professional that is attempting to use the data to identify expenses that could be deductible for a consumer. Would they be able to access transactions for a period of 12 months to cover the previous financial year?

Additionally, should the consent request provide the consumer a notification of the period of historical transactions that are being requested and the purpose of its use?

[versent1Jas]

@JamesMBligh : Are the data holders obligated to validate the mandatory Request headers for Banking APIs and if the validation fails, are Data Holders expected to DENY the data consumption request issued by the TPPs.
https://consumerdatastandardsaustralia.github.io/standards/#http-headers

[perlboy]

Regarding #78, Biza.io wishes to first ask a number of questions regarding the independent security assessment document produced by Fortian prior to being able to provide feedback on the decisions taken (including the partial adoption of recommendations). As #78 is a locked thread it would appear this is the only place to ask about interpretation of the documents contents.

In-scope/Out of Scope
Regarding in-scope and out of scope items. Further on the original request in #78 to publish the scope statement Fortian adhered to Biza.io takes note that security scope within the document is stated as a single page. Of note is the statement on page 6 that statesIdentify areas of unjustified divergence from open standards that should be remediated.

In detailed review of the CDS in Appendix D (Page 36) the following is stated:

Defines the overarching approach to security. This information security profile is based on OIDC and the FAPI-RW profile, overlaid with specific directives from Data61 as to how to implement specific components of FAPI-RW.

Biza wishes to clarify what is meant by "OIDC". OIDC (OpenID Connect) is a suite of standards with a breakdown published as follows:

The current understanding of adoption is as follows. Core is adopted but with modifications to underlying standards (as noted in #77). Discovery is not adopted on basis of ACCC Register API expectations. Dynamic Client Registration is partially adopted (metadata published but ACCC Static registration) on basis that Static registration will prevail. Session and Form components are not adopted. Federation is not adopted, ACCC is publishing custom register data. Are these statements accurate?

Specifically on FAPI1/2 implementation Biza.io notes the following statement within the FAPI specification which is relevant when considered in a side by side analysis between FAPI-RW and CDS: To achieve the full security benefits, it is important the implementation of this specification, and the underlying OpenID Connect and OAuth specifications, are both complete and correct..

Finally Biza notes that at times the Fortian report specifies that individual assessment of OIDC* and OAUTH subsections is out of scope which leads to ambiguity as to where the scope of the assessment finished, some examples include:

• Page 19: Token signing is specified in FAPI2 and OIDC 6.3 (outside the scope of this review).
• Page 19: Entropy requirements are specified in FAPI1 5.2.2 (outside the scope of this review).
• Page 20: Addressed in OIDC 6.3 (outside the scope of this review).
• Page 20: FAPI1 7.1 (outside the scope of this review).

Closed Ecosystem

Specifically on the intention of a closed ecosystem (which for security reasons Biza is supportive of), Biza notes the following on page 17:

Biza wishes to note that the Product APIs are part of the Standards that Data Holders must present and Recipients will be required to consume (Accounts link directly to Products). Current guidance is that these will be secured by Public CA certificates. While they may be listed in the Register metadata there is no cryptographic proof that an endpoint is a member of the CDR scheme managed by the ACCC. We have provided feedback multiple times that we do not support the use of Public CAs for any Standards defined payload related APIs.

The report provides zero mention of Product APIs however there is a specific reference to CORS implementation which is relevant in the context of why Public CA for Product APIs would be justifiable:

Are Product APIs outside the scope of this report?

Consent and Broad Access to Information

Biza notes that the original technical recommendation has been replaced by a business like "competitive solutions" answer:

Specifically with regards to this instance Biza notes that the consent model adopted by #77 has a direct impact on the implementation of consent. Further it is noted that the CX guidelines provide information regarding how this should be displayed from the users perspective. The altered recommendation is open ended in nature and seems out of place as a "security risk" resolution. Is this still a risk? How will it be resolved? "Market solutions" is insufficient for an audit and compliance based review by participants in the ecosystem.

Independent Assessment

Biza wishes to gain clarification on the definition of independent assessment. Specifically the above issue notes a statement of [This update has been made after the risks was discussed with the CDB].. Who is "the CDB"? This acronym is never used anywhere else in this document. Do they have appropriate experience and certifications to override what has been declared in the scope as expert assessment ?

Biza wishes to specifically ask whether this recommendation is the only change on this document? For clarity Biza evaluates the word independent using the Cambridge English definition as follows: not influenced or controlled in any way by other people, events, or things.

The aforementioned modifications is an indication there may be other changes and consequently impacts the perception of independent assessment.

[anzbankau]

Metadata update

From discussions in the registry calls, it looks likely Westpac's feedback (https://github.com/cdr-register/register/issues/4#issuecomment-510235999) for base URIs will be taken up. Based on these classifications and the standards page it appears the metadata update API would be classified as a Admin API. It feels this would possibly be more appropriately allocated to the 'Infosec endpoints' classification due to its relationship with this functionality (as opposed to being grouped with metrics APIs).

Scheduled payments 'to account name'

Account name should be optional from Scheduled Payments API (BankingDomesticPayee - https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingscheduledpaymentto) for the scenario where:

• It is a scheduled internal transfer
• The 'to account' is not covered by the current authorisation

In this case the target account name is not available

Transaction detail error handling

Following up on this comment - #67 (comment) - we would like to understand the expected behaviour when a consumer invokes transaction details where the transaction detail flag has been set to false.

Transaction detail NPP specific

Is transaction detail (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingtransactiondetail) meant to be NPP specific? Currently the fact that 'service' is mandatory makes this the case (with only NPP service overlay values). Additionally the description for payee is NPP specific.

[fahadbinrahat]

Question # 1:-

Please clarify if this understanding is correct:-

Does the integer in the header input x-v represent "< minor >" in "< major >.< minor >.< bugfix >" of documentation versioning?
....If not kindly clarify with example what can be a minor version and how will a x-v version map to CDR requirement version for requirements/specification traceability.

Question # 2:-

In light of definitions given on standards for URI version, x-v and x-min-v, can you please confirm if API response shown below is expected as per API requests

API Request:-

Given:-

URI:- /cds-au/V1/banking/accounts
x-v:- 4
x-min-v:- 2

Provided:-

Holder’s highest implemented version is 1.2

API Response
API responds with
x-v: 2

[anzbankau]

Payee end point scope

For GET /banking/payees - the scope is currently bank:accounts.basic:read

While it would appear appropriate to instead use bank:payees:read

Financial Institution for credit card direct debits

For the direct debit end points, could it please be clarified that in the case of direct debits on a credit card, the 'financialInstitution' (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingauthorisedentity) is not required.

ID Permanence rules

As per discussions, could it please be clarified in the standards, that for the ID permanence rules (https://consumerdatastandardsaustralia.github.io/standards/#id-permanence):

• That 'data consumers' refers to the Software product client ID
  IDs MUST be immutable across sessions but MUST NOT be transferable across data consumers. For example, data consumer A obtaining an account ID would get a different result from data consumer B obtaining the ID for the same account even if the same customer authorised the access. Under this constraint IDs cannot be usefully transferred between client organisations or providers.

• That 'customers' refers to the customer's digital identity in the data holder.
  IDs MUST NOT be transferable between different customers for the same data consumer. For example, a data consumer should obtain a different ID for a joint account if the ID was obtained independently using authorisations from both customers.

[spikejump]

Few clarifications are sought below.

Sharing Duration, Sharing Expires At, Refresh Token Expires At
Can there be more detailed examples of the exchange of messages including use of sharing_duration, sharing_expires_at, refresh_token_expires_at?

The example supplied in the Request Object section shows the claim 'sharing_duration' under both 'id_token' and 'userinfo'. Is this correct? Suspect the 'sharing_duration' claim should be under 'claims' and at the same level as 'id_token' instead of embedded in it?

In the Request Object section it is mentioned that "The iss claim SHALL NOT be supported as it duplicates the role of the client_id claim". What is the rational of mandating a SHALL NOT? Admittedly it is not a MUST not, however, is this necessary? What if the infrastructure software tool does not allow removal of 'iss'? Would it be simpler to specify that 'iss' and 'client_id' MUST have the same value or 'iss' MAY be omitted or 'client_id' overrides the role of 'iss' if both are present? The use of SHALL NOT can lead to debate between Recipients and Holders on whether 'iss' should be there or not.

In the Requesting Sharing Duration section, it is mentioned "The Data Recipient is able to obtain the expiration of sharing via the sharing_expires_at claim." Can this be further clarified via examples? Seems there are two ways this can be obtained? 1. via Token endpoint response, with a 'sharing_expires_at' field; 2. via UserInfo endpoint response, with a 'sharing_expires_at' field. Is this correct? Examples would help.

Refresh Token
The 'refresh_token_expires_at' value is determined by Data Holders. But it MUST NOT exceed the end of the duration of sharing consented to by the Consumer. If the consent duration is 365 days but Data Holder decides to set refresh token to expire 30 days from issue then does it mean the Consumer will now need to go through the full reauthorisation/consent flow again at the Data Recipients end every 30 days - even when the Consumer has given consent for 365 days? If this is correct then the Consumer may be mislead by the consent they provided. Is this a good experience for the Consumer? or May be it is intended that 'refreh_token_expires_at' is always the same as 'sharing_expires_at'? Can we have some clarification on this please?

One-time Password
In the OIDC Hybrid Flow section it is mentioned "The algorithm for the creation of the OTP is at the discretion of the Data Holder" but it also states "OTP MUST be numeric digits and be between 4 and 6 digits in length". The later seems to be dictating the algorithm Data Holders use to generate the OTP. Anything wrong with including alphabet in the OTP and of length longer than 6? Furthermore, it should be noted Data Holders can choose any available channel to send the OTP to the Customer. For example, Data Holder may not have registered a mobile number with the holder but only an email address. i.e. SMS may not be the only channel employed.