.Net Suggestion - Support "include list" for OpenApiFunctionExecutionParameters
#10514
Assignees
Labels
api_proposal
Issues tagged with this label propose a change to the public API surface
experimental
Associated with an experimental feature
function_calling
.NET
Issue or Pull requests regarding .NET code
openapi
Issues related to the OpenAPI function importer
sk team issue
A tag to denote issues that where created by the Semantic Kernel team (i.e., not the community)
Comments
crickman
added
.NET
|
I would highly recommend that we remove |
evchaki
added
the
sk team issue
|
Hi @crickman, we've already started moving in this direction and introduced the OperationSelectionPredicate, which can be used to either include or exclude operations based on operation id, path, method, and description. This sample ImportOperationsBasedOnInclusionListAsync demonstrates this. The predicate is not propagated to the |
SergeyMenshykh
moved this from Sprint: Planned
to Sprint: In Progress
in Semantic Kernel
SergeyMenshykh
moved this from Sprint: In Progress
to Sprint: In Review
in Semantic Kernel
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 25, 2025
### Motivation, Context and Description This PR adds an operation selector predicate that can include or exclude operations based on id, method, path, and description. It also obsoletes the `OperationsToExclude` exclusion list, which is limited to filtering out operations by operation id only. Closes: #10514
glorious-beard
pushed a commit
to glorious-beard/semantic-kernel
that referenced
this issue
May 6, 2025
### Motivation, Context and Description This PR adds an operation selector predicate that can include or exclude operations based on id, method, path, and description. It also obsoletes the `OperationsToExclude` exclusion list, which is limited to filtering out operations by operation id only. Closes: microsoft#10514
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OpenApiFunctionExecutionParameters supports the ability to exclude specified API from the overall specification. This makes sense since the surface for an Open API may be quite large (huge even!).
The thing is, as an API might grow anything not excluded is included by default. This is a classic design bug: logic based on disallowed state instead of allowed state. This design bug is often associated with a security context and in this case, it could very well result in a security exploit.
Since
OpenApiFunctionExecutionParameters.OperationsToExcludeis marked experimental (SKEXP0040), considering this prior to feature graduation may be prudent.Instead of
OperationsToExclude, supportingOperationsToIncludecould provide developers with the precision that aligns with the most common intent.OperationsToExcludecould then either be deprecated or removed. IfOperationsToExclude&OperationsToIncludewere to exist side-by-side, then the inclusion list would have logical priority. Throwing an exception of both were defined may be the most clear contract. If neither are defined, then the entire API would be included in the spec.As a work-around, a developer can define the JSON API spec as a resource and edit it as they desire; however, this result in a brittle pattern where parameter changes to included api wouldn't be reflected dynamically.
The text was updated successfully, but these errors were encountered: