Clarification of x-fapi-interaction-id header

[CDR-API-Stream]

Description

The standards make exclusions for some headers fo unauthenticated calls (e.g. x-fapi-auth-date). No such exclusion is made for x-fapi-interaction-id with the intent that this is a useful tracing header for all resource calls (both authenticated and unauthenticated). Based on a review of data holder implementations this is an area with clear ambiguity as many PRD implementations do not appear to support the interaction header. Resolving this ambiguity is probably a good thing to do.

Area Affected

The area affected depends on the final solution but a minimal solution would at least impact the headers section of the standards.

Change Proposed

Proposed options could include:

• Clarification text added to the x-fapi-interaction-id section
• Removal of the obligation of using this header for unauthenticated calls (acknowledging a reduced ability to do end to end tracing)
• Updates to all endpoint definitions in swagger and API definitions to include x-fapi-interaction-id where it is required

DSB Proposed Solution

The current DSB proposal for this issue is in this comment.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It was agreed to incorporate this change request into this maintenance iteration.

Options Proposed

• (Recommended) Option 1: Clarify that it must be returned or played back for authenticated APIs only (optional for unauthenticated)

  • Not a breaking change and it aligns to upstream FAPI specifications

• Option 2: Re-purpose the x-fapi-interaction-id for all Data Holder APIs (mandatory for both authenticated and unauthenticated resource APIs)

  • Breaking change that overrides the upstream FAPI specification

• Option 3: Include a CDR specific correlation ID header

  • Breaking change
  • This correlation ID would be introduced for all endpoints defined by the data standards (ADRs and DHs)

[CDR-API-Stream]

This issue was discussed in the maintenance iteration call held on 17/08/2022.

Aligning to FAPI was preferred by participants with the introduction of a x-cds correlation ID headers to be considered in the future when the FAPI 2.0 migration is consulted.

Note: FAPI 1.0 requires the x-fapi-interaction-id header. FAPI 2.0 which is currently in draft, drops mandatory support for x-fapi-* headers including the x-fapi-interaction-id header.

This change has been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.19.0...maintenance/411

[CDR-API-Stream]

This change has been updated to target v1.20.0: ConsumerDataStandardsAustralia/standards-staging@release/1.20.0...maintenance/411

[perlboy]

It's worth noting that FAPI 1.0 doesn't require this because this endpoint isn't a protected resource.

With that aside and a little bit of scope creep here but if we're going to "align" with FAPI 1.0 then perhaps adding the component of not rejecting x-fapi-customer-ip-address as well is worthwhile.

I actually don't like any of these headers but somewhat mundane consistency is better than ambiguity.