Open adamretter opened 1 year ago
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
I would still like a response to this if possible?
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
Can someone reply to this please?
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart:
Id still like some feedback on this
I noticed that the current securitySchemes mechanism in AsyncAPI 2.6.0 seems to limit sending an Auth token in a header (similar to Bearer Authentication) to the HTTP protocol only. For use cases like JMS, it would be valuable to extend this capability.
I'm looking to achieve something like:
securitySchemes:
bearerAuthentication:
type: apiKey
in: header
name: AuthenticationToken
description: Bearer Authentication Token should be provided in the AuthenticationToken
header.
Is there a recommended way to implement this with the current spec, or should we consider updating the spec to support this for protocols beyond HTTP?
The
securitySchemes
mechanism of AsyncAPI 2.6.0 spec does not seem compatible with the idea of sending an Auth token (e.g. similar to Bearer Authentication) in a header when using the JMS protocol. The 2.6.0 version of the spec seems to restrict this to HTTP only for some reason.I would like to be able to achieve something like:
Thoughts on how I can achieve this, or should I contribute an update to the spec?