search

ConsumerDataStandardsAustralia / standards

Work space for data standards development in Australia under the Consumer Data Right regime
Other
321 stars 56 forks source link

Decision Proposal 79 - July Draft Feedback Cycle 1 #79

Closed CDR-API-Stream closed 5 years ago

CDR-API-Stream commented 5 years ago

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

deboraelkin2 commented 5 years ago

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

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

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

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

Please clarify whether it is mandatory or not.

deboraelkin2 commented 5 years ago

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

perlboy commented 5 years ago

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

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

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

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

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

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

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

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

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

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

Finally, repeating my previous comment:

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

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

tpk1971 commented 5 years ago

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

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

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

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

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

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

versent1Jas commented 5 years ago

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

perlboy commented 5 years ago

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

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

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

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

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

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

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

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

Closed Ecosystem

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

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

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

Are Product APIs outside the scope of this report?

Consent and Broad Access to Information

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

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

Independent Assessment

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

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

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

anzbankau commented 5 years ago

Metadata update

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

Scheduled payments 'to account name'

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

In this case the target account name is not available

Transaction detail error handling

Following up on this comment - https://github.com/ConsumerDataStandardsAustralia/standards/issues/67#issuecomment-496791313 - we would like to understand the expected behaviour when a consumer invokes transaction details where the transaction detail flag has been set to false.

Transaction detail NPP specific

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

fahadbinrahat commented 5 years ago

Question # 1:-

Please clarify if this understanding is correct:-

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

Question # 2:-

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

API Request:-

Given:-

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

Provided:-

Holder’s highest implemented version is 1.2

API Response API responds with x-v: 2

anzbankau commented 5 years ago

Payee end point scope

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

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

Financial Institution for credit card direct debits

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

ID Permanence rules

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

spikejump commented 5 years ago

Few clarifications are sought below.

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

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

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

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

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

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

ghost commented 5 years ago

I think @perlboy raises some really good challenges the the path OB is taking. I am not sure the regulator will have a view and be so prescriptive on it though...they tend to accept a model as long as it can be demonstrated that a "process" has been followed, i.e. controls/ security assurances are in place.

Definitely the liabilities around who wears a loss IF (repeat IF) the model becomes so flawed that it falls over and breaches privacy on a mass scale. No real value added here apart from in the security team and developers we trust!

perlboy commented 5 years ago

@spikejump

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

I had missed this and it would appear the author of the Standard does not understand the separation between iss and client_id. These statements are directly contradictory:

The Request Object is a signed and encoded JWT specified in section 6.1 of [OIDC]. As per [FAPI-RW] section 5.2.2, the request parameter MUST be present on requests to the [OIDC] Hybrid Authorisation End Point. The Request Object enables [OIDC] requests to be passed in a single and self-contained parameter.

The iss claim SHALL NOT be supported as it duplicates the role of the client_id claim.

Specifically on this iss is specified as follows:

REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

iss IS NOT a duplicate of client_id but instead is a unique identifier for the issuer which may or may not be the same as the client_id. In addition iss has specific verification requirements depending on whether the token is self issued .

As previously highlighted it would appear the CDS authors do not understand the OIDC suite and/or have decided to deliberately modify international standards for reasons unknown.

@hillite

I think @perlboy raises some really good challenges the the path OB is taking. I am not sure the regulator will have a view and be so prescriptive on it though...they tend to accept a model as long as it can be demonstrated that a "process" has been followed, i.e. controls/ security assurances are in place.

I agree, compliance is rarely as prescriptive. What they are likely to request is a risk based approach to analysing software risks. These typically rely on industry certifications as an "easy" solution. Fundamentally the focus in my response was seeking to establish if, due to the direct modification of international standards, the Australian government intended to establish an alternate certification body as the increasingly rampant modification of standards is going to leave them with no other choice.

CDR-API-Stream commented 5 years ago

After the release of 0.9.5 we held back on interacting on GitHub as the dust settled with a view to giving the community time to digest the latest changes. The DSB will now be re-engaging and will respond to the comments provided to date.

Note that, where comments are considered defects or can be resolved by uplifting documentation and descriptions we will attempt to address them directly.

Comments that warrant meaningful changes to the standard will be added to the back log for review and prioritisation according to the new operating model we have been working through internally.

CDR-API-Stream commented 5 years ago

In response to @deboraelkin2

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

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

which seems to indicate it is optional. ... Please clarify whether it is mandatory or not.

This header was intended to be optional as per the description. It was made mandatory in error. The behaviour should, in fact align with the FAPI profile which states that the holder:

- shall set the response header x-fapi-interaction-id to the value received from the corresponding fapi client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a; and
- shall log the value of x-fapi-interaction-id in the log entry.

Refer to FAPI documentation here

To rectify this the request header will be made optional and the response header will be made mandatory and the description will be aligned to FAPI requirements.

CDR-API-Stream commented 5 years ago

In response to @deboraelkin2

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

These are conditional (as opposed to mandatory) but you are correct that they should be included in the swagger. This is being worked on.

CDR-API-Stream commented 5 years ago

In response to @perlboy et. al. on the topic of consent

The DSB strongly disagrees that the standards have diverged from international standards as described. In specific reference to the use of a request object, this is included in the standards at: https://consumerdatastandardsaustralia.github.io/standards/#request-object

The decision to defer the adoption of a specific solution for more fine-grained authorisation is explained in the decision document on decision #77. As articulated in that decision the choice is to defer adopting a specific solution until further CX research has been conducted to better understand the real needs of the Australian consumers that will be engaging with the regime.

Implementation guidance was also provided in this decision as to how fine-grained authorisation may be implemented in the future to allow data holders design support for these future patterns at the outset. The lodging intent pattern proposed in FAPI is aligned with one of these patterns.

CDR-API-Stream commented 5 years ago

In response to @tpk1971

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

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

The standards do not make reference to the historic extent of data to be made available. The ACCC have indicated that these stipulations will be contained in a future version of the CDR Rules.

In the absence of guidance in the rules or standards the designation instrument specifies the earliest holding date as being 1 January 2017 (which is the earliest date allowed by the proposed CDR legislation). This implies that data for transactions made on, or after, 1 January 2017 should available under the bank:transactions:read scope.

CDR-API-Stream commented 5 years ago

In response to @versent1Jas

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

Data holders may deny the data consumption requests from a data recipient. It is up to their discretion if they choose not to in certain circumstances (for instance, assuming the latest version if x-v is absent). The provision of request headers is an obligation on the data recipient not the data holder.

That said, it is expected that data holders will likely deny malformed requests and data recipients should certainly expect them to do so.

CDR-API-Stream commented 5 years ago

In response to @perlboy

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

Questions are welcome and this is the intended thread for them to be asked. Responses to specific questions are below...

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

Yes "OIDC" refers to Open ID Connect. The standard defines OIDC Core as a normative reference using the link: http://openid.net/specs/openid-connect-core-1_0.html

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

Some clarifications:

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

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

The implied question here is to how the scope for the review was defined on this point. To clarify, there was no expectation for the review that existing and widely adopted standards should be reviewed. Only the use and modification of such standards by CDR was to be considered. It was not the intent of the review to do a full risk analysis of FAPI or OIDC as standalone standards.

Are Product APIs outside the scope of this report?

All aspects of the CDR standards published in the May draft were considered in scope for the review. This included the Product APIs.

Consent and Broad Access to Information

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

The history of this recommendation is as stated. The original review included a recommendation that customers should be allowed to select the accounts to be included for sharing. This was not referred to one or way or the other in the standard but the DSB explained to Fortian that this was expected to be left to the competitive space and included in the CX guidelines that had not yet been published. In light of this the recommendation was changed and the fact that a change had been made was transparently stated. There is not perceived to be an ongoing risk.

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

The CDB is a missed typo of DSB (referring to Data Standards Body).

Fortian was selected due to their experience and expertise in financial services and specifically in the protocols that the CDR is based upon.

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

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

The DSB did not seek to influence and did not contribute to review beyond providing explanations and clarifications of the standards and the CDR ecosystem when requested. Fortian understood the need for the review to be independent and acted accordingly in undertaking their review.

The fact that a clarification that changed an original recommendation was clearly and transparently stated, including the original recommendation and the reason for the change, is evidence of the independent nature of the review.

CDR-API-Stream commented 5 years ago

In response to @anzbankau

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

The metadata end points are no longer part of the CDR standard as they will not be implemented by either data recipients or data holders (only the register will implement these end points).

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

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

In this case the target account name is not available

If the point is that this data may not be known then it is unclear why this is the case. The name of an account that is the target of an internal transfer should be known to the data holder.

If the point is that data about the account has not be included in the scope and should not be transferred as a result then this is an overly zealous application of the application of account inclusion. If the scope allowing for scheduled payments to be included has been authorised then this is understood to include minimal identification information about the destination accounts.

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

The expected behaviour should be that the data requested does not exist and an error should be returned indicating this. The HTTP Response Code should be 422 Unprocessable Entity.

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

Transaction detail is currently NPP specific (hence the structure) but is not necessarily expected to always be NPP specific. Other regimes may result in rich data being added to transactions. The detail payload is designed to allow for these to be accommodated in the future as needed.

CDR-API-Stream commented 5 years ago

In response to @fahadbinrahat

Question # 1:-

Please clarify if this understanding is correct:-

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

No. The version supplied in x-v (which is a single integer) indicates the independent version of the end point (i.e. v1, v2, v3, etc). This is entirely independent of the semantic versioning of the standards as a whole.

It is envisioned that the end points will version at different velocities. It is entirely possible that the Get Product Details end point may be up to version 8 while the Get Payees end point is still at version 1.

It is also envisioned that, at any point in time, multiple versions of the same end point may be included in the standard to allow for changeover in the ecosystem.

Question # 2:-

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

API Request:-

Given:-

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

Provided:-

Holder’s highest implemented version is 1.2

API Response API responds with x-v: 2

Yes. That is the expected behaviour.

CDR-API-Stream commented 5 years ago

In response to @anzbankau

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

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

Yes. This is defect. Thanks

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

This is a case that has not previously been raised but, yes, it is reasonable that the financial institution would not be known if the direct debit was handled by a scheme. This is a defect with the current standard and will be updated accordingly.

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

  • That 'data consumers' refers to the Software product client ID IDs MUST be immutable across sessions but MUST NOT be transferable across data consumers. For example, data consumer A obtaining an account ID would get a different result from data consumer B obtaining the ID for the same account even if the same customer authorised the access. Under this constraint IDs cannot be usefully transferred between client organisations or providers.
  • That 'customers' refers to the customer's digital identity in the data holder. IDs MUST NOT be transferable between different customers for the same data consumer. For example, a data consumer should obtain a different ID for a joint account if the ID was obtained independently using authorisations from both customers.

This interpretation is correct. In summary:

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

Examples and implementation guidance is under consideration for being created. No ETA to provide as yet.

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

This is potentially a material change to the standard and the implications of either option would need to be understood before a change is made. Further comment on this issue would be welcome from all contributors (as well as from @spikejump, of course).

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

As per RFC 2119 MUST NOT and SHALL NOT are synonymous. Happy to consider this change if it causes problems. Perhaps this would be a good candidate for the back log for consideration.

In relation to @perlboy 's additional comments on this topic, this part of the profile has remained unchanged and uncommented on since the Christmas draft and has not yet been considered by the current authors. Your faith in our, admittedly limited and humble, capability is encouraging, however.

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

As noted, examples and implementation guidelines are under consideration.

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

The intention for the separation of these values is to facilitate refresh_token cycling which was requested by data holders.

If refresh token cycling is not being used then the two expiry times will be the same.

If refresh token cycling is being used then the expiry of the refresh token will be less than the expiry of the sharing date but a new refresh token (with an extended expiry) should be provided when an access token is requested to establish a session.

CDR-API-Stream commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

The specification of digits only and min/max length are considerations for customer experience. Beyond these limitations any algorithm can be used to create the token. This statement is included to allow the freedom for holders to actively select a pseudo random algorithm that matches their risk profile.

perlboy commented 5 years ago

In the first response to the modifications of international standards the following was stated:

The DSB strongly disagrees that the standards have diverged from international standards as described.

Less than one hour later with regards to what parts of the OIDC Suite have been adopted the following was stated:

Some clarifications:

  • Core is adopted with some modifications (including some modifications implied by FAPI R/W)
  • Discovery is adopted with some modification (specifically, not all fields defined as required in the discovery standard are considered required for CDR)
  • Dynamic Client Registration is not adopted
  • Other statements are accurate

The question is simple, are international standards being modified within the CDS?

NationalAustraliaBank commented 5 years ago

The CDS CX Guidelines v0.9.5 (17 July 2019) calls out the following consents and permissions captured by the Data Recipient during the Consent stage of the Consent Flow:

  1. [Guideline 2.10.1, 2.10.2] The data recipient should allow the consumer to specify the sharing duration, including how far back in time data will be accessed.
  2. [Guideline 2.11.1, 2.11.3] The data recipient must outline how often data is expected to be collected over that period.

NAB's interpretation of 2.11.1 and 2.11.3 is that this refers to when the Data Recipient's service is explicitly used by the consumer (attended traffic) or periodically (unattended traffic). The CX examples appears to support this interpretation.

And related to the above, in the Authorise stage of the Consent Flow, Data Holders are required to disclose information on the data sharing authorisation, including:

  1. [Guideline 4.4.1, 4.4.3] The data holder must state the sharing duration to the consumer, including how far back in time data will be accessed.
  2. [Guideline 4.4.2, 4.4.4] The data holder must state how often the data will be disclosed over the specific period.

How will the CDS API and Security profile support these CX requirements? The decision made for Consent https://github.com/ConsumerDataStandardsAustralia/standards/issues/77 and the participant metadata from the CDR Register (v0.3.0) does not support the CDS CX mandatory and recommended guidelines.

In addition to the above, the following consents and permissions are captured by the Data Recipient during the Consent stage of the Consent Flow:

  1. [Guideline 2.12.1] Explicit consumer consent to allow the Data Recipient to de-identify CDR data during the sharing period.
  2. [Guideline 2.8.1, 2.8.2, 2.11.2, 2.11.4] If data is being requested for multiple uses, the consumer must be able to specify which uses they consent to.

Can Data Holders get visibility of this additional consent and permission relating to:

  1. De-identification of CDR data during the sharing period; and
  2. The specific uses that the CDR data can be used for?

This would enable Data Holders to inform consumers of the consent provided to the Data Recipient to be displayed as part of the Confirmation sub-stage of the Authorise stage. It would also enhance Data Holder's ability to determine a customer's risk profile use to keep their customer's safe.

All of this would fall into the Staged Intent Pattern, which was defined as one of the future patterns identified in https://github.com/ConsumerDataStandardsAustralia/standards/issues/77. NAB would like to understand the plan to realise this pattern in order to meet the CX requirements, including considerations towards of data sharing consent that might have been established under v0.9.5 of the CDS API and Security profile.

fahadbinrahat commented 5 years ago

Thanks for above clarifications...

"The provider should respond with the highest supported version between x-min-v and x-v."

if x-min-v=2 and x-v=1, given highest supported version is 1, will x-v=1 (being in between) be expected response?

spikejump commented 5 years ago

In response to @spikejump (with separate issues responded to separately)

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

The intention for the separation of these values is to facilitate refresh_token cycling which was requested by data holders.

If refresh token cycling is not being used then the two expiry times will be the same.

If refresh token cycling is being used then the expiry of the refresh token will be less than the expiry of the sharing date but a new refresh token (with an extended expiry) should be provided when an access token is requested to establish a session.

Just following up on the above response...

Perhaps the standard should mandate if refresh token cycling is implemented then a new refresh token with an extended expiry MUST be provided when a new access token is requested. This will ensure users will not unnecessarily go through the full re-authorisation process.

spikejump commented 5 years ago

Seems like an authorisation scope is missing for direct-debit? e.g. bank:direct_debit:read

Does it make sense to provide a mapping table of API endpoints to the scopes that's required?

CDR-API-Stream commented 5 years ago

In response to @NationalAustraliaBank :

The feedback provided is related to the CX guidelines which is being managed by a separate feedback channel. The reason for a separate channel is to support non-technical stakeholders that may be less comfortable using GitHub for their responses.

We would appreciate it if you could provide your feedback via the CX feedback form at: https://consumerdatastandards.org.au/workinggroups/consumer-experience/consultations-cx-workstream/consultation-draft-1/

If the result of any feedback to the CX stream results in a proposal for change to the standards (which is possible) this proposal will be brought back here for discussion.

CDR-API-Stream commented 5 years ago

In response to @fahadbinrahat

It is expected that the value of x-min-v is always less than x-v and there was some treatment for that in the original decision that seems to have been mislaid on the path to documenting the standards.

This is a documentation defect. The description of the headers will be updated accordingly.

spikejump commented 5 years ago

A bit confused following the above question and response on the topic of x-v and x-min-v.

The data holder may support, as an example, 1.0, 1.1, 1.2 and 2.0 of the Get Accounts standard. For the recipients,

Is this correct?

perlboy commented 5 years ago

@spikejump

Perhaps the standard should mandate if refresh token cycling is implemented then a new refresh token with an extended expiry MUST be provided when a new access token is requested. This will ensure users will not unnecessarily go through the full re-authorisation process.

I see a challenge with indicating it's ok to cycle it but then not defining how to. This will mean that every data holder could have a different API and the recipient is potentially left trying to figure out how to get the consent agreement back.

Specifically on automatically extending consent, there's grounds for this but I'd ask whether this should be a specifically recorded action (ie. the audit log). x-fapi-correlation-id is usable although could be challenging to rely on it entirely when it comes to Dashboard implementation particularly when it comes to showing "Affirmative action" on a consent agreement (ie. user initiated extension). There is typically a difference between "system actions" and "user actions".....

spikejump commented 5 years ago

Specifically on automatically extending consent, there's grounds for this but I'd ask whether this should be a specifically recorded action (ie. the audit log). x-fapi-correlation-id is usable although could be challenging to rely on it entirely when it comes to Dashboard implementation particularly when it comes to showing "Affirmative action" on a consent agreement (ie. user initiated extension). There is typically a difference between "system actions" and "user actions".....

@perlboy, this is not about extending consent. In fact, the sharing_duration will remain as is - for however long the consent duration was. The only thing that's being refreshed is the Refresh token. It needs to be refreshed otherwise Recipient can't get hold of the data the customers consented to earlier and have to be forced to re-authorise/consent all over again. The audit log should not be touched as it is a technical refresh.

This is no different than using a valid Refresh token to get a new Access Token. Assuming no audit log is required for each new Access token received.

perlboy commented 5 years ago

@perlboy, this is not about extending consent. In fact, the sharing_duration will remain as is - for however long the consent duration was. The only thing that's being refreshed is the Refresh token. It needs to be refreshed otherwise Recipient can't get hold of the data the customers consented to earlier and have to be forced to re-authorise/consent all over again. The audit log should not be touched as it is a technical refresh.

@spikejump And the error state of this? If the Refresh token Refresh fails then the Consent agreement has been orphaned then the user either has an incorrect view of consents OR holders prematurely terminate the agreement. Both seem undesirable and yet if you are Refreshing the Refresh it's because the token state has reached expiration (or is going to soon presumably)...

Additionally, if it's the first time the agreement has been used in 90 days (to refresh access) it's eligible to trigger the "Ongoing notification" requirement in 4.14 & 4.20 (https://www.accc.gov.au/system/files/Exposure%20draft%20CDR%20rules%2029%20March%202019.pdf).

There's also grounds to say that the recipient should be proving "ongoing" use and potentially lose access to the consent if not utilised. I wonder if it's expected this is the Data Holder's job, to perform analytics to determine "ongoing use" and what the formula for "success" on this criteria? Does this extend to terminating "dead" data sharing agreements as part of data minimisation?

This is no different than using a valid Refresh token to get a new Access Token. Assuming no audit log is required for each new Access token received.

Technically I understand except this is Refresh getting Refresh token which is neither standardised nor documented. Also special reference to RFC6749 10.4: The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.

Refresh the Refresh seems to violate this.

spikejump commented 5 years ago

@perlboy Agree that when Refresh token failed to get refreshed then customers need to be notified and consent audit logged.

If refresh of a Refresh token is required to be logged in audit trail for consent visibility (ignoring the use case of system activity tracking) then this can be excessive and costly. For one thing, Recipients now need to compare the returned Refresh token to what it already has. If different then log in consent audit trail for Refreshing a refresh token. If this requirement is not there then any returned Refresh token can simply be stored for next usage. In addition, depending on Recipient use cases the Access token may be requested on a daily basis or even as soon as it expired. Each time a new Refresh token may be returned. Doubt if any user would love to see this kind of refresh being flagged nor if this is the original intent of a consent audit trail.

IMHO nothing wrong with refresh of a Refresh token. It is Data Holders prerogative. They just need to ensure Customers' consent duration are being upheld while doing so and not subject customers to a pre-mature re-authorisation/consent process.

fahadbinrahat commented 5 years ago

x-fapi-customer-ip-address and x-cds-User-Agent

Above header inputs are conditionally mandatory. I think its only DR that can/should implement these validations....

Can only think of one validation DH can have for above, that is if one is supplied the other becomes mandatory (and non-null and format check etc.)..

Is DH required to implement any validations other than above too?

Can/Should DH discover customer present/not present context and reject the call if these headers are not supplied?

CDR-API-Stream commented 5 years ago

In response to @perlboy and @spikejump

The mechanism for refresh cycling is standard OAuth 2 as described in RFC 6749 (see the last paragraph of RFC 6749 Section 6 for instance).

The intent of the standard is that a sharing arrangement is not unnecessarily impinged by the implementation of Refresh token cycling. If there is concern regarding this then clarification can be provided (such as the clarification suggested by @spikejump above). This was not previously considered necessary as Data Recipients are able to obtain new Access tokens (and thereby trigger a Refresh token cycle) at will.

CDR-API-Stream commented 5 years ago

In response to @spikejump

A bit confused following the above question and response on the topic of x-v and x-min-v.

The data holder may support, as an example, 1.0, 1.1, 1.2 and 2.0 of the Get Accounts standard. For the recipients,

  • request x-v: 1 for 1.0 (with the base URI point to /cds-au/v1)
  • request x-v: 2 for 1.1 (with the base URI point to /cds-au/v1)
  • request x-v: 3 for 1.2 (with the base URI point to /cds-au/v1)
  • request x-v: 1 for 2.0 (with the base URI point to /cds-au/v2)

Is this correct?

Yes, although the overall standards are using semantic versioning (i.e. 0.9.5 rather than 1.1, 1.2, etc).

The principle you have articulated is, however, correct - including how major versions will be handled.

commbankoss commented 5 years ago

Commonwealth Bank would like to support @spikejump's comment. We agree to change the Standard to accommodate as it makes sense to remove the recurrence.

In response to @spikejump (with separate issues responded to separately)

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

This is potentially a material change to the standard and the implications of either option would need to be understood before a change is made. Further comment on this issue would be welcome from all contributors (as well as from @spikejump, of course).

spikejump commented 5 years ago

In the spec there is a section that discusses the 'sub' claim. Based on the OIDC definition, 'sub' is a locally unique and never reassigned identifier within the Data Holder for the End-User - the customer.

The spec mentions

the identifier SHOULD also be unique relative to the scenario in which the end-user has authenticated. For example, the identifier generated for the same person when they are using a business account SHOULD be different to the identifier that is generated when that same individual is authorising as an individual

In the context of a person authorised for the business, and the business holds multiple business accounts with a Data Holder. Is it correct to say this 'sub' value will never change across different consents for the business for the same account (at different times) or for different accounts?

To use an example, customer C1, holds business accounts B1 and B2. C1 provides consent on 1/2/2020 for B1 for 30 days. C1 then provides consent on 1/4/2020 for B1 again for 30 days. C1 provides consent on 15/4/2020 for B2 for 30 days. In all three consents the 'sub' being returned from Data Holder MUST be the same.

Is this correct? If so, can the spec be enhanced with this clarification?

perlboy commented 5 years ago

In the context of a person authorised for the business, and the business holds multiple business accounts with a Data Holder. Is it correct to say this 'sub' value will never change across different consents for the business for the same account (at different times) or for different accounts?

@spikejump there's relevant note in another subsection around Claim Stability. In non-modified OIDC-C the unique pairwise identifier is sub+iss because sub is locally unique.

The current CDS proposes the removal of iss which impacts the guaranteed uniqueness when considered in the context of a single customer federated across multiple services (per brand, per product etc). More to come on this soon but thought it timely to comment now.

spikejump commented 5 years ago

@perlboy Appreciate the comment. While uniqueness is critical, the earlier request for clarification was to highlight another critical aspect of this and that is the consistency of the 'sub' to identify the customer across consents and accounts. Without such consistency, Data Recipients will struggle to match the customer (to previous connection for example) and his/her data consistently.

perlboy commented 5 years ago

@perlboy Appreciate the comment. While uniqueness is critical, the earlier request for clarification was to highlight another critical aspect of this and that is the consistency of the 'sub' to identify the customer across consents and accounts. Without such consistency, Data Recipients will struggle to match the customer (to previous connection for example) and his/her data consistently.

My understanding of OIDC-C and I believe the intent of the CDS was that tracing of end user customers between individual consents is specifically NOT meant to be possible. From the previous claim stability link OIDC-C states that the sub is never reused, that is to say once all attempts to use an access and/or refresh token are exhausted it should never reappear:

"...since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User..."

I believe the intention is, in the absence of a Consent API that facilitates modification of existing consents, that Recipients will maintain a 1:M mapping of recipient product customer and consents. Since account identifiers are intended to be unique as well I acknowledge that this will make creating overlapping consents difficult (cause one token's accounts list will be different to the other despite potentially describing the same accounts). My interpretation of a use case illustrating the workflow for this would be something like:

1) Customer C1 signs up for recipient product 2) C1 consents and establishes sharing agreement S1 to data from account A1 and A2 with list balances & basic transactions 3) C1 uses recipient product and then "upgrades" 4) C1 consents and establishes sharing agreement S2 to data from account A1 and A2 with list balances, basic and detailed tx 5) Recipient "migrates" data from S1 to S2 (or wipes S1 entirely and reprocesses under S2) probably using "fuzzy" matching of attributes because the account id will be dynamically generated 6) Recipient cancels S1 by issuing a token revocation request 7) Recipient proceeds to use S2

