Request For Clarification

Some discussion regarding signing algorithms occurred in tonight FAPI WG call.

There isn't an explicit list of signing algorithms specified within the Standards I assume because they are inherited from FAPI RW as PS256 and ES256? This is also repeated in the non-normative examples for discovery payloads within the Standards.

Within the UK OBIE however the certificate authority only issues RSA and therefore in reality only PS256 are available.

Is it known whether the ACCC CA will be issuing EC certificates or will it be exclusively RSA? More simply is ES256 support mandatory for Data Recipients to implement?

Thanks in advance.

Request For Clarification

There are a number of steps in the Hybrid flow which is initiated at the data recipient. At which point in this flow should a customer be considered to have granted consent (triggering consequent update of consent dashboards)?

Options for consideration include:

1. After the customer has pressed the authorise button and the authorisation has been successfully recorded in the data holder’s systems.
2. At the point where the customer is redirected back to the data recipient from the data holder following a successful authorisation.
3. At the point where the data recipient claims the access token from the token endpoint.
4. Data holder discretion.

Description

The ANZSIC 2006 industryCode field in the standards is specified as a string but is actually a 2-4 digit zero padded number.

Area Affected

CommonOrganisation

Change Proposed

a) Create a string field format for ANZSIC numbers similar to MaskedPANString
b) Change to a PositiveInteger on the basis of maintaining a consistent approach to zero padded values as previously communicated for thoroughfareNumber1 and thoroughfareNumber2

Description

The information security profile limits client authentication of protected infosec end points to the use of the authorisation_code and client_credentials values for grant_type but the value refresh_token is required for access token refresh. This issue has been highlighted during the February implementation issue tracking meetings.

Area Affected

The Client Authentication section of the Information Security profile

Change Proposed

Add support for the refresh_token value for grant_type when calling the token end point.

This section in Data61 spec specifies that ID tokens must be encrypted. However, the algorithm for encryption has not been defined. OIDC spec allows following to be used for encryption as specified here.
Can the algorithm be specified for assistance in implementation of encryption of ID tokens.

This request for clarification has been transferred from the main standards site. Contents of the request, posted by @bmangalaganesh, are below:

Hi,

The specs define Customer Present as follows - Authenticated API requests made in direct response to interactions by the end customer using the digital services of the data recipient will be considered “Customer Present”.

The expected response times for customer present requests are significantly shorter than the unattended requests ( 1 or 1.5 seconds vs 4 seconds).

What is the mechanism/procedures that are kept in place to prevent misuse of customer present requests by ADRs?

In other words, the Data Holder when they receive any request with x-fapi-customer-ip-address header info present is expected to provider a faster response (while they do not truly know if there is a customer at the other end of the ADR/TPP app)

Description

In BankingAccountDetail at most one lendingRate can be associated with an account. There are cases where the relationship between lending rates and an account is many-to-one. For example a credit card may have different rates associated with lending for purchases, cash advances and balance transfers. See also #9.

Area Affected

Definition of BankingAccountDetail which is used in:

• Get Account Detail

Change Proposed

We suggest that the lendingRate description is updated to specify that for credit cards the lending rate is the purchase rate. Thought may also be given to allowing the representation of all lending rates for an account (e.g. an additionalLendingRates field). Alternatively the lendingRate field may already allow this. Although we are not yet aware of any examples, similar issues might apply to depositRates and it may make sense to make similar additions or changes in relation to deposit rates.

Description

International payees can have BSB and account number, be known to be international and may or may not have other information as required by the BankInternationalPayee schema. In this case the BSB and account number effectively act as an alias and a third party acts as a proxy to transfer funds to the payee.

Area Affected

The following names and definitions are affected:

• BankInternationalPayee and BankDomesticPayee
• toUType in BankingScheduledPaymentTo
• type in BankingPayee
• payeeUType in BankingPayeeDetail

These objects are used in:

• Get Payees
• Get Payee Detail
• Get Scheduled Payments for Account
• Get Scheduled Payments Bulk
• Get Scheduled Payments For Specific Accounts

Change Proposed

An optional domesticAccount field is added to BankingInternationalPayee with type BankingDomesticPayeeAccount. This approach avoids breaking changes.

Description

The Fortian security review recommended the adoption of JARM. The DSB agreed that this should be investigated.

Area Affected

The information security profile.

Change Proposed

Adopt the JARM standard into the information security profile.

The description of this standards is as follows:

This document defines a new JWT-based mode to encode authorization responses parameters. All response parameters defined for a given response type are conveyed in a JWT along with additional fields used to further protect the transmission. Since there are different techniques to encode the JWT itself in the response to the client, namely query URI parameter, fragment component and form post, this draft defines a set of response mode values in accordance with [OIDM] corresponding to this techniques.

Description

The Fortian security review recommended that detached signatures be included in the information security profile to provide recipient certainty of the data provided. The DSB agreed to investigate this change.

Area Affected

The information security profile.

Change Proposed

Resource API responses will include a header containing a detached signature that signs the contents of the response payload.

The Standards indicate that the expiry of the currently active refresh token ends a sharing arrangement. However, there is a provision in the standards to cycle refresh tokens, which indicates that the 'currently active' refresh token could be made inactive and the sharing arrangement would still continue.

Suggest rewording the first statement to clarify:

The revocation or expiration of the currently active refresh token should be understood to effectively revoke or expire the sharing arrangement as a whole.

Content-Type is currently listed as a mandatory request header. We recommend that it is only mandatory for verbs where there is a body (most commonly PUT and POST) and optional for the verbs where there is no body. It should not be mandatory to send a request type as the content may not be present in all scenarios.

Request For Clarification

Hi,
Is the value for the x-cds-subject header the same as that of the "sub" claim of the ID-Token?

The Standards have a list of URIs in Resource URIs that have a backslash instead of slash in the URI.

i.e. GET …\accounts instead of GET …/accounts.

Request For Clarification

Within Tokens the Access Token definition states the following:

An Access Token MUST expire between 2 minutes to 10 minutes after the Data Holder issues it (at the discretion of the Data Holder).

Within the Refresh Token definition it states:

Refresh Token expiration MAY be any length of time greater than 28 days but MUST NOT exceed the end of the duration of sharing consented to by the Consumer. Data Holders MAY cycle Refresh Tokens when an Access Token is issued. If Refresh Token cycling is not performed then the Refresh Token MUST NOT expire before the expiration of the sharing consented by the Customer.

Does this mean that if the Data Holder supports Refresh Token cycling they can issue a new and singular Refresh Token (deactivating the previous one), potentially, every 2 minutes?

If not, option 2, does it mean that there can be multiple active Refresh Token's who's lifetime must be >28 days from issuance?

If not option 3, does it mean that a new refresh token should only be cycled if it is older than >28 days?

Further, how does such a scenario impact this final statement which references a singular refresh token?

The revocation or expiration of the currently active refresh token should be understood to effectively revoke or expire the sharing arrangement as a whole.

If there are multiple refresh token's issued how does one decide when to terminate the sharing arrangement?

If there is a singular refresh token issued and active but then rotated the last part of this sentence seems confusing.

Thanks in advance.

Request For Clarification

"High Traffic Period" is defined as:

Any time in the 18 hour period between 6am and 12am (midnight) is considered to be a high traffic period

In which timezone is this specified?

• UTC (normal for computer specifications)
• Timezone of the server
• Timezone of the server owner's headquarters
• Timezone of the customer
• Timezone of the data recipient

If not UTC, then what should occur on the days before/after daylight savings?

The description for metadata API as defined says:

Indicate that a critical update to the metadata for Accredited Data Recipients has been made and should be obtained

However, https://cdr-register.github.io/register/#cache-refresh-metadata-request says

Data Holders and Accredited Data Recipients will be required to implement the Admin endpoint

Assuming the Register spec is correct in that both DH and DR are required implement the metadata API?

Thanks.

Description

The FAPI read profile, in section 6.2.1 encourages the use of CORS for resource end points that are anticipated to be made available for javascript clients

Area Affected

The security profile, specifically unauthenticated resource APIs but potentially also the authenticated resource APIs

Change Proposed

Adopt the requirement that holders allow CORS (ie. Access-Control-Allow-Origin: *) for resource end points.

Description

Defining ‘breaking change’ explicitly and allowing for non-breaking changes to be incorporated without incrementing endpoint versions will support Principle 4: APIs provide a good developer experience by:

• Informing developers of coding practises which are best suited to support for newer versions with minimal effort.
• Avoiding potential eco-system churn as legacy versions are depreciated.
• Reducing the burden created by a need to maintain code for many endpoint versions within a code base.

Area Affected

• Principle 4: APIs provide a good developer experience
• Principle 11: APIs are version controlled and backwards compatible
• Versioning

Change Proposed

• New section under Versioning defining the meaning of breaking and non-breaking changes within the standards. Suggested wording to the effect of:
  • The following are non-breaking changes:
    • Addition of a new endpoint
    • Addition of a new optional request parameter (query, body or header)
      • Note: Servers must ignore request parameters that they do not understand.
    • Addition of a new response header, field or entity, where the meanings of existing headers, fields and entities are not changed.
      • Note: Clients should ignore response headers, fields or entities that they do not understand.
    • Addition of a new error code , where the meaning of existing error code and HTTP status codes have NOT changed.
      • Note: Clients should catch-all behaviour for unrecognised 4xx and 5xx series HTTP status codes
    • Change of a mandatory request parameter (query, body or header) to optional or conditional.
    • Addition of new enumerated values for existing fields, where the meanings of existing enumerated values are not changed.
      • Note: Clients should ignore enumerated values that they do not understand.
  • The following are breaking changes:
    • A new mandatory request parameter (query, body or header)
    • Addition of a new HTTP status code that does not meet the criteria for introduction in a non-breaking way.
    • Removal or change of field or entity data types or object types in request or response
    • Removal or change of existing enumerated values in request or response
    • Removal or rename of existing endpoint URIs
    • Removal or changed meaning of existing response HTTP status codes.
    • Removal or changed meaning of existing error codes, messages or descriptions
    • Change of HTTP verb (e.g. GET to POST)
• Version part <bug fix> is renamed to <non breaking>. Description is updated to say “Changes which are non-breaking.” With a cross reference to a definition as in the previous point.

Description

The description of amount in BankingScheduledPaymentSet is clearly incorrect, duplicating the description of isAmountCalculated.

Area Affected

Definition of BankingScheduledPaymentSet which is used in:

• Get Scheduled Payments for Account
• Get Scheduled Payments Bulk
• Get Scheduled Payments For Specific Accounts

Change Proposed

The description should be updated to reflect the Decision 051 – Scheduled Payments:

“The amount of the next payment if known. Mandatory unless the isAmountCalculated field is set to true. Must be zero or positive if present.”

Request For Clarification

As the original issue for this #34 has been hard closed it appears creating a new ticket is the only method. Cross posting my #34 comments:

Not sure why this has been closed after 7 days. Given responses from this Stream are measured in the order of weeks this closure seems premature.

If a refresh token is provided but not received (or lost in some other way) then the sharing arrangement is still in place as far as the holder is concerned but no more requests can effectively be made and the arrangement can not be revoked. In this case authorisation will need to be requested again.

So there will be dangling consents which may need termination when authorisation is requested again? Is that to say the intended behaviour is that a new sharing request will automatically overwrite any existing one? Is this documented in the Standards somewhere?

While the CDR standards define expiration constraints on OAuth tokens the meaning and operation of these tokens are defined by the underlying standards and protocols. The case described above would be able to be handled only to the extent that the mechanisms of these standards and protocols allow.

The difference is that the OAuth standard does not deal with sharing agreements as this is overlaid within ACDS. It also doesn't make explicit statements with respect to retired tokens and immediate termination. That is to say that in the event of a communication failure a relying party can simply issue a new refresh token with the previous token, possibly within some sort of trailing validity period.

Within ACDS refreshing of tokens explicitly and immediately terminates previous ones AND irreversibly updates the association to the sharing agreement.

Description

In BankingDomesticPayeeAccount, the field accountName is mandatory. There are many cases where we do not have a payee name or a name entered by a customer whilst scheduling a payment.

Area Affected

Definition of BankingDomesticPayeeAccount which is used in:

• Get Payees
• Get Payee Detail
• Get Scheduled Payments for Account
• Get Scheduled Payments Bulk
• Get Scheduled Payments For Specific Accounts

Change Proposed

We propose that accountName is changed from mandatory to optional.

Description

The current draft says this about x-cds-User-Agent:

The customer's original standard http headers Base64 encoded, including the original User Agent header

I presume this isn't what's intended, as it would require the data recipient to send the 'Cookie' header that the customer used to access the data recipient. Access to that cookie header would likely let the data holder impersonate the customer and access the data recipient's service, exposing various PII included that received from other data holders, which is not something the data holder should have the ability to do.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/#http-headers

Change Proposed

Change to simply 'The customer's original User Agent header'. (I don't see any clear reason why base64 encoding would be required or helpful.)

Description

Some sentences still remain in relation to vectors of trust in parts of the Infosec profile, including links to a Vectors of Trust section which no longer exists within the standard. Standard still references expired draft on Vectors of Trust in normative references.

Area Affected

• Overview section
• ID Token section and example
• Claims section
• OpenID Provider Configuration End Point
• Normative references section

Change Proposed

Remove remnant references to vectors of trust in the security profile.

Description

As per subject it seems relevant to prepare for the likely implementation of ISO 20022 transaction details. Based on reports the RBA is set to make a decision on implementation in early 2020 but, today, had a comment published which stated with relation to adoption: “The expansion and addition of information fields can help to facilitate payment tracking and verification, which can assist in the mitigation of fraud and other financial crimes, [....] The use of highly structured ISO 20022 fields also supports greater automation of a number of compliance activities (eg: Anti-Money Laundering/Counter-Terrorism Financing [AML/CTF] monitoring and sanctions screening).”

Development of these definitions was raised, by me, 15 July 2019:

It was first suggested by a representative from SWIFT on 23 Nov 2018:

Quoting kennethleungswift:
To supplement on my colleague @DDobbing 's feedback above, from SWIFT’s perspective, we highly recommend the consideration of using ISO20022 message elements and components where applicable.

Area Affected

BankingTransactionDetail but possibly more if seeking to consistently align.

Change Proposed

Introduce metadata definitions required to support ISO 20022 payment scheme.

Description

Amend the PRD payloads to incorporate the ability to represent tiered fees

Area Affected

Payloads of Product Detail and Account Detail

Change Proposed

The following is the detail previously posted by CBA in the main standards repo in this comment:
ConsumerDataStandardsAustralia/standards#79 (comment)

Problem Space – Tiered Fees

Commonwealth Bank want to represent fees accurately via the Open Banking specification. However the specification is restrictive for fees that leverage tiering and/or varying fee amounts (percentage or amount).

Example One - Credit Card Cash Advance Fee

Description: This fee is charged for cash advances obtained: Over the counter at CommBank branches or other Australian financial institutions. $3.00 or 3.00% of the transaction amount - whichever is greater. Capped at a maximum fee of $300.00
The credit card cash advance fee should be represented like the table below:

Transaction Value Fee Amount Fee Percentage
<$100 $3.00 -
Between $100 and $9,999 - 3%

$10,000 | $300 | -

However we are representing it like below:

{
                "name": "Cash advance fee",
                "feeType": "WITHDRAWAL",
                "transactionRate": "0.03",
                "currency": "AUD",
                "additionalValue": "3.00",
                "additionalInfo": "This fee is charged for cash advances obtained: Over the counter at CommBank branches or other Australian financial institutions. $3.00 or 3.00% of the transaction amount - whichever is greater. Capped at a maximum fee of $300.00 (or $3 if your closing balance was in credit the previous business day). We’re unable to block cash advance transactions that aren’t sent to us for authorisation. These will attract interest from the date the transaction is made until it’s repaid."
}

Example Two – Corporate Charge Card Annual Fee
Description: 1-49 cards $40.00 per card, 50-499 cards $32.00 per card, 500+ cards $24.00 per card
The Annual Fee should be represented like the table below:

Annual Fee Card Count
$40 1-49
$32 40-499
$24 500+
However we are representing it like below:

{
                "name": "Annual fee",
                "feeType": "PERIODIC",
                "amount": "40.00",
                "currency": "AUD",
                "additionalValue": "P1Y",
                "additionalInfo": "1-49 cards $40.00 per card"
            },
            {
                "name": "Annual fee",
                "feeType": "PERIODIC",
                "amount": "32.00",
                "currency": "AUD",
                "additionalValue": "P1Y",
                "additionalInfo": "50-499 cards $32.00 per card"
            },
            {
                "name": "Annual fee",
                "feeType": "PERIODIC",
                "amount": "24.00",
                "currency": "AUD",
                "additionalValue": "P1Y",
                "additionalInfo": "500+ cards $24.00 per card"
            }

We have many examples where pricing is a mix of percentage or amount depending on the size of the transaction. Additionally we have fee where a counter number of transactions are free, then multiple levels of pricing apply depending on the quantity.

Recommendation

We recommend that tiering gets added to the open banking specification to support the above use cases.

BankingProductFeeTier Definition

Name Type Required Restrictions Description
name string mandatory none A display name for the tier
unitOfMeasure string mandatory none The unit of measure that applies to the tierValueMinimum and tierValueMaximum values e.g. 'DOLLAR', 'PERCENT', ‘TRANSACTION_COUNT’
minimumValue number mandatory none The number of tierUnitOfMeasure units that form the lower bound of the tier. The tier should be inclusive of this value
maximumValue number optional none The number of tierUnitOfMeasure units that form the upper bound of the tier or band. For a tier with a discrete value (as opposed to a range of values e.g. 1 month) this must be the same as tierValueMinimum. Where this is the same as the tierValueMinimum value of the next-higher tier the referenced tier should be exclusive of this value. For example a term deposit of 2 months falls into the upper tier of the following tiers: (1 – 2 months, 2 – 3 months). If absent the tier's range has no upper bound.
rateApplicationMethod string optional none The method used to calculate the amount to be applied using one or more tiers. A single rate may be applied to the entire balance or each applicable tier rate is applied to the portion of the balance that falls into that tier (referred to as 'bands' or 'steps')
applicabilityConditions   optional none Defines a condition for the applicability of a tiered rate
Then we could model our pricing more accurately.
Example one modelled in the new world…..

     {
                "name": "Cash advance fee",
                "feeType": "WITHDRAWAL",
                "amount": "3.00",
                "currency": "AUD",
                "tiers": [
		{
"name": "Cash advance fee tier",
"unitOfMeasure": "DOLLAR",
"minimumValue": "0.00",
"maximumValue": "100.00",

         }	
        ]},

{
                "name": "Cash advance fee",
                "feeType": "WITHDRAWAL",
                "transactionRate": "0.03",
                "currency": "AUD",
                "tiers": [
		{
"name": "Cash advance fee tier",
"unitOfMeasure": "DOLLAR",
"minimumValue": "100.01",
"maximumValue": "9999.99"
         }	
        ]},
{
                "name": "Cash advance fee",
                "feeType": "WITHDRAWAL",
                "amount": "300.00",
                "currency": "AUD",
                "tiers": [
		{
"name": "Cash advance fee tier",
"unitOfMeasure": "DOLLAR",
"minimumValue": "10000.00"
         }	
        ]}

Description

The relationship between BPAY fields and transactions is many to one. In particular a single transaction may be recorded for each day where there are BPAY payments with funds deducted.

Area Affected

Definition of BankingTransaction which is used by:

• Get Transactions For Account
• Get Transaction Detail

Change Proposed

We propose an approach that avoids breaking changes to endpoint definitions:

1. An optional bpay list is added within extendedData in BankingTransactionDetail. Each element of this list would contain billerCode, billerName and crn. This list would contain all BPAY payees.
2. The elements billerCode, billerName and crn in BankingTransaction should only be populated if there is a single BPAY payee and not be populated if there are 0 or greater than 1 payees.

Description

During the May consultation the submission from FinTech Australia identified a series of data gaps that they have requested be added to the standards. A decision by the DSB was provided in response to the May submission. The fields that were then decided not to be included are now being raised for wider consultation.

Area Affected

This change affects the payloads of the existing Banking end points.

Change Proposed

The following requested data has not been included in the standards:

• Account holder date of birth
• Default status for customer (including details of the default, such as product, date of default, principal amount, outstanding amount with fees and interest)
• Guarantors linked to particular products
• Whether mortgages are for owner occupied or investment property
• Details of relevant security property or other secured assets (including type of security, valuation)
• Application details (including date of applications, products applied for, current status)

Description

Arising from feedback in the main standards repository it was requested that a single account be able to support an array of Term Deposit balances, maturity dates, etc.

Area Affected

Account and Balance end points

Change Proposed

The change requested is specific at this comment:
ConsumerDataStandardsAustralia/standards#79 (comment)

The request is quoted below:

Term Deposits in the Get Account Detail Api.
As a non-technical resource, not sure if this is the appropriate section to raise this query relating to Get Account details on behalf of our API developers.

With the way the Consumer Data Standard is representing Term Deposits in the Get Account Detail Api.

We have the situation where there can be a many-to-one relationship between deposits and deposit accounts. Ie multiple deposits can be represented in a single account, each of these deposits could have different lodgement dates, maturity dates, maturity instructions and maturity amount.

The CDS structure for BankingAccountDetail only allows for 1 term deposit (https://consumerdatastandardsaustralia.github.io/standards/?javascript#tocSresponsebankingaccountbyid).

For us to fully describe a deposit account as requested, we would need the termDepost property of BankingAccount to be an array of BankingTermDepositAccount. Is this planned or possible?

Commonwealth Bank would like to reference this issue as an outstanding problem space. Data61 can we please receive an indication on when you will provide feedback on this issue involving the registry?

As discussed in #13 the x-cds-subject header:

1. Serves no useful purpose as it is not included in unattended calls, so the iDP cannot rely on it's presence to perform lookups (meaning all the information has to be accessible via the access token, and if the information is available via the access token there's no gain from including it in a header)

2. Serves no useful purpose as it is defined as replaying information the iDP already has (i.e. the sub from the id_token the idp issued), and hence cannot be a useful input into fraud detection

Hence I'd strongly recommend removing it. It's a significant deviation from the underlying specs, and has the potential to introduce new flaws and hence Australia would not be benefiting from the significant amount of formal security analysis that has already been done on OAuth2, OpenID Connect and FAPI specifications.

This is particularly there doesn't seem to be any valid documented reason for diverging from the standards and introducing extra work for data recipients to do - the clear model in OAuth2 is that the access token is the method to communicate from the OAuth client to the resource server, and that is how other ecosystems do it. There is no reason I can see to add this extra element.

Request For Clarification

The August version of the ACCC rules have a new requirement under: Part 1, Division 1.4, Subdivision 1.4.3, Section 1.15, (3)(g).

This new rule requires the data holder dashboard to inform consumers if a disclosure was re-disclosed because the consumer requested it to be re-disclosed due to a previous disclosure having incorrect data. The technical standards do not seem to have any mechanism to allow for this.

Will this need to be catered for in the technical standards?

As loan products come into scope the ability to represent this attribute will enhance the machine readability of the schema. This information can currently only be represented in the additionalValue or additionalInfo. These fields are currently mixed-use for marketing, pricing and other information, driving complexity up for the Data Recipients and increasing the chances of miscommunication and customer impacts.

In the account detail there is an existing option to include this in the enumerated values. We recommend mirroring this design for the BankingProductLendingRate property by adding the repaymentType as an optional field.

Area Affected

BankingProductLendingRate

Change Proposed

Commonwealth Bank recommends the inclusion of repaymentType in the Product Detail API.

Description

The submission from Visa restated previous feedback that digital card art information should be included in the standards to enable card-centric experiences.

Area Affected

This change affects the banking API end points and payloads. Specifically, Account Details may be impacted although it is possible that an alternative end point could address this issue.

Change Proposed

The submission from Visa stated as follows:

• Recommend adding option for Card Art support
• URL for Card Art
• Card Art Height/Width size in pixel fields

Description

Currently, the Data Holder Metadata Management takes place using periodic polling and Metadata AdminAPI call from the CDR registry for immediate updates.

The concern is scalability, Hypothetically with a large number of ADRs on-boarded with the CDR registry, the DH will have to query the complete ADR statuses through the Registry API.

The proposal is to make the APIs more granular allowing query of individual ADRs for metadata updating.

Area Affected

• CDR Registry GET /{industry}/data-recipients/brands/software-products/status
• CDR Registry GET /{industry}/data-recipients/status
• CDS AdminAPI POST ​/admin​/register​/metadata

Change Proposed

• CDR Registry GET /{industry}/data-recipients/brands/software-products/status
  • Pagination (in the case of the number of software products are unsendable in one payload)
  • Allow retrieving the status of a single software product using the softwareProductId using a query parameter or path parameter.
• CDR Registry GET /{industry}/data-recipients/status
  • Pagination (in the case of the number of ADRs are unsendable in one payload)
  • Allow retrieving the status of a single software product using the dataRecipientId using
• CDS AdminAPI POST ​/admin​/register​/metadata
  • Send the softwareProductId or dataRecipientId allowing invalidation of a singular software product/ data recipient.

This proposal will allow DHs to do JIT(Just In Time) provisioning of metadata instead of periodically having to completely retrieve the whole metadata list from the CDR registry.

Description

Currently the standards only support 1 version of ANZSIC codes.

Area Affected

The customer API

Change Proposed

Commonwealth Bank recommends adding support for multiple versions of the ANZSIC code. Data holders will be using a variety of code version and potentially not supporting the 2006 revisions.

Greetings all,

Upon looking at the OpenAPI Schema given for the CDS v1 API it shows that the current error model ResponseErrorList_errors only support a single error type.

It is for the 422 Unprocessable entity exceptions of the POST calls in the API, this is further justified with the description Must be one of the following: 0001 – Account not able to be found.

Any considerations for introducing different error codes for HTTP bad request, Internal Server Error, etc?
With this, we are able to give textual descriptions in case of a missing attribute bad request as an example.

If only a single type of code is allowed why not make the OpenAPI schema code attribute an enumeration?

In the case of a GET request to /banking/accounts/{accountId} with an invalid accountID can the same 0001 – Account not able to be found be used as a response?

Cheers,

Request For Clarification

The Tokens section of the information security profile specifies that ID tokens must be encrypted. However the type of encryption (symmetric or asymmetric) and choice encryption algorithm has not been defined. Please specify which encryption type should be used from the available options in the OIDC Core normative reference and outline the mechanism of key exchange for this encryption method.

Additionally, we have these questions:

1. What are the algorithms that data holders and recipients must support for ID token encryption? (i.e. which asymmetric or symmetric algorithms)
2. How will the encryption algorithms be exchanged between parties and configured?
   1. Statically by referencing appropriate algorithms and encodings in the standards
   2. Dynamically by requesting ACCC add id_token_encrypted_response_alg and, optionally, id_token_encrypted_response_enc to the dynamic client registration request jwt.

Westpac recommends asymmetric ID token encryption where the mechanism for key exchange is as per OIDC Core. That is, the data holder will reference the authorised data recipient’s JWKS endpoint and select an encryption public key for an algorithm it supports.

Notwithstanding the above, we also query as to if the encryption requirement for ID tokens should be removed entirely from the standard? Given, the complexity of the above, the fact this issue has not yet been dealt with in the standards and the fact that no PII is exchanged in the ID token (refer to this issue), this appears a viable option.

As per Data 61, the ID token should not contain any personally Identifiable data. Is this statement still valid when the DR passes profile scope in the authorisation request(grant consent), could you please confirm that claims(firstname, lastname, name and updated_at) are NOT required to be returned ID token and will ONLY be available via userInfo endpoint for any scope (openId or profile) passed in the request.

Description

Revision of how lastWeekDay is expressed in the Scheduled Payments payloads.

Area Affected

The payloads for the Scheduled Payments end points.

Change Proposed

This issue is raised in response to a feedback comment in the main standards repository, ConsumerDataStandardsAustralia/standards#73 (comment)

This feedback is quoted below:

Further, BankingScheduledPaymentRecurrenceLastWeekday and BankingScheduledPaymentInterval appear to have similar purposes but use different data types (Duration vs. Integer) when specifying a day of week.
This variation is deliberate. The interval in BankingScheduledPaymentInterval can potentially be many days so the ability to represent this interval in terms on years, months or days is more appropriate. As lastWeekDay is constrained to days in the week an integer was seen as more applicable than using a duration field and limiting the value to exclude the majority of the duration syntax.

If lastWeekDay is intended to be a day of week then the least confusing method would be to declare and reuse a DayOfWeek enumeration which strongly orders the days of week in line with ISO-8601.

Regarding dayInInterval in BankingScheduledPaymentInterval, is this intended to be an arbitrary number of days for the interval period? Ie. If BankingScheduledPaymentInterval represents a monthly payment but the payment is to be conducted on the 5th day of every month interval=P1M and dayInInterval=5 ?

ISO-8601 allows for bounded durations specified using a / separator. Additionally the standard allows for recurring time intervals to be specified using a prefix of R/#. Are these variations intended to be supported?

Finally, the BankingScheduledPayment* namespaces appear to have shared attribues in sub objects (eg. paymentsRemaining) rather than following an attribute structure similar to Product info's use of additionalValue and additionalInfo.
The preference in this case is to be strongly typed rather than use the more generic model used in product reference data. These objects may initially be similar but, as they represent different conceptual objects, they may diverge over time. As such dedicated structures for each interval type have been defined.

As per above ISO-8601 allows for bounded timespans and repetition. Since this is facilitated in ISO-8601 BankingScheduledPaymentRecurrenceOnceOff, BankingScheduledPaymentRecurrenceLastWeekday and BankingScheduledPaymentRecurrenceIntervalSchedule all appear to be able to be represented in a single unified object.

Nonetheless, specifically on BankingScheduledPaymentRecurrenceOnceOff there doesn't appear to be a facilitation for nonBusinessDayTreatment. On BankingScheduledPaymentRecurrenceIntervalSchedule the finalPaymentDate could be derived from a bounded ISO-8601 Duration. On BankingScheduledPaymentRecurrenceLastWeekdaythere doesn't appear to be a facilitation for nonBusinessDayTreatment (ie. when the weekday is set to Monday and it's a public holiday).

The uType convention provides reference to a JSON field. In most cases this is an object but it is not necessarily always the case. In this case it is referencing only a single field but was included because it is expected that new types will be added in the future as new NPP overlay services become available.

My feedback has been misunderstood. There is a high probability that there will be additional transaction details that are divergent. In the current proposal extendedData and, on further review BankingTransaction effectively contains all possible payment attributes which inevitably will lead to a sparsely populated and poorly structured object. This means that a developer will need to perform picklist matching to determine the acquisition channel rather than be able to determine that acquisition channel via a strongly typed subobject.

On BankingTransaction, overloading of the base object is occurring rather than using the uType convention followed elsewhere. Specifically of note is that BPAY payments (a trademarked and commercially attached payment provider) have been granted exclusivity over generically named attributes notably billerCode, billerName and crn. This precludes an alternate payments provider using these global attributes and arguably provides a commercial advantage to the incumbent. Additionally reference described as The reference for the transaction provided by the originating institution. Empty string if no data provided appears to be overloaded as it may be used by various origination sources.

BankingTransactionDetail does not appear to sufficiently allow for attributes of even existing payment types such as:

• BPay: BPAY reference id
• Traditional payments: BSB, Account Number etc
• International payments: Routing codes, payment instructions, intermediaries etc.
• NPP: Currently only pain.a09.001.01 exists but it is likely this sub-object itself would need an NPPuType
• Internal Transfers: Source/Destination account (probably using the UUID of the Accounts in question)
• ISO20022 Payments: Current consultation is being conducted by the RBA for mandatory adoption

As can be seen through the collapsing of these structures there is an increasing amount of fuzziness for a recipient developer attempting to clearly identify and present transaction information. Such different views are a regular use case within existing internet banking platforms. That is to say that BPAY transactions usually have a different presentation view than direct transfers which have a different presentation view to those which utilise card providers such as VISA or Mastercard.

Pseudo coding an alternate JSON structure for BankingTransaction:

    "BankingTransaction" : {
      "type" : "object",
      "required" : [ "accountId", "amount", "description", "isDetailAvailable", "reference", "status", "type" ],
      "properties" : {
        "accountId" : {
          "type" : "string",
          "description" : "ID of the account for which transactions are provided",
          "x-cds-type" : "ASCIIString"
        },
        "transactionId" : {
          "type" : "string",
          "description" : "A unique ID of the transaction adhering to the standards for ID permanence.  This is mandatory (through hashing if necessary) unless there are specific and justifiable technical reasons why a transaction cannot be uniquely identified for a particular account type",
          "x-cds-type" : "ASCIIString"
        },
        "isDetailAvailable" : {
          "type" : "boolean",
          "description" : "True if extended information is available using the transaction detail end point. False if extended data is not available",
          "x-cds-type" : "Boolean"
        },
        "holderType" : {
          "type" : "string",
          "description" : "The type of the transaction within the Holders sytems",
          "enum" : [ "FEE", "INTEREST_CHARGED", "INTEREST_PAID", "TRANSFER_OUTGOING", "TRANSFER_INCOMING", "PAYMENT", "DIRECT_DEBIT", "OTHER" ]
        },
        "status" : {
          "type" : "string",
          "description" : "Status of the transaction whether pending or posted. Note that there is currently no provision in the standards to guarantee the ability to correlate a pending transaction with an associated posted transaction",
          "enum" : [ "PENDING", "POSTED" ]
        },
        "description" : {
          "type" : "string",
          "description" : "The transaction description as applied by the financial institution"
        },
        "postingDateTime" : {
          "type" : "string",
          "description" : "The time the transaction was posted. This field is Mandatory if the transaction has status POSTED.  This is the time that appears on a standard statement",
          "x-cds-type" : "DateTimeString"
        },
        "valueDateTime" : {
          "type" : "string",
          "description" : "Date and time at which assets become available to the account owner in case of a credit entry, or cease to be available to the account owner in case of a debit transaction entry",
          "x-cds-type" : "DateTimeString"
        },
        "executionDateTime" : {
          "type" : "string",
          "description" : "The time the transaction was executed by the originating customer, if available",
          "x-cds-type" : "DateTimeString"
        },
        "amount" : {
          "type" : "string",
          "description" : "The value of the transaction. Negative values mean money was outgoing from the account",
          "x-cds-type" : "AmountString"
        },
        "currency" : {
          "type" : "string",
          "description" : "The currency for the transaction amount. AUD assumed if not present",
          "x-cds-type" : "CurrencyString"
        },
        "reference" : {
          "type" : "string",
          "description" : "The reference for the transaction provided by the originating institution.  Empty string if no data provided"
        },
        "transactionUType" : {
            "type" : "string",
            "description" : "Type of object included that describes the transaction, reused for TransactionDetail",
            "enum" : [ "BPAY", "PAYID", "WIRE", "DIRECT" ]
          },
          "BPAY" : {
            "$ref" : "#/definitions/BankingTransactionBPAY"
          },
          "PAYID" : {
            "$ref" : "#/definitions/BankingTransactionPayID"
          },
          "WIRE" : {
            "$ref" : "#/definitions/BankingTransactionWire"
          }
          "DIRECT" : {
            "$ref" : "#/definitions/BankingTransactionDirect"
          }
        },

    },

Pseudo coding a JSON structure for BankingTransactionDetail:

    "BankingTransactionDetail" : {
      "allOf" : [ {
        "$ref" : "#/definitions/BankingTransaction"
      }, {
        "type" : "object",
        "required" : [ "transactionUType" ],
        "properties" : {
          "BPAY" : {
            "$ref" : "#/definitions/BankingTransactionDetailBPAY"
          },
          "PAYID" : {
            "$ref" : "#/definitions/BankingTransactionDetailPayID"
          },
          "WIRE" : {
            "$ref" : "#/definitions/BankingTransactionDetailWire"
          }
          "DIRECT" : {
            "$ref" : "#/definitions/BankingTransactionDetailDirect"
          }
        },
        "x-conditional" : [ "WIRE", "BPAY", "WIRE", "DIRECT" ]
      } ]
    }

This structure allows BankingTransactionDetail* to extend the non detail version of the object while rewriting it within the detailed definition. Additionally this structure allows for non-standard payment types to be adopted by banks (for instance an Apple Pay integration) without polluting the namespace. Finally this structure makes transitioning to polymorphism available in OAI3 using the uType as the discriminator.

Thanks for the detailed review. Most of this is stylistic and will be incorporated.

Repeating one of the defined principles: Principle 4: APIs provide a good developer experience
Stylistic from the Standards perspective is object pollution for developers using available industry tools. I would suggest that perhaps Standards should consider running swagger-codegen on their specification as a matter of course.

The response code table will be updated as suggested.

Regarding @anzbankau's comment and your response regarding the return of 422 Unprocessable Entity for invalid pagination inputs. This is divergent from the UK OpenBanking specification which states that 400 Bad Request is to be used in the situation defined as Request has malformed, missing or non-compliant JSON body, URL parameters or header fields.. In fact error code 422, defined in HTTP 1.1+, is entirely missing from the UK Standards. Instead the UK Standards prefer a HTTP 1.0 400 Bad Request and this convention is utilised within Engineering artefacts (following clarification at the time with Standards). Is this position now changing?

Thanks.

Request For Clarification

The August version of the ACCC rules has a new requirement with an accompanying note under: Part 4, Division 4.4, Section 4.26, (1)(h).

The note explains that an authorisation to disclose particular CDR data to an accredited person expires when an accredited data recipient of CDR data becomes instead a data holder of that CDR data.

Does Data61 know what scenarios this rule relates to? Is this rule already catered for in the technical standards?

We are imagining that the accredited data recipient would just send a request to the Token Revocation Endpoint, but not be required to delete or anonymise the data they are holding for that token - as they are now a Data Holder for that data.

Description

The APCA Number in the standards is specified as a string but is described (and actually is) a zero padded 6 digit number.

Area Affected

Transaction and TransactionDetail

Change Proposed

a) Create a string field format for APCA numbers similar to MaskedPANString
b) Change to a PositiveInteger on the basis of maintaining a consistent approach to zero padded values as previously communicated for thoroughfareNumber1 and thoroughfareNumber2

Description

The submission from Visa to the May draft requested the inclusion of a Payment Account Reference field in the Transaction History payload.

Area Affected

Transaction History end points and payloads.

Change Proposed

The submission from Visa requested the following:

Include PAR (Payment Account References) in the detailed responses. While PAR is not a consumer-facing attribute, it is pertinent in instances where underlying parties serve loyalty/rewards programs or to assess risk/fraud in the absence of a card number.

Request For Clarification

Hey there. We are requesting clarification as to whether OAuth 2.0 Form Post Response Mode is an authorisation response mode that will be supported by Data Holders. At the moment, the response mode we can find mentioned in the standard is 'fragment' which is part of the non normative example in the endpoints section.

From this security article:
To aid the implementation of the best practice, we recommend that OPs consider supporting OAuth 2.0 Form Post Response Mode, as it makes it simpler for clients doing code id_token to get both the code and the ID Token on the backend for verification.

Thank you.

Request For Clarification

Scopes and Claims section here , mandates the inclusion of refresh_token_expires_at claim. It is unclear which token must include this claim. It is conflicting to include this in ID token as the OIDC spec here does mention inclusion of refresh token information in Id tokens.

Request For Clarification

Data Holders, Data Recipients and the Register must all host JWKS endpoints to allow for verification of public keys for a variety of purposes. Typically, these endpoints do not require mutually authenticated TLS. This approach allows distribution via a CDN and increased resiliency without security impact.

Currently, the transport security required for Data Recipient implementations is not specified. If intended, we would need to customise our security infrastructure to support TLS-MA instead of TLS. To align with standard approaches, and the approach used for the registry hosted JWKS endpoint we suggest that TLS without mutual authentication is the most pragmatic option for February.

We also query as to if the requirement for Data Holders to require TLS-MA for their JWKS endpoint was intended, and if so, the rationale for this approach.

Description

Currently the standards dictate that ADRs will need to expose the following with MTLS:

1. Token Revocation endpoint for consent withdrawal
2. Admin Endpoint for Metadata Update

These endpoints are also using Client Authentication as part of the resource request as opposed to utilising access tokens. Therefore, I'd like to get feedback on how MTLS contributes to the security profile given:

1. Holder of Key is not relevant in this scenario as there are no access tokens required
2. Client authentication is still occurring using the private_key_jwt method as defined in https://consumerdatastandardsaustralia.github.io/standards/#client-authentication so the caller can still be validated
3. TLS will still be in place, reducing likelihood of MITM attacks

Area Affected

Admin endpoint transport security for ADRs
Revocation Endpoint Definition for ADRs

Change Proposed

If there is no benefit of using MTLS in these usecases, the security requirements should be lifted.

We would like the community to comment on the relevance of this requirement to help determine the validity of the change proposed

Request For Clarification

The changes from 0.9.6 -> 1.0.0 seem to have been made in one or two large changes:

ConsumerDataStandardsAustralia/standards@f22d5d2
ConsumerDataStandardsAustralia/standards@5e3a8f8
(and possibly some other commits as well, the git history is a little hard to follow, I think there's possibly a "rebuild" process that's not yet been automated which makes it noisier?)

I can't find any description that covers why each change was made, any reasoning, security analysis, pro/cons, etc. Is this available please?

I understand that 1.0.0 is ready for vendors to implement, so can we assume that going forward each change to the standard will be made as a result of an issue in this issue tracker, with a pull request made linked to that issue and hence the final standard being traceable (via 'git blame') back to a description of the intention / rational / analysis etc? (I see there is mention of something like this on https://github.com/ConsumerDataStandardsAustralia/standards-maintenance but it's not clear, e.g. will the discussions on the teleconferences will be minuted back to the relevant issue on the issue tracker? will comments received via email to csiro or otherwise made off-github be added to the relevant GitHub issue if they are to be taken into account?).

I can't find the documentation on the detail of the process, is this available somewhere? I guess it will be something like a branch will be opened for containing the 'draft' for each potential new spec version, then pull requests will be raised to that branch for each issue, some time given for members to review the contents of the pull request, then the pull request merged to the branch and the draft branch merged to 'master' branch when the cycle for that release completes?

Or if a process like this the above is not being followed, what is the model for public (or at least vendor etc) scrutiny of each change to the standards prior to a new version being published, and how is all the information about rational etc recorded & made available incase a decision later needs to be reconsidered?