Decision Proposal 005 - Authorisation Granularity

[JamesMBligh]

This decision proposal outlines a recommendation for the granularity of authorisation scopes as they would apply to API authorisation in the scope of the API standards. There is some overlap in this decision with the Security working group. An attempt has been made to minimise that overlap.

This proposal has already been provided to the Advisory Council for preliminary feedback.

Feedback is now open for this proposal. Feedback is planned to be closed on the 7th September. Decision Proposal 005 - Authorisation Granularity.pdf

[NationalAustraliaBank]

This proposal helps simplify the API authorisation scope; however, there are a number of other considerations that will need to be acknowledged or further clarified:

Cross Channel Integration

“It is recommended that existing credentials already being used by customers for accessing their data via digital channels should be used for the authorisation of access to API standards.”

Is this recommendation/guidance for just for the initial phase (i.e. July 1st, 2019) or is this the intent for the entire scheme? i.e. is this a recommendation or a requirement?

If this is the a requirement for the full scope, then it needs to be understood that many of the products, particularly corporate and institutional products, may not be available through digital channels and will following this logic not be included in the roll-out of Open Banking; to do so it would require substantial enhancements to the existing digital banking capabilities.

These products which are not currently digitally accessible were included in the Farrell Report; however, we agree it is pragmatic for the initial phases of the Open Banking to keep the scope constrained to what is digitally available now; this reduces complexity, and ensures we only deliver services which are of actual use to our Customers.

Extending on this statement, all banks would not have the same products and services available through their existing digital channels. For these products and services what is the guidance? Or is the intent of the statement more focused on the point that Customers should not need to register a new profile, and that new services and data should link to the appropriate existing channel profile and credential sets.

Under what circumstances would it be permissible to create a new identity for our Customers? Given the Consumer Data Right is a customer centric scheme. We recommend not constraining providers on how they implement the scheme as there is a multitude of considerations at play. I.e. Registering a new customer centric ID might be insignificant when compared to the challenges of data sharing across multiple product centric profiles in a customer centric world.

Existing credentials can be owned by users who are not account owners. The question is then whether these users should be allowed to authorise data sharing of an account owner’s data with a third party. This raises a question as to whether the account owner (consumer) has provided their clear and explicit consent/authorisation to share their data for a known purpose or NOT? There are similar issues and complexities around joint-accounts where the proposed model exacerbates the risk of unauthorised and (unintended consequences) of data-sharing. It could be the customers expectation that authorisation would be obtained from each account holder, or at a minimum visible to each.

These issues are more evident for business banking solutions, where payment authorisers (e.g. finance department), who may have channel credentials and are authorised to make/approve certain payments, would inherit permission to share organisational data. Being able to make payments for an organisation does not mean you should be able to share an organisations’ data. In our view, there is a distinction on who can access the data and who can share the data. Blending the two may lead to legal disputes and security issues (i.e. data leakage, brand damage).

To ensure authorisation is given by all legal account holders of a particular account, a suggested approach is that data sharing permissions are controlled separately from the view and payment permissions (i.e. a business customer would require approval of that enterprise's directorship rather than someone from the finance department). This ambiguity creates challenges and complexities when looking at a 1 July 2019 implementation date. Data privacy is something that should not be taken lightly, we need to make sure we fully understand and quantify the risks before committing to and locking in scope and against fixed timelines.

For customers that have products available on multiple digital channels and/or credentials it is likely that they could encounter a scenario where consents for the same account are duplicated and in an inconsistent state. (i.e. on one profile, consent has been revoked, and on another profile consent is still in place. This may become confusing for Customers and lead to justifiable legal disputes for data providers) The customer will not have central visibility and control of their authorisations.

The statement, “If they can access an account via Internet Banking then they should be able to access it via the Open APIs” Does this statement mean that Customers themselves can access their own data via a Restful APIs?; I.e. allowing them to build their own apps? If this is the case, it will add complexity to the scheme. OR is the intent of this statement more of a guiding statement around the types of data that should be made available via the open banking channel.

Authorisation Granularity

Note that we do not yet have a date for “Customer Provided Data” (Farrell / CDR data scope) which seems to align with “Customer Data” (this proposal scope). Should the reference to dates be removed from within this decision proposal?

Other Recommendations

Time based authorisation should be limited to the defined purpose of use with a set timeframe. Leaving this decision completely to the customer may result in excessive access. Customers may not understand the technical implications of allowing a once-off access or extended access (i.e. authorisation for a third party to access their data for 3 months).

A balanced option could be achieved by having pre-determined time-frames defined based on use cases; (i.e. which third parties and/or which use cases require a once-off access or extended access and provide this information on the consent/authorisation screen).

Once a time-based authorisation expires, would any extension only come via a new request? Or would there be a simple way of renewing an existing consent? Finally, we would like to re-iterate the concept of explicit consent and authorisation. We believe any authorisation should be tied to a particular Data Consumer. It should not be possible for one consumer to pass access or data to another consumer without the explicit customer consent and/or authorisation from the Customer(s) in question.

[davidthornton]

From the perspective of customers and a fintechs, if there is no option to enable standing access and authorisation for a third party app then the scope and (more importantly) financial sustainability of innovative financial management apps is severely curtailed.

It should be the decision of the customer as to whom they grant access to their data, and incumbent upon the banking service provider to display prominently the connected apps with standing authorisation throughout the first party (if any) app experience.

[c-j-hughes]

The implication of this approach is that the APIs under the standard simply become another channel for a customer along side their existing channels with the same levels of access and servicing mechanisms. If they can access an account via Internet Banking then they should be able to access it via the Open APIs. If they lose access to an account in Internet Banking then they should also lose access to that account via the Open APIs – even if they have previously authorised access to that account.

We would expect that a user with an owning relationship to an account, would be able to share that account outside the bank. But a person who had just a signatory relationship would not. In both cases the user would be able to see the account via their digital channels.

While the proposal on this point cites which accounts are available to share, the proposal is substantially reducing the number of permissions available. One of the capabilities in the UK standards that the proposal withdraws is to provide separate permissions for viewing basic data vs detailed data. In the case of accounts, under the UK standard a detailed permission is required to see the actual account number - which is more sensitive than the balance and nickname. In the case of saved payees, the creditor account details also require elevated permissions.

When the Australian standards are expanded from read-only to support payments, this distinction would be valuable to maintain, as the account numbers are especially relevant to data consumers that intend to perform payments, and not so much in other scenarios.

The proposal seems to prefer this simplification on the grounds of either simpler user experience, or flexibility for data consumers by being less prescriptive. We would argue that this goes strongly against the principal of the user providing explicit informed consent.

Permissions that control similar kinds of data could be simplified however, for example, standing orders, scheduled transfers, direct debits arrangements etc, might all be considered "Transfer Arrangements". Statements are really the same as transaction history.

[ghost]

Disclosure - Member of the Advisory Committee

NAB - agree with your comment:

Existing credentials can be owned by users who are not account owners. The question is then whether these users should be allowed to authorise data sharing of an account owner’s data with a third party. This raises a question as to whether the account owner (consumer) has provided their clear and explicit consent/authorisation to share their data for a known purpose or NOT?

Example: Customer may have view only Internet Banking access, and all of sudden they have shared bank account information for a purpose outside of their 'intended privilege'.

As such, also agree with NAB view that it changes the 'game' as new authorisation layers may now be required at the gate keeper level (i.e. Bank) to allow differing levels of view access and share access.

Failing this, and should this not be achievable by the July 2019 timeframe, significant internal policy and procedural changes will be required that would now 'push' the expectation of data sharing back to the customer. i.e. if you want this business account on Internet Banking, you now have to realise dear customer that you signatory can share this account information with a Fintech provider who can do 'XYZ' with the data....Did your Director really want you to do this?

Director - yes its all OK, I will accept the new T&Cs Director - No Dear Bank, don't like this, please remove my signatories access.

As you can see, the various challenges require careful thought and segregation of sharing privileges from transaction privileges seems to be the answer...

[JamesMBligh]

Below is feedback on this proposal provided by ANZ during the Advisory Committee review. It has been posted here by agreement with ANZ for transparency and visibility.

-JB-

Data61 Recommendation subcomponent	Recommendation description	ANZ Response
Cross Channel Integration	It is recommended that existing credentials already being used by customers for accessing their data via digital channels should be used for the authorisation of access to API standards.	Broadly supportive of existing credentials being used by customers for accessing their data via digital channels, with the following considerations:• Implication is “what you see you can share” may be at odds with CDR and privacy regulations. This needs clarification from regulator.• Our existing set of credentials will be part of the approved subset of credentials (i.e. that there be flexibility as to the credentials used) and that we will not be obligated to adhere to a specific credential set that we do not use today or plan to use in the future.• Participants may not show the same/consistent data sets in digital channels – may require some flexibility in the data standards.
Cross Channel Integration	If they can access an account via Internet Banking then they should be able to access it via the Open APIs. If they lose access to an account in Internet Banking then they should also lose access to that account via the Open APIs – even if they have previously authorised access to that account.	Broadly supportive of the idea that the scope of data is not broader than that which is visible in digital channels today. It should not be specified as being the same though as some things in channel may be bespoke priced and hence outside the scope of being ‘widely available to the general public’
Authorisation Granularity	It is recommended that a set of high-level authorisation scopes be defined and that each API end point should be mapped to one of these authorisation scopes as part of the standard settingprocess.	Recommend that this section of the proposal be modified to consider:• Overly broad scopes may result in customer sharing unnecessary data.Recommend that the scopes allow for finer sharing controls (e.g., read account basic, read account details, read transaction credits, read transaction debit, etc.)  so that scope of data sharing is tightly aligned with the explicitly stated usage.• Party data is not consistent across different digital channels. Also, party data may vary on an account basis (e.g. different address for different accounts), entity type, e.g., business entity vs individual, as well role type (owner vs operator)In order to prevent a poor CX, we recommend that party scope initially be limited to a narrow attribute set (e.g., name and email address) or clear distinction be drawn on party attributes based on entity type, role, sharing purpose, etc.
Additional authorisation in the competitive space	It will be left to the competitive space if a provider wishes to provide their customers with additional authorisation flexibility. For instance, a data provider may wish to allow a customer to specify which accounts should be accessible under a registration.	Broadly supportive, however, potentially at odds with the assertion that what you can see you can share (as per feedback above). Would suggest that the authorisation mechanism/technology protocols be separated from the business rules
Additional scopes for extended data	Under the extensibility model for the standards, if additional data types are made available then additional scopes may be required.	Broadly agree, however,• New scopes should not be in conflict with existing and agreed standards and impact consideration should be assessed by all participants.• Must conform to the agreed data model (precedent to any API development), i.e. extend the model not materially change the existing model.
Scopes will be added as the regime expands	Over time, as the regime expands, new scopes will be added to the regime.	Broadly agree, however, should not be at odds or conflict with existing and agreed standards.• Should conform to the agreed data model (precedent to any API development), i.e. extend the model not materially change the existing model.• Additional scope should still be standardised and governed under Open Banking regulations to avoid misalignment between participants, potentially resulting in a poor CX and outcome.
Scopes will be set via consumer registration	Scopes required by a client will be presented to the customer during the authorisation process.	Agreed
Time based authorisation	At the time of authorisation, along with the scope of authorisation, the customer will also beinformed of the length of time that authorisation is being sought by the third party.	Agreed
All authorisations are time based	There should be no concept of indefinite authorisation.	AgreedRegardless of the intent of the data sharing window, e.g., one-off, ongoing/long standing, etc., consents must be finite (e.g., UK model where customer needs to authenticate and authorise every so 3 months) and in the case on long-standing data sharing windows (>90days), re-authentication and authorisation is mandatory every 90 days (or similar agreed period).
Customer can arbitrarily end authorisation	The provider should provide a mechanism for a customer to see the authorisations that are currently active as well as the ability to cancel any of these authorisations if they so desire.	AgreedConsent or authorisation or delegated authority? Consistent terminology required.

[JamesMBligh]

Below is feedback on this proposal provided by CBA during the Advisory Committee review. It has been posted here by agreement with CBA for transparency and visibility.

-JB-

• CBA is comfortable with using the OAuth2, OIDC, and UMA 2.0 protocols and standards as the basis for authorisation and access management. A strong recommendation is that the data standards body look to uplifting the cryptographic and security standards as per the Financial API (FAPI) WG Standard under the Open Id Foundation.
• Use of an existing credential is the only method of identity and authentication CBA will endorse. This credential should only ever be entered on a trusted bank-owned property, and no personally identifiable information should be disclosed to a third-party prior to consent and authorisation being established.
• CBA support the establishment of a set of high-level authorisation scopes, as part the OAuth2/OIDC protocol, that establishes consent for the sharing of data with third parties. These scopes should be set up as collision resistant namespaces for fine-grained claims to be recorded in the JWT to be used within an access token
• The current proposal defines the scope of authorisation as being prescribed by the consumer registration. CBA feel that we should empower customers to be able to define a granular level of scoping based on their comfort level to disclose data to a third party. The scope of this authorisation should be able to be withdrawn or changes at any time period post-consent.
• The proposal alludes to the implementation of Open Banking as being seen as an extension to the existing channels within online banking domain. As there is a substantial change in the risk posture for requests originating from outside of the banking, CBA feels this positioning needs to be adjusted. Requests for CDR data should be held to more scrutiny for both customers and the bank to ensure they are legitimate and the adjusted risk profiles can be managed.
• CBA has a concern around a mandated User Experience journey for the authorisation and consent flows required as part of the CDR. Although we wholly agree that there is no appetite for unnecessary friction, being a financial institute that receives ~40% of the Australian cybersecurity attacks (by volume) we are continually refining our security defences. This includes introducing new innovation, such as biometric and passwordless interfaces, with the overall aim of enhancing security whilst reducing customer impediments. CBA feels any mandated customer flows would potentially compromise our security defences and as a result would reduce our ability to innovate in this field.

[speedyps]

Should all authorisations be time bound - especially where the access is read-only?

I completely understand this for Payment based calls, but where read-only access is provided, it seems like it could be adding a level of friction for the consumer. I believe that the original intention in the UK was for the 90 day expiry to be specific to payments, but it was documented in a generic way which was interpreted as for all access methods.

I do not need to reauthorize my mobile banking app every 90 days, should I need to do it for other applications that are reading my data?

As each bank is in control of the tokens, any token can be revoked at any time, forcing a re-authentication by the user.

Is a possible middle ground here that if a read-only token is not used for 90 days, it is automatically expired. ie the use of a token resets the time period to 90 days from last access?

[ghost]

I share similar views to speedyps re time-bound authorisation. From a trust point of view, enforcing re-authorisation is a positive and is great for applications requiring ephemeral access. But from a UX point of view, it could be a negative in applications involving perpetual data sharing requirements. E.g. If I authorise my bank to share my data with fancy fintech ACME (A Cool Mobile Experience) so that I can use ACME's app on a daily basis, I would find it annoying to have to re-authorise this access every 3 months.

The ideas of an auto-expiry after a defined period of inactivity and/or regular reminder notifications of perpetual authorisations granted might be ways of addressing concerns???

It would be good to get other's thoughts on this, too.

[Promysys]

Disclosure. Our representation in this committee is through the Australian Industry Information Association (AIIA) however the author also represents Priviti Group.

AIIA is advocating Openness and Transparency to support vitality in the Fintech community to enable Customer centric competition and innovation within Open Banking. Data sharing must recognise the social policy of the customers data right and avoid any standardisation that is banking specific due to its broader applicability. It is also important to recognise the multitude of digital identity and personal id projects underway across multiple industries and our standards need to be cognisant of the broader use cases for Data Sharing and specifically Consumer consent.

Priviti has developed a Consent Management enabler that works alongside the traditional Authorisation standards typically encompassed in OAuth2.0/OIDC to provide a greater level of flexibility and control to Consent Management for Open Banking transactions. The Priviti emphasis is on ensuring the security of the credential provider (the banks) while giving greater control to the Consumer to control the consented release of transactions/data. This submission whilst on behalf of the AIIA does also represent view of the Priviti Group due to our focus on Consent.

The experience with Open Banking in Europe requires referencing the introduction and impact of GDPR. The confluence of regulations (GDPR, Open Banking and PSD2) together with market behaviour (e.g Cambridge Analytica) created a paradigm shift in attitudes to data. It is our recommendation that as large scale technology investment is being made by both banks and fintech/regtechs to embrace open banking that Customer Consent for data sharing should be explicit and requires a specific approach to support the Consumer expectations. As such we propose that best practice would incorporate the following:

1. All entities engaged in Financial Services should commit to the publication of a company wide consent policy for data sharing
2. Use Open banking to achieve a common understanding and code of conduct relating to the data sharing ecosystem
3. Distribute a truly digital platform and process rather than digitizing a paper based process so that all data sharing arrangements and new innovations can be entered safe in the knowledge that they auto-comply with regulation and consent policy
4. Enable all members of the ecosystem to view, grant, revoke and renew consent using a digital platform with full audit trails to ensure independent regulatory oversight.

Data61 Recommendation subcomponent	Recommendation description	Response
Cross Channel Integration	It is recommended that existing credentials already being used by customers for accessing their data via digital channels should be used for the authorisation of access to API standards.	Standards need to be Consumer centric rather than Credential Provider centric to further support increased competition.  OIDC is Credential Provider centric which supports the purposes of the larger established banks but there are more innovative ways to support the Consumer and emerging FinTechs to integrate within the Open Banking marketplace.  Consumer centric authorisations protect the Consumer. ·      A unique password (bound to a presenter identifier), specific to the Transactions to be approved should be a requirement ·      Auth/OIDC implementations typically use the clients bank login credentials to authenticate ; so in a typical Presenter Centric implementation for PSD2/GDPR the user should never have to give in their private credentials whereas in most bank OAUTH/OIDC implementations they must do so. ·      While OAUTH/OIDC is regarded as being secure the fact that you have to give credentials leads to a concern about potential Phishing attacks and maintaining Privacy.
Authorisation Granularity	It is recommended that a set of high-level authorisation scopes be defined and that each API end point should be mapped to one of these authorisation scopes as part of the standard settingprocess.	It is important to draw a distinction and differentiation between authentication and authorisation as, although they may appear similar, they are in fact very different: Authentication is the process of identifying and confirming that a particular entity is who they say they are. Authorisation is the process of granting certain permissions or consent to certain users so they have access on the system.   All services require a user to be authenticated before making requests to the platform.  Consumer Consent needs to be explicit for handling authentication and authorisation.   Authentication should be handled using either an API key or an OAuth token (set in the header Authorization).  This flexibility provides choice to the Consumer for when they obtain Consent.   Granular Authorisation on a Consent Management platform can then be handled using Role Based Access Control (RBAC). RBAC makes it easy to associate permissions to roles, and roles to users; this separation of concerns makes it easy to apply new permissions and to add/remove roles from users in independent steps. RBAC is beneficial as it separates the concerns of users, roles, and permissions. Roles are defined in the system and then permissions are defined separately. Depending on what actions a particular role should be permitted to perform, those permissions are assigned to that role. Users can be assigned the roles.
Scopes will be added as the regime expands	Over time, as the regime expands, new scopes will be added to the regime.	Agree, however, Presenter centric flows split messaging across two channels whereas OIDC/OAuth2.0 flows rely on the use of tokens over single channels. Multi flows offer increased security and is most effective over multiple device transactions. This supports the intent of Open Banking beyond individual transactions and limited use cases and could be used in conjunction with OAUTH/OIDC to provide a secure an trusted ecosystem for both Consumer and Credential provider.   Agreed standards is the point of this exercise and we purport that the current standards do not sufficiently favour the consumer, simplicity and KYC/AML obligations which in turn result in poor CX outcomes.   The recent implementation of Open Banking in the UK, PSD2 in Europe and now Open Banking in Australia have a common intention to increase competition and reduce technology induced inertia for consumers. "Strong Customer Authentication" and "Dynamic Linking" are examples of best practice effective security measures and some of the most positive aspects of PSD2.   To boost user adoption, it is our view that a systemised common standard for obtaining consent should be adopted ideally avoiding the redirect system.    The following attributes are critical in providing Consent: • A decoupled process flow avoiding phishing threats from “redirects” being intercepted. • Sensitive information is only entered on a trusted bank-owned  technology  • no personally identifiable information is ever disclosed to a third-party prior to consent being granted, authentication of the user and authorisation being confirmed by the bank • specific ‘Granular’ consent can be requested by third parties and granted by users subject to the terms and conditions laid down by the banks and regulatory bodies • enhanced (rather than perceived reduced security of OIDC) authorisation flows eliminating unnecessary friction
Time based authorisation	At the time of authorisation, along with the scope of authorisation, the customer will also beinformed of the length of time that authorisation is being sought by the third party.	The consumer should also have reasonable control over the time based Consent whether it be per transaction or event.  The ability for the Consumer to review and revoke Consents should be allowable inside predefined guidelines by the Credential Provider
All authorisations are time based	There should be no concept of indefinite authorisation.	Agreed and must be configurable.  The Consumer should have the ability to review and revoke Consent at any time.
Customer can arbitrarily end authorisation	The provider should provide a mechanism for a customer to see the authorisations that are currently active as well as the ability to cancel any of these authorisations if they so desire.	Agreed and agree with the need for consistent terminology, we are talking about explicit Consent not simply authorisation.

[TKCOBA]

The API authorisation process, and its potential control mechanisms, raises questions around what types of data would be captured under Open Banking and issues associated with certain data. For example, different types of accounts (such as joint accounts and children’s bank accounts) raises questions around explicit consent. While we recognise that the Government will soon consult on the scope and granularity of the data under Open Banking, we would appreciate further clarity from Data61 on the types of data that would be captured under the recommended high-level authorisation scopes (e.g. ”Public”). We suggest that the recommended high-level authorisation scopes are revisited following finalisation of the banking sector designation instrument, to ensure they support the instrument.

The API authorisation process also raises questions around the use of existing credentials by an accredited third party, and there needs to be transparency around what these credentials would be.

It is important to remain mindful that customers need visibility of who has access to their data, what scope has been granted and an ability to revoke that authorisation at any time. Revocation also raises the issue of happens to the data once access is revoked. We recognise that the ACCC CDR rules will address de-identification and deletion of data and encourage Data61 to work with the ACCC on the rules and guidance, as appropriate.

In relation to time-based authorisation, we consider that pre-defined periods (e.g. 1 day, 1 month or 3 months) would support a higher level of customer experience, as opposed to allowing an accredited third party to input the time period.

Recognising that this decision proposal does not seek to pre-empt decisions that will be made by Data61’s Security Working Group, we would encourage this decision proposal being also explored by that working group.

[Pelsurry]

This is a topic in which competing and, to some extent, largely unreconcilable views will need to be finely balanced. Without addressing the entire discussion, I raise the following points:

1. I agree with concerns about automatic reauthorisation every 90 days (see @speedyps) . In practice in the UK, this is proving to be an irritation to consumers (particularly when the use is read-only not write). It is further complicated by the likely need to notify every person with authority to act on the account. Privacy safeguards in the draft legislation and the Farrell Review point to the equal treatment of joint account holders and, by extension, anyone with authority such as a director and finance officer in the case of a company. That’s a lot of notices going out frequently for little obvious benefit. This is better handled by a right to get a report on how and where data is being used (such a right is included in the draft legislation)

2. The proposed approach has the advantage of being easier to implement and brings with it the already significant investment in security by the banks for their online channels. However, as discussed in the comments by @DermotMcCann, it does appear to be Credential Provider centric not to mention the issues raised by @NationalAustraliaBank.

3. I’m wondering how the proposed approach (using existing online bank credentials) will work with Privacy safeguard 2 (anonymity and pseudonymity) in the draft Consumer Data Right bill (release Sept 18)

[da-banking]

Indefinite authorisation @speedyps and @mattp-rab the arguments about the diminished UX for time-based authorisations are valid.

Banks are enormously cognisant of the trust their customers place in them to protect their customers data and money, and would want data consumers to only request the minimal authorisations necessary to provide the data consumer's service to their customers. The concept of explicit informed consent is important here, though there is valid concern about consumers being easily manipulated by fine print.

Open Banking offers the banks little in the way of enforcing the principal of least privilege on data consumers, and it is probable that data consumers will ask for all privileges from day 1, just in case they need them later.

@speedyps - The suggestion of revoking indefinite authorisations, would not be effective. The data consumers accessing the data providers on behalf of the PSU would simply implement a regular ping to keep the token active.

@mattp-rab - The suggestion of reminders about indefinite authorisations would also be ineffective, as there is no way to know if notifications have been read, without requiring the user to reply in some way, which is the same as renewing the authorisation - the thing we are trying to avoid.

It is unclear at this time, what security practices the ACCC will audit data consumers against in order to approve their access to Open Banking. And in the absence of a clear position on these rules, time-based authorisations are one way to limit the damage that a breach at a data consumer could do to consumers, the banks, Open Banking and the Consumer Data Right in general.

We recommend against allowing indefinite authorisations at this time. Poorer UX seems to be a worthwhile trade-off in this case. Though not ideal.

Although we do not disagree in principal with the idea of indefinite authorisation, provided the PSU has explicitly consented, if this was to be permitted, it should be controlled.

The ACCC could allow specific data consumers the privilege of longer or even indefinite authorisations based upon their level of certification. If a data consumer was deemed to be working to the same security and privacy standards as banks, then it does not seem that this higher privilege would be abused, and a better UX would follow.

Separate to the security concerns, and possible controls outlined above, it would be easier to proceed with time-based authorisations on day 1, and then expand upon that in a later revision, than to allow indefinite authorisations from day 1, and try to constrain it later if it is problematic.

In the former case, tokens can just last longer. In the latter case, indefinite tokens could be revoked by data providers, but data consumers that weren't built to solicit renewals from PSUs would be broken and their businesses damaged.

Mandated User Experience Journey

CBA has a concern around a mandated User Experience journey for the authorisation and consent flows required as part of the CDR.

We understand the challenges in the UK, where banks were accused of making the user experience so complex that few users completed the authentication/authorisation flows.

CBAs concerns are very real, and we share them too. Each bank has its own, multi-layered approaches to security, and requires the freedom to respond to new threats unilaterally. OIDC is enormously flexible in this regard which is why it is such a good fit for Open Banking.

If banks are deemed to have established anti-competitive processes, this should be investigated by escalation to the ACCC, not by limiting how banks protect their customers.

We recommend against a mandated user experience journey.

[bazzat]

The ABA Online Banking Technical Working Group makes the following observations:

We are collectively supportive of the comments already made here on GitHub by NAB, ANZ and CBA.

Additionally our members note:

1. The customer should not be required to disclose additional information not related to the purpose of the information request simply because the authorisation model does not give them sufficient control. This is why the UK specs, for example, include four permissions related to transactions – ReadTransactionsBasic, ReadTransactionsDetail, ReadTransactionsCredits and ReadTransactionsDebits. The more detailed approach adopted by the UK is the right balance between customer eccentricity and unnecessary data leakage.

2. The link between the status of the credentials could be problematic. Status of a customer’s retail or business banking account could be:

• Expired (no login for x days)
• Mandatory change password (after assisted channel reset)
• Self-locked (too many incorrect passwords)
• Temporarily locked (auto re-enable after x hours)
• De-authorised (allow read-only due to suspicious activity until step-up authentication)
• Fraud blocked (due to suspicious activity/investigation)

How will these map to the open banking access?

Will the customer have to fix their banking channel access before they can continue to use open banking channels? Attempting to synchronise credential status between banking and open banking channels will create a complicated model for banks to support and for customers to understand. Proposal would be to treat any of these error conditions as a trigger to drop the open banking token. The customer then must re-delegate access using the oAuth process. This introduces customer friction if the customer locks their account but greatly simplifies servicing and maintains a high level of security.

[Wil-C]

Disclaimer: These are my personal opinions. Official responses via COBA.

• Agree with comments from NAB, ANZ and CBA, authentication (validating the customer) is different to authorisation (data to be accessed). Just because the customer provided authentication they might only wanted to share a subset of their information.

• The proposal reference “existing credentials”. I would like to clarify this refer to existing authentication mechanism. For example if a bank uses 2 factor authentication this should be respected. It is not recommended to purely just use account name and password – many of these have been compromised in security breaches in the past and this is not effective to protect personal information.

• While I support a more granular approach and allow the customer to select what to share, I do have concern this might overwhelm the less IT literate. For example, an elderly person might not be able to understand field level security. A suggestion is to provide a snapshot sample of what information will be shared prior to finalise the authorisation.

• Authorisation consent is only for the authorised ADI only. This does not constitute forwarding to a subsequent third party or fourth party without additional consent from the customer.

• This proposal should be explored further in the Infosec working group. While everyone agree this is important, we may want to do deep dive in the specialised security group.

• Regarding indefinite authorisation, I agree with comments above that this is a big risk area. This needs to be treated carefully otherwise will erode truts. If this is to be defined, I would recommend that indefinite authorisation will require explicit consent (instead of expiry) and should not be the enable by default.

• I also agree that we need some guidance on the data after authorisation is revoked. In the Data61 Use Case working group, several of us raised the concept of “right to be forgotten” in Europe GPDR which we should consider.

[JamesMBligh]

Some fantastic, in depth feedback here. I will try to summarise my thoughts as follows:

ACCC Rules Now that the ACCC rules framework has begun to be shared it appears that many of the issues raised in the feedback will actually be constrained by the ACCC rules when they are finalised. As such feedback should be directed to the ACCC first and then the standard will adapt accordingly.

This overlap would include:

• How accounts with no current digital access will be accommodated. Initially it would be assumed that the CDR regime will force the establishment of digital access for this accounts but that would be up to the ACCC.
• The concept of data sharing being a separate consent type to the ability to view an account.
• Time based authorisation. The ACCC rule framework has a current position on this topic which is fairly clear.
• The ability for a customer to directly access the APIs for their own data. The support (or not) of this paradigm is within the scope of the rules.

I will therefore refrain from taking a position on these things and will instead provide my own feedback to the ACCC. I will also bring this feedback thread to the attention of the ACCC as it contains valuable insights.

The rules framework does leave a lot of the specifics to the standards, including benchmarks, so I will comment on the topics that I believe fit within the auspices of the standards.

Existing Digital Channel The intent with this position is, in effect, a non-functional requirement. The APIs should be accessed using existing digital credentials. If none exist then new credentials will be needed (pending ACCC scope clarity) but these new credentials should then be used for any other digital channels that are subsequently created. The purpose of this position is to reduce both the friction for customer adoption but also to ensure that there is a mechanism using known credentials for a customer to view and manage the authorisations they have provided.

Basic Vs Detail This is a good addition and I will add it in. Comments around preventing collisions is noted. This is in effect an ongoing design principle so the community will need to be on the watch for this as the end points are defined. As a general principle I would propose that while multiple scopes may be needed for an end point to be accessed no end point should respond with a partial payload in the absence of a scope. The scopes should either allow or preclude access to the full capability of an end point. This will simplify usage, implementation and customer understanding.

Account Lock Out The status of a user credential is only relevant during the process of authorisation or when a customer wishes to manage authorisation. In between these use cases the status of the credential is irrelevant to the authorisation and should not be a reason to change the status of the authorisation in any way. That said, evidence of breach or credential takeover would be justification to lock down all access to the customers digital access. The handling of this would be left to the data provider.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document. Decision 005 - Authorisation Granlularity.pdf

-JB-