Feedback on version 0.1 of Information Security Profile draft

[lukepopp]

This thread is for feedback on the full 20/12 December working draft. Overarching feedback on the draft can be made here, and complete responses to the draft in .doc format can also be uploaded.

[lukepopp]

Commonwealth Bank's response:

20181219 CommBank Standards Submission.pdf

[AmexAUopenbanking]

Feedback on version 0.1 of Information Security Profile draft #45

• American Express would support secure app deep linking in the consent journey between the data recipient’s app/website to the data holder’s app (if installed) for the best customer experience e.g. using existing biometric sign-on/authentication with the data holder’s app

• From the ACCC Rules Outline published on 21 December 2019 - “7.26. Accredited data recipients must remind consumers every 90 days that an ongoing data sharing arrangement is in place.“ – Flexibility should be given to accredited recipients on how best to display this reminder as to avoid onerous user interface requirements.

[NationalAustraliaBank]

NAB's consolidated response: 20190118 Open Banking - NAB review on CDR InfoSec draft v 0.1.1 standard.pdf

[anzbankau]

ANZ's Feedback on Info Sec profile 0.1.1: ANZ's Feedback on InfoSec profile 0.0.1 -Date 18012019.pdf

[tgrid-usa]

Secure Logic feedback on Information Security Profile draft version 0.1:

Section 3.3 – Registry Given the important role of ACCC as the appointed Certificate Authority in the scheme, Secure Logic recommends that a comprehensive Certification Practice Statement (CPS) documentation is produced and distributed on the public domain. It should clearly include the information on certification and registration authorities, acceptable usage, availability, access control, initial identity validation as well as certificate application, acceptance, issuance, renewal, modification, revocation, suspension and status checking services at a minimum.

It is also recommended that Common Criteria certification is considered in the development of the ACCC Certificate Authority solution.

Section 14 – Consent In alignment with the Bill and Rules Framework, we would like to underline the concept of time-limited consent. The Standards should articulate the requirement to check for consent expiration which may manifest in form of an access token time-based validity for short-lived, session-bound consent or a more permanent datafield for longer term use.

The process of automatic clean-up, deletion or de-identification of data which consent has expired should occur on a regular interval and documented in the Standards.

[MacquarieBank]

Macquarie appreciates the open collaboration and feedback process to harden the information security standards for Open Banking. Information security is of paramount importance to Macquarie Bank and one of the key foundations for our existing Macquarie Open Platform. Please find below Macquarie’s feedback for v0.1 of the InfoSec profile.

3.2 Data Recipients What guarantees that Data Recipient is passing the correct consent reference to Data Holder. This might be intentional or mistakenly but may lead Data Holder to provide data which has not been consented by Consumer.

3.3 Registry We acknowledge that the roles and functionality of Central Registry is being defined and subject to change. We seek clarity on following

1. Will there be a certificate revocation list and how it will be managed. How frequently should Data providers poll the CRLs to keep up to data information on data recipients.
2. When meta data changes for a given Data Holder or Recipient and how will this be notified to the participants.
3. What will be the governance process for Meta-data changes.
4. Please include few examples to demonstrate various use cases of Central Registry.
5. What will be the availability of Central Registry and what is expected from Data holders when the central registry is experiencing service outages.
6. Will registry be accessible privately to authorized participants or will be available to public.

4 Authentication Flows

1. We seek further information on the merits behind adopting Hybrid Flow over Authz Code Flow and in what scenario the implicit part of Hybrid flow might get used.
2. We seek clarity on authentication flow for joint accounts.
3. Consumer Data security being top most priority FAPI-CIBA is considered to be more secured that Hybrid Integration Flow especially due to redirection increasing the phishing risk.

4.1 OIDC Hybrid Flow

1. We seek more clarity on authentication for joint accounts owned by more than one person.
2. What values of prompt parameters are permissible for end-user authentication
3. Please provide reasoning behind not supporting request_uri parameter

4.2 Client-Initiated Backchannel Authentication (CIBA) We consider CIBA as more secure that OIDC Hybrid flow but also mindful that CIBA has poor user experience than Hybrid Integration flow. We welcome both and request to have mandatory recommendations to get a consistent implementation across industry.

7.1 ID Token Usage of symmetric keys poses security challenges on how the key will be established and supported between Data Holder and Receiver. We recommend using Data recipient cert to encrypt the ID Token.

7.2 Access Token ‘n’ the expiry duration of access token should be practical and derived based on approximation of chattiness of Data recipients. Too long duration compromises data security and too short duration compromises refresh token security.

7.3 Refresh Token Refresh token expiry duration should also be aligned with consent duration.

8.1 Scopes The scope ‘profile’ seems to contradict with statement made in 7.1 of ID Token should not contain PI. We seek further detail on content of profile.

13.1 OpenID Provider Configuration Endpoint We suggest exploring options of managing OpenID config for each data holder to be centrally managed at the registry as part of meta data. Also access to OpenID configuration endpoint should be restricted to trusted data participants to reduce misuse of data and phishing attacks.

13.5 User Info Endpoint We seek clarification if there would be any throttling limit for Data Recipient on End User basis to restrict over usage of APIs to avoid scenarios where data recipient continuously ping Data holder to get up to date information about end consumer. This also applies on other APIs providing user related information.

13.6 JWKS Endpoint As mentioned in section 13.1 the JWKS endpoint should be protected and accessible to trusted data receivers only to protect metadata information.

[JamesMBligh]

Thanks for this feedback. Apologies for the absence of a response to date. @kirkee and I will review and respond.

-JB-

[commbankoss]

Hi James, Could you articulate the architectural intent / direction with respect to the trust model and its interaction with the directory and associated CA : Is it a. Similar to the current UK model. The existing infosec profile seems to be highly aligned with this model. b. Similar to eIDAS ( used by PSD2 ) c. Some other model. If this is the case - can you shed some light on the intent for how i. TPPs authenticate with Data Holders ii. TPPs authenticate with directory iii. Directory authenticates with Data Holder or the other way around.

Thanks Darren

[JamesMBligh]

@commbankoss, I haven’t responded to this as the answer is very dependent on the Directory design.

I think we are now in a position to give some clarity:

• The model will be similar to the UK but not exactly the same
• The Directory will be designed so that it is not critical to the operation of the regime (ie. It will provide the data required to authenticate and facilitate the regime but there is an expectation that this data is cached by all parties and not requested continuously as transactions occur)
• The Directory meta data will therefore contain the information needed for accessing holders and recipients as well as the meta data, certificate and JWT info needed

-JB-

[JamesMBligh]

Closing this issue as feedback has either been addressed or migrated to the decision proposal threads on the main API Standards repo.