Known issues log

01

Specification issue

Aug 3, 2024

What should value of `exp` be in an introspection response with `"active": false`

Added explainer, will update the text in future specification versions. Also an errata candidate.

status:known issue

02

Specification issue

Aug 26, 2024

Contradictory statements regarding pagination 'Links'

Have published an explainer to communicate intent here: https://paymentsnz.atlassian.net/wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/1918533642 .

This is a candidate for errata and inclusion in future standards versions.

status:known issue

03

Specification issue

Sep 8, 2023

Time as Customer - GAP

v3.0.0 Security Profile | Introspection response states the exp is mandatory in the introspection response. What should the exp value contain if the response indicates "active": false?

Should exp be conditionally mandatory - that is, should we update the security profile to state exp MUST be returned if "active" : true otherwise expshould not be returned?

Added explainer here: https://paymentsnz.atlassian.net/wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/1921122308, will update the text in future specification versions.

This is a candidate for errata and inclusion in future standards versions.

status:known issue

04

Specification issue

Jun 26, 2023

here are a couple of potential errors/omissions in the sequence diagram in Payments Initiation API Specification - v2.1.0 | Sequence Diagram (and subsequent standards versions too, probably)

1. In step 4 the consent status depends on whether it is an enduring payment consent or a domestic payment consent. EPC’s don’t have a Consumed status.

2. Step 5 has two opts for [accounts] which don’t exist in these standards

3. Step 5 is missing the GET domestic-payment/debtor-account

Corrected the diagram in v3.0 onwards.

This is a candidate for errata and inclusion in any future patch changes for all other standards versions.

status:known issue

05

Specification issue

Jan 13, 2025

The PNZ v3.0 Security Profile lists the following statements:

While at the same time in the PNZ v3.0 Security Profile

This seems to be contradictory and should probably be clarified by:

1. updating the NZ Read and Write API Security Profile section to remove the assertion that FAPI-RW section 8.6 should be followed and instead explicitly list the algorithms (or reference Step 2: Form the JOSE header), since the standards are obviously not using the FAPI-RW JWS algorithms.

2. remove the other non-FAPI-RW algorithms.

 In the meantime, we has assumed option 1 above and will be using the list of allowed algorithms for signing:

• RS512

• PS512

• ES384

• ES512

If this is not the correct assumption, can you please let me know so we can fix this up on our end.

Thanks for raising, it does seem that this could create some confusion. To clarify, 8.6 partially applies, since we follow:

2. should not use algorithms that use RSASSA-PKCS1-v1_5 (e.g. RS256); and

3. shall not use none.

But your assumption of option 1 is correct, the algorithms specified

Probably the most practical approach would be to include this in a future update as a note to the Security Profile. In the meantime we will look to include in errata (when we publish this) in the near future.

This is a candidate for errata and inclusion in any future patch changes for all other standards versions.

status:known issue

06

Specification issue

Apr 2, 2025

The spec and examples all use http not https https://github.com/PaymentsNZ/API-Event-Notification/blob/master/schemas/event-notification-schema.json#L152 but the docs show that this should be https (and I would have expected https) Event Notifications v3.0.1 | Event Notification Request

The API Centre will update and correct errata in the next standards version.

status:KNOWN ISSUE