Decision Proposal 71 - May 2019 Draft Information Security Profile Feedback Cycle 1

[JamesMBligh]

This thread has been created to accept feedback on the May 2019 working draft. Specifically this thread is for feedback on Information Security Profile.

We will also receive written submissions on this update on the basis that such submissions will be published subsequently. In accordance with our normal transparency policy all submissions will be made public. Written submissions should be submitted via the CDR email address: [email protected].

Where participants believe they have sensitive information to convey we will consider those discussions and give guidance on our preferred disclosure approach prior to meeting to discuss such issues. To discuss such issues please email us at the CDR email address: [email protected].

We will written submissions and feedback on this thread until Friday 21st June.

For feedback on the API standards please refer to the separate thread at #70.

[WestpacOpenBanking]

We support the inclusion of a consent API as a mandatory mechanism for banking. As we have stated in previous feedback, we believe that it is necessary for robust customer experience. A minimum viable design for a consent API should include functionality which allows data consumers to provide and query the information needed for authorisation, consent management and reauthorisation.

This information includes:

• A consent identifier
• Consent status (e.g. ‘authorised’, ‘active’ or ‘revoked at recipient’)
• Text describing the consent purpose for the consumer. Note that one application might have multiple consent purposes depending on the particular consent, perhaps "credit card application approval" and then "import payees".
• Consent type (i.e. once-off vs ongoing)
• Consent expiry datetime (if ongoing).
• Permissions (mirroring scopes initially). Note, in anticipation that future granular scopes will be required to allow Fintechs who are unable to meet the ACCC’s single “high bar” at launch to participate, this also allows the option of removing permission information from OIDC scopes entirely and following the UK’s model of a single simple scope, e.g. 'banking-data'.
• Information about the number of unauthorised joint accounts.

In any case where a consent API is not used in all banking consent interactions:

• Data61’s UX stream may be unable to make actionable recommendations in relation to consent (until the API was mandatory).
• Customers may only have limited ability to manage consents in an informed way.
• Data consumers would have limited ability to help customers grant consent or manage consent in scenarios where error occurs.
• Data consumers and data holders will incur rework costs in the long term once a consent API is made mandatory (as we expect will be the case).
• There is a tricky problem to determine when the appropriate time is to introduce a Consent API. Given the iterative approach to be taken with the evolution of the regime, over time we see the field by field pollution of security information with business information. This has already begun with the inclusion of the sharing_duration and sharing_expires_at claims.

In the particular case where a consent API is included in the standard, but only as an optional mechanism:

• Customers having inconsistent experiences depending on the data holder and data consumers that they interact with.
• Data recipients needing to maintain different implementations and experiences depending on data holder support for a consent API.

Recently, the ACCC has sought stakeholder views on options for an energy data access model as well as the principles and considerations for assessment of these options. We understand that the interim data standards body has been involved in this consultation. In consideration of other sectors, we think that the consultation paper strengthens the argument for a consent API:

1. Decoupling of consent and authorisation to the extent possible allows alternative flows to be used in other sectors. For example, a number of options presented for consultation in the energy sector appear to recommend that consent be authorised at the Data Recipient rather than the Data Holder. This would necessitate abandonment of the OIDC Hybrid flow as is used for the granting of Consent in the banking sector. In the current draft standard this flow is used to exchange consent information in lieu of a Consent API. Hence, a consent API may be necessary, rather than desirable, to exchange consent details between participants if that approach was adopted by the energy sector.
2. A consent API may serve to reduce audit complexity – authorisation at data recipient in the energy sector would place a higher audit burden on those recipients. A consent API would reduce audit complexity through the exchange of granular scopes. In particular, it will be less difficult to audit a series of Consent requests rather than check that every API request made is within the bounds of customer consent.

The following sequence diagram is a hypothesis on how consent authorised at the recipient (as is being considered for other sectors) may work with a consent API:

[anzbankau]

Auth Flow

• Use of Known channel by means of volitionary action from redirected page still doesn’t prevent Phishing. Effective treatment against it is customer education which admittedly can be relatively easier with consistency. Even with proposed approach Phishing can occur by directing customer to Data Holder’s look alike page to collect identifier and prompt for explicit action to be redirected to another Phishing page to harvest credentials.
• Discretion on how and where to authenticate should be left to Data Holder to decide as long as it doesn’t risk unauthorised access to Data Holders existing channels. Use of Authenticators like One Time Use credential delivered via trusted known channel to the customer provides effective control. Further restriction of access using those for only consent creation takes away motivation for Phishing attacks.
• ANZ believes authenticators like OTP delivered to customer's mobile on file or registered Mobile App which can be entered on redirected Data Holders page can provide balance not giving anything more than identifier as in proposal. Customers in this variation are not required to leave their current user agent or device to complete process and be redirected to Data Recipient from Bank’s known channel abruptly.
• Education piece here still offers consistency where customers are encouraged to not enter their passwords outside known channels (e.g. Internet Banking or Mobile) inline with industry education.
• We appreciate experience as a whole be taken into consideration for wider adoption and that standards can avoid being prohibitive to implement authentication of any type on redirect page.

Re-authorisation

We believe an approach to achieve similar outcome is by notifying customer about expiry of sharing arrangement either by Data Recipient or Holder. Customer can then make an explicit and informed choice by logging into Data Holders known channel for extension of sharing duration. Doing so provides an opportunity to review sharing arrangement created by initial authorisation.

This can offer the following benefits:

• Customer will be in control of extension duration and can elect to extend by directly going to Known Data Holder channel.
• Simplify implementation at both Data recipient and Data Holder. Avoid the need to build additional endpoints or CIBA for purposes of Re-authorisation.
• Data holder can conform to extension duration as per CDR within the extent of original sharing arrangement.
• Inline with proposal extension of duration can be made aware to data recipient through property in response of Access Token or Introspection endpoint.

Consent API

ANZ is supportive of consent API removed from standards.

Dynamic Client registration

ANZ supports view shared across the board on adoption of standards and that strong consideration be given to support dynamic client registration to avoid complexity in building, supporting and certifying bespoke implementation. This could also means delays on both Data Recipient and Holder to deliver as any standard tools and product offering from vendors won’t offer support to custom approach.

We appreciate further clarity in InfoSec standards on how authentication and trust will be established between Data Holder and Recipient in absence of central trust. In specific distribution of client IDs and credentials.

[commbankoss]

Commonwealth Bank welcomes the opportunity to provide feedback on version 0.9.3 of the Draft Information Security Standards.
The Standards identify a number of areas where further feedback is specifically requested before a decision will be made, and Commonwealth Bank has addressed those issues in our submission to this proposal.
Commonwealth Bank note that the Australian Competition and Consumer Commission (ACCC) have begun consultation on the design of the CDR Registry. The design of the Registry is critical to the secure operation of the regime. We note that there will be required amendments or additions to the standards once the design and function of the Registry become clear. Specifically, it is expected that future iterations of the Standards will include details regarding end points related to, Data Recipient registration, certificate revocation, Data Recipient discovery, and Data Holder discovery. At this time Commonwealth Bank are unable to comment on those issues without additional information.
Commonwealth Bank looks forward to working with the ACCC, the Data Standards Body and potential CDR participants on the Registry.
Open Banking Information Security Standards June 2019.pdf

[ralphbragg-ob]

In a personal capacity i would encourage the authors to review and incorporate the latest FAPI RW Draft (not the published specification) and incorporate the latest recommendations from https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md

Additionally, please refer to the FAPI Minutes published yesterday regarding intent passing. This meeting was attended by all significant standards authors and vendors in this space. Open Banking UK will continue to be using, like the rest of Europe a consent API as a first party service / data structure in order to decouple OIDC Consent from Business Consent - this pattern will be carried into CIBA for the UK. This is being done to enable consents to be dual owned by both the Relying Party (Client) and the Resource Owner as well as to facilitate better management, decoupling of business logic from the OIDC Authorization layer and enable migration. It also allows a single pattern to be adopted for all use cases.

Generally, I personally, would welcome additional engagement from Data61 in the development of these standards at the Open ID Foundations FAPI Working Group where this topic continues to evolve.

Of the seven options to support intent passing given on the ticket, the greatest support from vendors, including the majority of vendors used by the major banks in Australia, was for option 4, a link to a staged intent/consent payload. It is recognised as a complex subject one that is being tackled by the standard body.

A more formal write up of the decision of the standards and vendor community will be incorporated both into the UK Specs and the Next Drafts of FAPI RW and CIBA next week.

1. Do nothing; ecosystems may well decide to use login_hint_token to pass extra context, which is undesirable as it is defined as 'A token containing information identifying the end-user for whom authentication is being requested', and using login_hint_token precludes using login_hint or id_token_hint for their intended purposes.

2. Endorse use of login_hint_token for this purpose & redefine it (undesirable for similar reasons to '1')

3. Emphasise that new (not defined by FAPI-CIBA) parameters should be used to pass intent

4. Dynamic scopes with a lodged intent id, e.g. scope=openid payments:5514cacc-93da-11e9-bc42-526af7764f64

5. Dynamic scopes without lodging, e.g. scope=openid payments:{"amount": "100.00", "to-account": "22-21-11 23467755"} (or variants thereof that add base64 encoding etc)

6. Structure scopes, https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948, e.g. a new claim in the signed request called structured_scope containing {"payment":{ "amount":"123.50", "to-account": "22-21-11 23467755"}}, or {"payment":{"intent_id":"5514cacc-93da-11e9-bc42-526af7764f64"}}, and removing the current scope parameter or passing purely scope=openid.

7. Define a new a new claim in the signed request that is used alongside existing scopes, e.g. intent containing a JSON object "intent":{"payment":{ "amount":"123.50", "to-account": "22-21-11 23467755"}} or "intent":{"id":"5514cacc-93da-11e9-bc42-526af7764f64"}

[NationalAustraliaBank]

NAB welcomes the progress and collaboration that Data61 has promoted so far, though there are still key decisions and impact assessments that must be closed out for InfoSec profile, including:

