eCommerce Platform

ATO eCommerce Platform Project

Echo of identifiers and TFN in XML/JSON responses

Contents

Contents

1.1Architecture Decision Echo of identifiers and TFN in XML/JSON responses

Change Log

Version / Author / Date / Comments
0.3 / Brendan Kee / 18/05/2016 / Drafted

1.1Architecture Decision Echo of identifiers and TFN in XML/JSON responses

Subject Area / SBR ebMS3 and EMC / Topic / Message Design
Architectural Decision / Echo of identifiers and TFN in XML/JSON responses / ID / TBA
Issue or Problem Statement / Background:
As part of the approach to implement the operational framework, a review of the ATO software services is being undertaken to understand the risk of each service before being released for whitelisting and ensure unnesessary risk is reduced within each service.
The risk of each service is being assessed in consideration of the characteristics ofthe service combined with the potential business risk.
This includes business risk pertaining to personal or sensitive client details that are returned by the service (even when included in the original request).
The TFN is included in this list of personal or sensitive details and in some cases the return of the TFN is the only reason the the DDS service into is classified in the “medium” risk category.
As this behaviour is common across the XML/JSON services, this means that there are minimal services that are in the “low” risk category
By removing the TFN from the response, this will lower the risk rating resulting in lower security requirements placed on the software developer and make it more accessible.
Current state:
The primary client identifier provided in the request payload is “echoed” in the response payload (e.g. if you provide a client ABN in the request, you will receive the client ABN with the response payload).
This is in pattern with the SBR AU reporting taxonomy principles (XBRL) specifically related to Data contextualisation (SBRAUTaxonomyPrinciplesv3.0 Section 6) whereby each data element should be stand on its own and the owning party is able to identified.
Impact of removing client identifiers
By removing/suppressing the TFN, the payload in itself cannot be used to maintain client identification.
Client identification will need to be maintained by the BMS via transaction and message packaging context.
This has the potential to impact the reconciliation of the payloads if there is a dependency within the BMS on the client identifiers in the response (in the case of potentional defects).
Single transaction processing:
“PartID” set in the SBR eBMS3 part properties (eb:PayloadInfo/eb:PartInfo/eb:PartProperties) identifies the specific payload part, which allowsmatching to the corresponding response (set by BMS). See SBR ebMS3 Web Services Implementation Guide v1.5 for further detail.
Batch/Bulk transaction processing:
“Document ID” in the record delimiter (set by BMS) enables the matching of records within a batch/bulk transaction
See ATO Common Message Implementation Guide v3.1 for further detail.
Assumptions
Motivation /
  • Understand how the “echoed” client identifers are being consumed.
  • Reducing unessessary sensitive information returned in the response and therefore reducing the potential risk of the service and the risk rating.
  • Reducing the risk of the service will make the service more accessible due to less conditions placed on developers.
  • Agree to the pattern around “echoed” client identifers.

Alternatives / Issue 1: the “echo” pattern and TFN client identifier
Option 1 –Remove the “echo” of TFN from low risk services
  • TFN will not be built into the response oflow risk services, but will remain in higher risk services.
  • Other identifiers will still be “echoed”
Pros
  • Minimal change: Mapping logic can be used to suppress the TFN (see issue 2)
Cons
  • Inconsistent return of client identifiers (i.e. No client identifier if a TFN has been used in the request, but all others returned)
  • Inconsistent return of the TFN across ATOservices, potentially impacting
Option 2 –Remove the “echo” of TFN from all services
  • TFN will only be built into the response where there is a specific business need.
  • Other identifiers will still be “echoed”
Pros
  • Minimal change: Mapping logic can be used to suppress the TFN (see issue 2)
Cons
  • Inconsistent return of client identifiers (i.e. No client identifier returned if a TFN has been used in the request)
Option 3 –Remove the “echo” of identifiers as a pattern
  • Client Identifiers will only be built into the response where there is a specific business need.
Pros
  • Consistent messaging pattern going forward.
Cons
  • Change in message design pattern
  • Inconsistent with XBRL services.
Option 4 – Retain the TFN in the response
Pros
  • Maintain existing patterns
  • Allows reconciliation of payloads via client identifiers.
Cons
  • Increased base level risk rating for services (medium), which may result in higher security requirements and time to availability for whitelisting.
Issue 2: For current XML/JSON services, method of removal of TFN from the response
The TFN element will be suppressed from the current services (and other client identifiers depending on Issue 1).
The Response schema will not be updated.
Option 1 – Mapping logic (Suppression)
Pros
  • No impact to schemas
  • Minimal change.
Cons
  • Element exists in schema but is never consumed.
  • Potential confusion for new developers.
Option 2 – Element removal
The TFN element will be removed from the current services (and other client identifiers depending on issue 1).
The Response schema will be updated.
Deactivation of older versions of services that have not been released.
Pros
  • Minimal confusion to new developers.
  • As the services have been not been whitelisted, breaking change has less of an impact.
Cons
  • Breaking change to the response schema.
  • Potential delays to allow the refactor to occur.

Decision
Justification
Implications
Derived requirements
Related Decisions
Other alternatives (discarded)

END OF DOCUMENT

UNCLASSIFIEDPage 1 of 5