This seems like it could be very messy for complex use cases. I guess recipients will be more inclined to request wholesale access to everything to alleviate the likely customer experience challenges....

spikejump commented 5 years ago

Scope seems to be missing for Discovery APIs (status and outages)? or are these public APIs?

WestpacOpenBanking commented 5 years ago

HTTP Headers and non-functional requirements

With respect to non-functional requirements an API request is “Customer Present” if and only if x-fapi-customer-ip-address is populated with a valid IP address of the end customer’s device. The HTTP Headers definition of x-fapi-customer-ip-address says that this header is not required for unattended or unauthenticated calls. We suggest that phases like ‘Not required for unauthenticated calls’ are replaced with phases like ‘Not to be included for unauthenticated calls’ in the HTTP Headers section. This will make it possible for us to be sure when a call is unattended and to be able to report accurately in relation to the non-functional requirements.

User agent headers as distinct from the user agent header

We suggest that x-cds-User-Agent is represented with a base64 encoding that will allow for inclusion of client browser headers other than the user agent string. This aligns with the recommendation of the Fortian Review.

Transaction search

Decision A07 in the May draft consultation response indicated that the transaction search query parameter will be made optional for implementation. This has been reflected in the Get Transactions For Account endpoint definition but the recommended approach if not implemented (return data as if the parameter was not provided) lacks transparency for data consumers. We suggest recommending the inclusion of an error object with a suggested set of parameters.

Get Metrics

How your data will be shared

Version 0.9.5 of the CX guidelines state as a Mandatory requirement that ‘The data holder must state how often the data will be disclosed over the specific period’ for on-going data sharing. The example given is “Your data will be shared everytime you use [ADR]’s service for the next 12 months, until 3 July 2020.”. There is not currently a way for this information to be sent from recipients to holders as part of the consent process or otherwise.

Clarification of currentDay and previousDay

Decision A11 in the May draft consultation response indicated that the definitions of currentDay and previousDay be clarified, but their definitions do not appear to have been updated.

Versioning

We believe that the versioning strategy needs further clarification and reiterate our previous comment on this issue as it was not responded to. We also look forward to further information regarding the standards release strategy.

IsPreferred

isPreferred as used in CommonPhoneNumber, CommonEmailAddress, CommonPhysicalAddress are now optional fields to cater for the case where a preference isn’t known, but the descriptions are still written as if the fields are conditional.

jwks_uri mandatory in [OIDD]

The OpenID provider configuration endpoint references the OpenID Connect Discovery standard [OIDD]. That standard states that a jwks_uri is REQUIRED and should be a JSON Web Key Set document containing signing keys and possibly server encryption keys. The remainder of the security profile appears to be written as though no such endpoint is to exist. Regardless of the outcome of discussion with the ACCC with regard to the hosting of key information the standards will need to be adjusted.