The ReadRefundAccount defined in the VRP spec is an enum which supports a Yes or No value.
This is causing an issue when we use the openapi-generator-maven-plugin to generate Java code for this type.

The generator is interpreting the yml Yes/No as boolean values and mapping them to true/false, which causes the Java code to be produced as follows:

public enum ReadRefundAccountEnum {
    TRUE("true"),
    FALSE("false");
...
}

A fix for this is to quote the "Yes" and "No" values in the yml schema and the codegen produces the correct output. As Yes and No are valid representations of boolean in yml, then I think for safety they should be quoted so they are not misinterpreted. The definition would then look like this:

ReadRefundAccount:
  type: string
  enum:
    - "Yes"
    - "No"
  description: >
    Indicates whether information about RefundAccount should be included in the payment response.

Looking at the Open API examples, we see they do the same thing for the port enumeration, quoting the port values.

I would really appreciate it if someone can review the above and apply the fix I have suggested please.

Problem

File: ./README.md

...
### Payment Initiation

- [Swagger (OpenAPI 2.0) - YAML](./dist/swagger/confirmation-funds-swagger.yaml)
...

Description

The link above should refer to ./dist/swagger/payment-initiation-swagger.yaml.

In the case of account information multiple Content Type is supported:

    "content": {
      "application/json; charset=utf-8": {
        "schema": {
          "$ref": "#/components/schemas/OBReadConsentResponse1"
        }
      },
      "application/json": {
        "schema": {
          "$ref": "#/components/schemas/OBReadConsentResponse1"
        }
      },
      "application/jose+jwe": {
        "schema": {
          "$ref": "#/components/schemas/OBReadConsentResponse1"
        }
      }
  }

While in case of Confirmation of funds only "application/json; charset=utf-8" is supported.

    "content": {
      "application/json; charset=utf-8": {
        "schema": {
          "$ref": "#/components/schemas/OBFundsConfirmationConsentResponse1"
        }
      }
    }

This is inconsistent and also API Gateway might not support charset encoding validation breaking the specification validation

Can this be made consistent as in case of Account Information Specification

Hi,

Problem:

When using swagger-codegen to generate server or client code using the open banking specs, the use of the x-namespaced-enum property as opposed to just enum is causing the code to generate incorrectly.

Description

When using the enum property the code generator correctly creates the enum and references the enum in the appropriate class i.e. in OBAccount3 the accountType and accountSubType fields correctly reference the generated enums, i.e.

  @JsonProperty("AccountType")
  private OBExternalAccountType1Code accountType = null;

  @JsonProperty("AccountSubType")
  private OBExternalAccountSubType1Code accountSubType = null;

However when the x-namespaced-enum property is used the class that references that property simply has it's field defined as a String. An example of this can be seen in the OBBranchAndFinancialInstitutionIdentification5 class, where the schemeName property is a String as opposed to an actual enum i.e.

@JsonProperty("SchemeName")
private String schemeName = null;

Question

Has a vendor extension been created that will allow the code generator to correctly create and reference the appropriate enum class, as opposed to just defining a String?

In the "Events API Specification - ASPSP Endpoints" Swagger, there seems to be missing the base url: the other ones have /open-banking/v3.1 as a base url path, but this one does not, is it normal? because the "Event Notification API Specification - TPP Endpoints" does have it as well,

Thank you

Looks like there is a typo in the following field:

https://github.com/OpenBankingUK/read-write-api-specs/blob/master/dist/openapi/payment-initiation-openapi.yaml#L3219

is:
ContractPresentInidicator
should be:
ContractPresentIndicator

The error is carried out in all diagrams etc., however Interestingly, it is correct in the JSON request example:
https://openbankinguk.github.io/read-write-api-site3/v3.1.11/resources-and-data-models/pisp/domestic-payment-consents.html

I downloaded the assets from 3.1.8r2 release to build VRP but noticed that the paths given for VRP are different than what's given in the documentation

paths in 3.1.8r2 release assets:

/domestic-vrps/{ConsentId}:
/domestic-vrps/{ConsentId}/payment-details:

in the documentation from https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/vrp/domestic-vrps.html#endpoints

/domestic-vrps/{DomesticVRPId}
/domestic-vrps/{DomesticVRPId}/payment-details

The parameters also reference consentid instead of vrpid

There's also a ticket raised on Service Desk:
https://openbanking.atlassian.net/servicedesk/customer/portal/1/OBSD-24636

Starting in version 3.1.2, a number of schema definitions that are still in use are no longer present in the swagger fIles

Take OBDomestic2 still in use in 3.1.10: https://openbankinguk.github.io/read-write-api-site3/v3.1.10/resources-and-data-models/pisp/domestic-payment-consents.html#obdomestic2

Compare 3.1.1 with 3.1.2 and 3.1.10:

has a definition for OBDomestic2:

• https://github.com/OpenBankingUK/read-write-api-specs/blob/v3.1.1/dist/payment-initiation-swagger.json#L3389

no definition for OBDomestic2:

• https://github.com/OpenBankingUK/read-write-api-specs/blob/v3.1.2/dist/payment-initiation-swagger.json
• https://github.com/OpenBankingUK/read-write-api-specs/blob/v3.1.10/dist/openapi/payment-initiation-openapi.yaml

Expected result

The swagger should contain schema definitions for all classes e.g.

• OBAuthorisation1
• OBCharge2
• OBDomestic2
• OBExternalConsentStatus1Code

Actual result

The swagger is missing schema definitions

Lack of default values on required fields causes errors in most OpenAPI language generators. Any chance of getting sensible defaults declared?

Up until now, I have generated the Java controllers and interfaces for all versions of the Read/Write API since v3.1.3, using the OpenAPI Maven plugin (openapi-generator-maven-plugin version 4.3.1). However, when generating the VRP controllers for v3.1.8, I don't seem to have any headers or request body objects in the generated code.

The response definitions appear correct, but it looks like there are no request parameters in the Swagger spec. Does anyone know why this is?

Building automated tests and tools, we discovered a few inconsistencies between the OBUK website (markdown) specs (https://github.com/OpenBankingUK/read-write-api-docs-pub) and the OpenAPI specs. More and more systems and apps use this types as the source of truth for their implementation. It should be fixed in further releases to increase the robustness of specification and avoid incompatibilities and type errors, in order to allow and ease its adoption.

Missing Components/Names:

• OBCashBalance1 (Markdown) vs OBReadBalance1/Balance as [synthetic type] (OpenAPI)
• OBCashAccount5 (Markdown) vs OBAccount6/Account as [synthetic type] (OpenAPI)
• OBReadData (Markdown) vs OBReadConsentResponse1/Data as [synthetic type] (OpenAPI)
• OBCurrencyExchange5/InstructedAmount as OBActiveOrHistoricCurrencyAndAmount (Markdown) vs OBCurrencyExchange5/InstructedAmount as [synthetic type] (OpenAPI)

=> This is not an exhaustive list. There are other synthetic definitions that needs to be declared as component using dedicated type names

Incompatibilities:

• OBCashAccount5_0 (OpenAPI) vs OBCashAccount5_1 (OpenAPI)

  • Identification is referenced as component vs synthetic definition.

• OBActiveOrHistoricCurrencyAndAmount_8 (OpenAPI)

  • Has an extra SubType compared to others (is that a new type version ?)

Components duplication:

• OBActiveOrHistoricCurrencyAndAmount (11 times)
• IOBBranchAndFinancialInstitutionIdentification5 (2 times)
• IOBBranchAndFinancialInstitutionIdentification6 (3 times)
• OBCashAccount5 (2 times)
• OBCashAccount6 (2 times)
• OB_OtherCodeType1 (9 times)

The previous feedback only relates to read-write-api-specs OpenAPI definitons.
This is for sure incomplete and there might be other inconsistencies in others OpenAPI files.