Maintenance Iteration 24 Holistic Feedback

[Technical-DSB]

This change request has been created to simplify the raising of minor changes, such as text corrections or description clarifications, that are not material to the standards but do have a real impact on readability and clarity.

Please raise any suggestions that you would like included in Consultation Draft 373 - Maintenance Iteration 24 on this issue and the DSB will review them. If a suggestion is a material change a dedicated change request will be raised.

[nils-work]

The Banking endpoints were updated in v1.35.0 to include the '400 - Missing Required Header' error response.
It should also be added to all other endpoints with a mandatory header (e.g., x-v).

[nils-work]

The below fields were likely intended to be conditional as they relate to each other, but their specification is inconsistent, resulting in them being displayed in the standards currently as optional. As the Register provides these fields where available, there may be no immediate impact to participants, but the requirements of these fields should be clarified in a future version of Get Data Holder Brands Summary, for example with #518 - Deliver V2 of the GetDataHolderBrandsSummary API.

"DataHolderBrandSummaryV2": {
...
  "type": "object",
  "properties": {
    "dataHolderBrandId": {
      "maxLength": 36,
      "type": "string",
-     "x-conditional": true,
      "description": "Unique id of the Data Holder Brand issued by the CDR Register."
    },
    "interimId": {
      "maxLength": 36,
      "type": "string",
-     "x-conditional": true,
      "description": "Interim id of the Data Holder Brand issued by the CDR Register. This is to be used to uniquely identify the record when _dataHolderBrandId_ is not populated and is not to be reused."
    },

[anzbankau]

The feature type enum EXTRA_DOWN_PAYMENT in BankingProductFeatureV4 is out of alphabetical order:

• COMPLEMENTARY_PRODUCT_DISCOUNTS
• EXTRA_DOWN_PAYMENT
• DIGITAL_BANKING
• DIGITAL_WALLET
• DONATE_INTEREST
• EXTRA_REPAYMENTS

[NilsBerge-DSB]

In the Private Key JWT Client Authentication and Self-signed JWT Client Authentication sections, change both instances of this incorrect/confusing text, from:

iss - REQUIRED. Issuer Identifier for the Issuer of the response. The client ID of the bearer.

to:

iss - REQUIRED. The identifier for the issuer of the JWT. The client ID of the bearer.

[NilsBerge-DSB]

Replace the following mock value in two Non-normative Examples with a variable that references an expected value:

- "iss":"dataholderbrand-123",
+ "iss": "{dataHolderBrandId}",
 
- "sub":"dataholderbrand-123",
+ "sub": "{dataHolderBrandId}",

Replace the following mock value in two Non-normative Examples with a variable that references an expected value:

- "sub": "a9ebbef6-1f0b-44eb-96cf-0c5b51b37ab2"
+ "sub": "{ppid}"

Replace the following mock values in one of the Non-normative Examples with a variable that references an expected value:

- client_id=5ntwEOpMdPxxy49Gt28SXWY6j3afl2CP2&
+ client_id={ClientId}&

- "iss": "5ntwEOpMdPxxy49Gt28SXWY6j3afl2CP2",
+ "iss": "{ClientId}",

- "sub": "5ntwEOpMdPxxy49Gt28SXWY6j3aflCP2",
+ "sub": "{ClientId}",

Replace the following mock values in all the Non-normative Examples with a variable that references an expected value:

- "client_id": "s6BhdRkqt3"
+ "client_id": "{ClientId}"

- client_id=s6BhdRkqt3
+ client_id={ClientId}

- "iss": "s6BhdRkqt3",
+ "iss": "{ClientId}",

- "sub": "s6BhdRkqt3",
+ "sub": "{ClientId}",

Replace the following mock values in all the Non-normative Examples with a variable that references an expected value:

- client_id=12345
+ client_id={ClientId}

- "iss": "12345",
+ "iss": "{ClientId}",

- "sub": "12345",
+ "sub": "{ClientId}",

- "aud": "12345",
+ "aud": "{ClientId}",

[NilsBerge-DSB]

Replace the following value in two Non-normative Examples with a representation of the DH as audience for a PAR request object:

- "aud": "https://adr.example.com",
+ "aud": "https://tls.dh.example.com",

Replace the following value in the Non-normative Examples with an example for a TLS issuer for an authorisation response:

- "iss": "https://mtls.dh.example.com/",
+ "iss": "https://tls.dh.example.com",

[NilsBerge-DSB]

Replace the following value in the Non-normative Examples with a representation of the MTLS host of the token endpoint:

- "aud": "https://tls.dh.example.com/token",
+ "aud": "https://mtls.dh.example.com/token",

[NilsBerge-DSB]

Typo in the following sentence (cdr_arrangement_id_) -

Data Holders MUST support the cdr_arrangement_id_ cdr_arrangement_id claim provided in the Request Object.

[NilsBerge-DSB]

The following Non-normative Example associated with the PAR endpoint response shows an expires_in value for a Request URI of 3600:

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache, no-store
{
  "request_uri": "urn:mtls.dh.example.com:bwc4JK-ESC0w8acc191e-Y1LTC2",
  "expires_in": 3600
}

As the standards state:

The Request URI MUST expire between 10 seconds and 90 seconds.

the value should be changed to 90 to clarify the maximum expected Request URI expiry time:

- "expires_in": 3600
+ "expires_in": 90