• Alignment and clear decisions with the CX stream to land a position on the authentication, authorisation, and re-authorisation flows.
• There is a key dependency on the completion of the ACCC's Directory and Registry design activities, which will need to be accounted for in the end to end standards and security review.
• An independent security review of the standards needs to be completed and any high risk issues addressed in order for industry to have confidence in the standards as a whole.

Failure in the achievement of acceptable outcomes and the closure of these gaps will lead to further delays in the implementation and delivery of the CDR regime.

Consent Authorisation Flows
The Consent Authorisation Flow is one of the key dependencies for the expedition of the CDR delivery activities. NAB insists on the adoption of the Hybrid Redirect to Known Channel consent authorisation model as it provides a balanced level of security (see previous #62 (comment)). Alternatively, NAB could support the Redirect with OTP flow which was presented by Data 61 at the CX workshop held on the 5th June, provided that security principles agreed by industry participants and mitigant controls are adopted and independently security audited. Security principles for this flow must include:

• Customer bank credentials must not be input in a Data Recipient solution for authentication
• Passwords must not be used for consent authorisation in a full redirect flow
• Consent authorisation must be completed in an environment dedicated purely for consent authorisation
• The OTP must be short-lived and specific for the current consent request

Consent API
NAB insists on the implementation of the Consent API to future-proof and enable flexibility and extensibility of the consent object and the regime. Having an explicit Consent API would enable future benefits such as:

• Bounded dates for transaction history for which the customer wants to share with the Data Recipient. Currently, all transaction history would be shared (up to the limit specified in the ACCC Rules and Designation Instrument). The CDS CX Phase 1 report recommends applying the data minimization principle to the data time frame in the future and the past - third party providers should only request the time frame they require to provide the service, e.g. 1 year prior and post consent for an accounting tool
• Consent expiry - The proposed CDS has this in as a custom claim (“sharing_duration”) in the OIDC security standard. The UK implementation has the consent expiry in the Consent API
• Ability to introduce fine-grained control over specific data fields within the existing data sharing APIs
  • E.g. A “Transaction History Sensitive Data” permission could indicate that the “Get Transactions” API will include transaction description / narrative in the data payload; without this permission, basic transaction detail (amount, category, etc) would only be shared. This aligns with the CDS CX recommended permission language of "Description of transactions"
  • E.g. A “Transaction History Debit” and “Transaction History Credit” permission would allow customers to control if debits and/or credits will be shared to the Data Recipient. This aligns with the CDS CX recommended permission language of "Outgoing transactions" and "Incoming transactions".

The Consent API (or similar capability) will be required at a future date and designing for it now reduces future impact and costs for Data Holders, Data Recipients, vendors and aggregators.
If the implementation of the Consent API (or similar capability) be left for future architecture and design, specific conditions and trigger points must be defined for the kick off of design and build activities.

Re-Authorisation
This is another area that must be closely aligned with the CX requirements and NAB insists on the following considerations:

• Re-authorisation is not required for the initial go-live. NAB proposes that re-authorisation happens as a brand new authorisation in order to de-risk and reduce implementation requirements across participants
• To finalise the re-authorisation design, CX testing activities and industry collaboration must be completed so that Security and CX requirements are clearly articulated and impacts to implementation are understood
• The CX stream must outline the standards for notification and flows for re-authorisation, incorporating requirements defined by InfoSec and the independent security review
• The customer must re-authenticate and re-authorise in the Data Holder's channel to ensure that appropriate controls and checks are enforced
• Implications to joint account owners need to be considered during the re-authorisation flow. This has previously been mentioned as being in the competitive space, however this will likely have an impact from a standards perspective

Register
NAB welcomes the kick off of ACCC's register design activities. Integration with other components / interfaces must be properly aligned for the entire system to work. Delay in this design means that participants’ ability to implement has been impacted. To efficiently achieve an appropriate outcome, the ACCC need to conduct collaboration workshops and transparent consultation. The following are key areas that must be of priority:

• Client registration - dynamic vs. static registration
• Industry Alignment
• High Availability
• InfoSec profile

Decision Proposal 065 - Transaction Security
A final decision paper was completed for DP65, however it did not include clarification around options for which certificates are to be used for Product API endpoints. This needs to be confirmed for Product APIs.

[CDR-InfoSec-Stream]

Hi All, this is the new persona for the CDR Information Security Stream that will be used for posting by the Data Standards Body. You can expect to see more interactions from this profile as we continue to progress.

Thank you all for the contributions to date for this consultation. The consultation period is now complete and this thread will be closed for further posting. The submissions provided via email will be added here, however.

A new thread for holistic (API and InfoSec) feedback will be opened shortly for ongoing feedback.

[CDR-API-Stream]

For a summary of the feedback provided for the May draft please refer to this comment in issue thread 70: #70 (comment)

[CDR-API-Stream]

Note that the decision for the majority of the feedback to the May 2019 draft can be found here: #70 (comment)

Decisions regarding Consent and Authorisation Flow will be published separately.