P-26 | Protocol server supporting Open API Specification 3.1

[emmayank]

Ticket Contents

Purpose

Each network has its own policy rules that need to be validated at the protocol layer. Currently, BAP and BPP must write custom business logic to validate these policy rules, leading to increased development and maintenance overhead. Additionally, this approach creates a higher likelihood of inconsistencies at the protocol level among different participants (BAP/BPP). The purpose is to validate the policy rules specified in Level 2 (L2) configurations of Open API Specification 3.1 directly at the protocol level, thereby reducing overhead and ensuring uniformity across participants.

Objective

Following are the Objective for this goal :

1. Support for Open API Specification 3.1 Validation: Ensure the protocol server fully supports validation according to Open API Specification 3.1.
2. Automated Policy Rule Validation: Implement automated validation of policy rules at the protocol layer to eliminate the need for BAP/BPP to write custom business logic, reducing development and maintenance overhead.
3. Uniformity Across Participants: Achieve consistency in policy rule validation at the protocol level, minimizing discrepancies among different participants (BAP/BPP) and enhancing interoperability.
4. Efficient Validation Process: Optimize the protocol server to validate API endpoints against L2 configurations with minimal latency, aiming for a maximum of 20 milliseconds to ensure prompt and efficient validation.
5. Simplified Development Workflow: Simplify the development workflow for BAP/BPP by offloading policy rule validation to the protocol server, allowing developers to focus on core business logic and functionality.

Goals

Assess Middleware Compatibility:

• Verify if the existing middleware has been upgraded to support Open API Specification 3.1.
• Identify and evaluate other middleware options that support Open API Specification 3.1, including those used in proof-of-concept (POC) by the Spec team.

Middleware Integration:

• Select the most suitable middleware based on compatibility and performance criteria.
• Integrate the chosen middleware into the protocol server code, ensuring seamless functionality and adherence to Open API Specification 3.1.

Configuration Validation:

• Create a sample L2 configuration file using Open API Specification 3.1 or take it from specification team.
• Validate the protocol server's capability to process and enforce policy rules as specified in the L2 configuration.

Testing and Verification:

• Conduct comprehensive tests to ensure the protocol server correctly validates API endpoints against the sample L2 configuration file.
• Perform a latency test to measure the validation speed of the new middleware.
• Compare the latency results with those of the previous middleware to evaluate performance improvements.

Documentation and Reporting:

• Document the middleware selection process, integration steps, and validation results.
• Provide detailed reports on latency comparisons and overall performance enhancements.

Deployment and Monitoring:

• Deploy the updated protocol server in a controlled environment.
• Monitor the system for performance, making adjustments as necessary to ensure optimal operation.
• Once the PR get merged, update the image in Beckn dockerhub.

Acceptance Criteria

Full Support for Open API Specification 3.1:

1. The selected middleware is integrated into the protocol server with no functional disruptions.
2. The protocol server successfully validates API endpoints against the L2 Confgis written in open API Specification 3.1 without errors.
3. Comprehensive testing shows no major issues or bugs in the validation process.

Latency Performance:

1. Validation of API endpoints against L2 configurations occurs within a maximum latency of 20 milliseconds.

Documentation and Reporting:

1. Complete and accurate documentation of middleware selection, integration steps, and validation results.
   Detailed reports on latency tests and overall system performance improvements are provided.

Implementation Details

Explore this library for the validation - https://www.npmjs.com/package/openapi-backend

Product Name

Protocol Server

Domain

Validation

Tech Skills Needed

JavaScript, Node.js

Complexity

Low

Category

Backend

Related Tickets

#171

[emmayank]

Here is the sample L2Config written in Open API Specification 3.1 - https://github.com/rajaneeshk90/local-retail-rk/blob/layer2-28thJune/api/l2-config/localretail_shopping_1.1.0.yaml

[emmayank]

Here is the Postman collection to validate against the above L2 Config

OAS3.1.postman_collection.json

[harshcrop]

assigning this issue to @Mishalabdullah

[Mishalabdullah]

@emmayank and @harshcrop, How can I test the schema validator using the sample l2 config and the post collection provided ?

[emmayank]

Hi @Mishalabdullah , Add the L2Config, and then make the request as given in the postman collection. for each API i have given some positive and negative cases. for negative cases you should be getting error from the validator.

[madhukaraman]

Hey @emmayank this looks interesting to me, can I pick this one ?

[emmayank]

Hi @madhukaraman, can you please go through the issue and let us know the ETA, will assign you the issue post that.

[madhukaraman]

Hey @emmayank , can we get discord vc understand the repository and task better so that I can provide you the ETA.

[KPRASANT9]

Same with me, Any high level info would be highly appreciated.

[harshcrop]

@KPRASANT9 @madhukaraman Please review the repository and familiarize yourselves with it. We've outlined most of the details regarding what we aim to achieve in this issue. Let us know what support you need to get started.

[meenakshi2468]

cdimascio/express-openapi-validator#882 : Link shared by Venkatesh - updating here.

[emmayank]

The content in this PR is now available on branch oas-3.1 and package [email protected]. please try it out.

experimental OAS 3.1 in alpha (contributions welcome - see branch oas-3.1 and pr-882)

npm install [email protected]
To contribute submit PRs against the oas-3.1 branch.

[emmayank]

The current plugin is now supporting OAS3.1. instead of replacing the plugin we need to test if it is working fine with the current plugin

[yesrag2309]

@emmayank - Any reason that this card status is moved from InProgress to Backlog. FYI, the flow status is in accepted. Please update the current status on this card.

@viraj89 @faizmagic

[yesrag2309]

@emmayank - Any reason that this card status is moved from InProgress to Backlog. FYI, the flow status is in accepted. Please update the current status on this card.

@viraj89 @faizmagic @ankitShogun

[ankitShogun]

It seems to be running fine even after using the new version of the configuration file. Used this

using express-openapi-validator: 5.1.6

Before adding the configuration. Doing search request

After

Behaving normally @emmayank

[ankitShogun]

Found some inconsistencies when tested further. Need to debug some more

[em-abee]

We further investigated and tried to find RCA of the issues, the problem lies majorly for nested array. Validator is by passing the validation checks for nested array, whereas for plain conditions it is working perfectly fine. To fix this we have 2 options left:

1. Change the spec to see if there's another way to apply rules for nested array- @rajaneeshk90
2. Create another middleware to validate 3.1 specs - @em-abee

[meenakshi2468]

As discussed with Mayank - this issue is completed as on Oct 4.

[meenakshi2468]

Mayank to review and mark this as closed