Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products #486
Comments
|
@Adatree thanks for raising this change request. This topic was discussed in the last Maintenance Iteration 10 session. We'd like to handle this as two pieces of work.
During MI 10 we can plan resolution of these pieces of work. |
|
The DSB proposes a mechanism to give additional control to the data recipient, describing how the industry path parameter applies to filtering authorisation scopes.
Banking and Energy are the only categories that align to industry; therefore, filtering needs to apply to only industry-specific scopes. The examples below assume all authorisation scopes for a particular category are assigned to the software product where the SSA is being retrieved. Authorisation scopes in the SSA will then apply as follows:
This functionality will allow for the following:
Therefore, to have the most meaningful impact, a future dated obligation aligned to the Energy rollout of 15th November 2022 is recommended |
|
The ACCC has not been given enough time to review the above proposed change, noting that it was posted around 3 hours before the MI call. Our understanding of the Maintenance cycle is that we are now outside of the 4 week consultation phase and as such should not be introducing new scope. The proposed change also does not seem to address the original issue and as such points to needing additional time to assess the use cases. At this time we are unable to consider additional scope for the 15th of November timeline. |
|
Hi @CDR-API-Stream. Thanks for your work on this.
Can we ever see this changing? With Open Finance the assumption would be that some data holder brands will be banks and superannuation companies and will participate in the banking and finance industries, but not all industries. Correct me if I've misunderstood, but doesn't the above proposed solution only support an SSA that is suitable for one industry, or all industries, but not a subset of industries which is likely the norm? |
This feedback may indicate a misunderstanding of the maintenance process. The process is deliberately agile in nature and we seek to be adaptive to the needs of the community as much as possible. In this case the issue is related to others already in scope and has, in effect, been raised due to other work already in the iteration. The fact that a solution was proposed 3 hours before the MI call is not an indication that a decision will be rushed. Any issue in the maintenance process may result in any of the following outcomes:
In this case, the last two outcomes are both possibilities if it ends up being contentious.
This is a serious matter, but we can't actually action this feedback as we need to know why the proposed solution doesn't address the issue. It is not obvious that this is the case and more detail would help. Also, feedback indicating how the solution could be amended so that it does address the issue would be very valuable.
This is helpful feedback on implementation considerations. The reason for stating the 15th of November is due to the fact that this is the date that this will become an issue for participants. If capacity is a problem then guidance on a solution that can be provided would be helpful. In any case, if this issue is to be resolved at some time after the 15th of November continued consultation on the best solution would still need to occur. |
There is an obvious gap in the understanding of the transitional friction when the Energy sector enters the CDR and lack of insight on the impacts to use cases where a data recipient seeks to create a new registration, or update a current registration, with a data holder brand. |
|
@Adatree, thanks for your continued input on this issue. This proposed solution only caters to single industries and all industries, not sub-sets. This is a known limitation and has been discussed in Maintenance Iteration 10. |
|
Discussions in MI 11 have highlighted the following:
Therefore, the following questions remain. Is this functionality still required in the energy go-live timeframe? What are the future requirements for data recipients specifying authorisation scopes? |
|
Isn't the quick solve here for the Register to use the optional By way of example:
This way a Data Recipient can use their normal SSA retrieval mechanisms and if that doesn't work out specifically request an old SSA and try that with a Data Holder? Seems to me the work effort required from the ACCC would be minimal and would get out things out of a bind from #507. Edit: In fact the ACCC's own mock register seems to have this exact functionality so maybe V2 SSA retirement date is just extended? Going forward the versioning mechanism could be used to add additional scopes but at least the sector introduction is relatively rare (ie. plenty of time for Holders). |
|
@perlboy thanks for your input. I'd like to adjust your example.
the optional Implementing ACCC, Is there significant difference in implementation effort to explicitly specify the authorisation scopes per API version vs implementing the industry path parameter filter? |
|
The ACCC’s preference is to implement filtering of scopes via the API versions (i.e. the solution described in the above comment). The ACCC requests that the following be specified in the Consumer Data Standards:
The Standards have not historically defined the behaviour of GetSSA with respect to scopes. The Register has returned all valid scopes at all material times. The very specific issue that arises here is providing the community with a workaround to suboptimal data holder behaviour with respect to unknown scopes. This behaviour is being addressed by a Standards change (see #507 and #488). What is therefore under discussion here is a workaround for a specific issue (additional scopes in an SSA causing certain data holders to throw errors) intended to apply for a limited time. The impugned data holder behaviour will become non-compliant and this workaround will be redundant once this issue is addressed. Lastly, while x-v interpretation and the best mechanism to facilitate scope filtering have been discussed in the above comments it would be ideal to treat these as separate issues. While valid, they are extraneous to the matter at hand and the problem as described in @Adatree's change request:
|
|
Thanks all for your input. Based on the feedback provided by the @ACCC-CDR and @perlboy, the DSB proposes the following ProposalThe authorisation scopes returned in V1 and V2 of the Get Software Statement Assertion (GetSSA) endpoint will be explicitly defined as follows:
V1 & V2 of the GetSSA endpoint have the authorisation scopes specified and will NOT include authorisation scopes from the energy sector. This aligns to current behaviour and allows data recipients to retrieve SSAs without energy scopes if required V3 of the GetSSA endpoint, sector-specific authorisation scopes will not be specified as all authorisation scopes will be returned. Therefore, for the 15th November release of the Energy sector, the authorisation scopes to be returned from the GetSSA endpoint will be the following:
|
|
Changes have been staged at: ConsumerDataStandardsAustralia/standards-staging#203 |
|
This doesn't appear to outline what the default behaviour of the non-mandatory |
|
A default value of 1 is in the OAS but you are correct, we should have an explicit statement somewhere outlining this |
Description
A common ADR use case may be personalised comparisons of products. This use case could span all supported industries in CDR. There are many comparison sites that exist today which help consumers find a better deal across a range of industries. In our view this would constitute a single software product for an ADR.
If the SSA for this product contains both banking and energy scopes then the energy scopes will not be in the list of supported scopes that is advertised via a banking data holder's authorization server metadata. It is expected that banking data holders will reject DCR attempts from ADRs whose software products contain unsupported energy scopes. Conversely we expect energy data holders to reject any SSA that contains banking scopes as they will not be advertised as supported.
Area Affected
Register APIs - Get Software Statement Assertion (SSA)
Change Proposed
Allow ADRs to specify the list of optional scopes they wish the SSA to contain through a
scopesquery parameter on the SSA endpoint. This will allow ADRs to tailor the SSA to match the supported scopes of data holders within an industry while allowing software products to span industries. This should also have no impact to data holder implementations. We would ask that this be considered a potentially urgent change.The text was updated successfully, but these errors were encountered: