Request for Clarification existing_refresh_toke conflicting standard and decision 85

[commbankoss]

Request For Clarification

Description

• The Standard and the original decision (85 link) proposal are conflicting. Commonwealth Bank is concerned that the CDR Standard version 1.2.0 of the security profile can be misinterpreted by other eco-system participants for July implementation.

Area Affected

Current spec says: MUST support an additional claim in the authorisation request object named existing_refresh_token that the data recipient may optionally include with the value set to the active refresh token for an existing consent.

• Until November 2020 data holders are not required to take any action if existing_refresh_token is supplied but MUST NOT respond with an error.

• Until November 2020 data recipients MUST NOT implement scenarios that support concurrent consent. Only single, extant consent scenarios should be implemented until this date.

Change Proposed

A detailed description of the specific change (or options for change) proposed. The more specific the proposal the easier

To avoid confusion about existing_refresh_token claim in July 2020 version of the standards, Commonwealth Bank recommends to:

• Remove existing_refresh_token claim from the specification

• Clarify that ADRs must not use existing_refresh_token claim

• Clarify that ADHs must not use existing_refresh_token claim

• Update the decision 85 PDF content to reflect this approach (Decision Proposal 85 - Concurrent Consents standards#85)

• Address future requirements (November 2020+) in a separate discussion (Decision Proposal 099 - Concurrent Consent Target State standards#99)

[CDR-API-Stream]

@commbankoss with the updates to concurrent consent in v1.3.0 can you please confirm that this query is resolved or no longer applicable?

[CDR-API-Stream]

This issue has been answered and it is being closed accordingly.