-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.13.0 Appears to have introduced new SSA error behaviours #484
Comments
I have referenced issue #443 as the impacts raised here overlap with the expectations set out in SSA change management. |
This issue has been flagged as a candidate for MI 11 |
Let’s talk to each concern individually:
The previous registration design articulated this requirement as:
The change in language was not intended to change the interpretation of the Standards. However, this concern raises the following question. Using the There are various reasons that a data holder may not have met their obligation. They may be late, the ACCC can provide exemptions. There is benefit in having flexibility in the process if obligation dates are not met. It’s also worth considering that if an older registration already exists but is not updated when there is the addition of the If a data holder is to return an error on receipt of a registration request with fields they do not support, the data recipient will have no opportunity to request consumer data. The benefit of this approach is that any consequences of the lack of support are less likely to occur.
Unsupported scopes are scopes that are defined in the Standards, but the data holder does not support them.
The merging of the Register design into the Consumer Data Standards never intended to alter the Register design. During the merge, the language was tightened up to follow the requirement-centric language of the Standards. This exercise was a significant piece of work and this issue you raise is an unintended consequence. As part of the maintenance iteration process, we have retrospectives to capture issues and opportunities for improvement. When the MI 11 retrospective occurs, we can raise this issue for discussion. |
Except pairwise identifiers would (should...) be different when the Holder does add
Within 206 Biza.io specifically requested a clarifying statement to be added to the Standards to explicitly state no technical change was intended. The DSB even went so far as to state:
And yet the additional statements were added without such consultation. Nothing in DP206 provided the DSB with a license to "tighten" language and yet it did it anyway. As per the first sentence of this ticket:
The Chair never actually approved the changes made as highlighted and now the consequences are playing out.
Feedback on this has been given numerous times. The DSB needs to walk the walk rather than twisting its own processes to suit the favourable narrative at the time. |
@perlboy Thanks for your input. To help elaborate on the
For these examples, sector is determined as per section 8.1 in OIDC Core 1.0. The data recipient is in control to drive the adoption/migration through updating their registration via the PUT DCR operation. Currently, the standards DO NOT constrain the scenarios where identifiers are broken. If an invalid adoption or migration were to occur, identifiers would break and the data the ADR has previously collected would lose referential integrity. What we will attempt to answer this maintenance iteration is: Should the registration process enforce the downstream technical or business requirements of the CDR? |
The analysis of this issue initially focussed on the |
We note this issue has been added to the intended issues for discussion on MI12. Due to resource constraints associated with multiple future dated obligations and Energy sector activation Biza is unable to provide the further comments, evaluation or elaboration we feel will be necessary to appropriately resolve this issue. As a consequence we request this issue is deferred until a later maintenance iteration. |
Description
In the release of version 1.13.0 the following section was added on October 2021 by @JamesMBligh that was not present in the Register specification:
This is despite Biza.io raising the potential of altering existing specification and the reassurance from the CDR API Stream that there was no such intent.
Despite these assurances the following statements have resulted in direct modifications using binding RFC2119 language to current implementations without notice:
Fields contained within the SSA, if ignored, would result in the incorrect outcome for the registration OR an invalid SSA. An example of this is the
sector_identifier_uri
field which was introduced as an optional field in July 2021 with no specific future dated obligation. By ignoring such a field a software product would be non-functional as the redirect uris would have multiple hostnames.The documented scenarios do not handle the possibility of unknown scopes being introduced into the SSA and as such, as the scenarios are explicitly defined, many Holders currently default to rejecting SSAs containing malformed scopes.
Area Affected
Register Standards
Change Management regarding the Standards
Change Proposed
The text was updated successfully, but these errors were encountered: