Scope check after SDK Grant feedback - revised GNAP/OpenAPI direction #9
Unanswered
Supercoolkayy
asked this question in
SDK Grant
Replies: 1 comment
|
Hi @Supercoolkayy, please review the grant areas that have been awarded and the updated proposal areas and timeline guidance. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi @jeremiahlee ,
Thank you for the feedback on our previous SDK Grant application.
For context, our original proposal was titled “GNAP Access Profiles for OpenAPI Security Requirements.” It focused on an OpenAPI profile/overlay for binding GNAP-protected operations to structured GNAP access rights. We also completed a public MVP to prove that direction:
Original MVP repo:
https://github.com/steven3002/gnapify-openapi
Based on your feedback, I understand that our previous approach was not aligned with the SDK Grant’s intended direction because it worked around the OpenAPI limitation as an overlay/profile, instead of addressing formal GNAP support in the OpenAPI Specification. I also understand that a credible path to Kiota implementation is important.
Before preparing a revised application, we wanted to check whether the following scope would be closer to what the Foundation is looking for and whether it would complement already-sequenced grantee work:
Draft a formal OpenAPI Specification proposal for first-class GNAP security scheme support, rather than an x-* overlay as the primary solution.
Provide a reference OpenAPI parser/model implementation path, likely through Microsoft.OpenApi.NET or the relevant OpenAPI object model used by Kiota.
Provide a Kiota proof-of-concept path showing how a formal GNAP security scheme could be recognized and mapped to a GNAP authentication abstraction in generated clients.
Provide Open Payments validation fixtures showing how the formal GNAP security scheme would apply to real Open Payments auth/resource operations.
We would not include per-language GNAP provider implementations, HTTP Message Signatures library work, Arazzo flow modeling, or runtime grant execution, since those appear to be separate grant lanes.
Would this revised scope be a better fit for the GNAP/OpenAPI lane, or is there a more specific remaining gap the Foundation would prefer applicants to focus on?
Thank you again for the clarification.
All reactions