Brief Project Description
The project aims to deliver support for GNAP in the OpenAPI Specification as a building block for providing richer API security definitions through OpenAPI.
Project Update
The GNAP project began alongside my increased involvement with scaffolding the FAPI 2.0 Security Profile in the OpenAPI Specification (OAS), with initial discussions focusing on high-level views of how to improve OpenAPI itself and incorporate complex security requirements.
This discussion morphed into an agreement to create a proposal for a dedicated OpenAPI Security Specification, which is standalone and separate from the OAS itself. This followed the creation of a GitHub Discussion on the shape of the proposal, which suffered from low engagement in soliciting opinions from the community and quickly became extremely dense and unwieldy. API security, especially complex profiles with many moving parts, is inherently difficult to discuss in a cohesive way, hence the change in approach.
I have created a comprehensive proposal for implementing security constraints, which I submitted as a PR on the Security Special Interest Group repository on September 25, 2026.
The expectation is that once agreement is reached on the proposal, the work on GNAP in OAS can come together quickly based on the revised security framework, which should result in significant improvements to the authoring and delivery of security profiles like GNAP.
Project Impact & Target Audience(s)
The target audience for this project has grown significantly, from implementers of GNAP to all API consumers and providers that make use of API security objects in OAS. This includes industry bodies such as the OpenID Foundation and various open banking and open finance bodies such as Open Banking Limited in the UK. The underlying proposal to provide a more modular and decoupled API security approach across OAS will therefore have a significantly greater impact than the implementation of GNAP alone.
Progress on Objectives, Key Activities
The activity of implementing GNAP in OAS is significantly behind the original schedule I set out in my milestones.
However, the net benefits of the work I have done to date (pending approval of the proposal) are similarly significant. The proposed approach decouples API security from the main OAS, with the objective of making API security features in OAS much easier to change (from a specification authoring view) and allowing tailoring by specific interest groups in the ecosystem. The proposed specification shape also introduces many opportunities for evolving agentic support in OAS, with "hooks" to point to sources of information that can be either referenced by a human or inferred from the corpus of knowledge held in an LLM.
The time and effort spent on this activity provide important building blocks for the delivery of GNAP in OAS and for the future evolution of API security objects across OpenAPI Initiative specifications.
Communications and Marketing
I will be discussing the progress to date at Apidays London on October 1, 2026, with the goal of eliciting feedback and support and ideally attracting more contributors to the new OpenAPI Security Specification, pending agreement on the proposal.
I will also be revisiting relevant working groups and hopefully writing a deep-dive blog post (for an as-yet-unconfirmed but important API-related blog).
What's Next?
Against the originally proposed milestones, the remaining work covered by the project is scheduled as follows:
- TypeScript implementation of GNAP for Kiota: This task will be brought forward if the proposal described above goes through the required processes at the TDC and TSC, and most likely the Security Special Interest Group (I am not sure it is active, but I will propose an ad-hoc session to elicit feedback).
- GNAP Support in OAS: I will contribute to and support the work based on feedback on the proposal above, with a view to working closely with Henry Andrews on completing the work in as timely a fashion as possible.
- Educational Materials (OpenAPI Learning site, OpenAPI Fundamentals): This is reliant on the final shape of GNAP in OAS, but I will push this along as expediently as I can.
Community Support
Feedback from experts in OpenAPI and API security on the proposal or the GNAP shaping, and any contributions, are most welcome!
Top comments (0)