v3.3: SAFs -> guidance for constants versus discoverability
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 15/100
- Issue 類型
- 文件
- 描述清晰度
- 需要釐清
- 活躍度
- 活躍
- 領域
- api, documentation
研究方向
The issue names no file or test. Read the linked discussion in PR 5447 and the existing security authentication framework (SAF) material in the OpenAPI Specification repository to see how runtime-discoverable values are handled today. Done means a proposed written guidance text for SAF authors and for users on conflicts between a document and a runtime value, agreed with maintainers. This is design work, so a newcomer should wait for a decision before starting.
由索引模型根據 Issue 內容生成。
描述
This is a follow up to this comment https://github.com/OAI/OpenAPI-Specification/pull/5447#discussion_r4221692962 which was left during the TDC call.
Some values, especially in the context of formalized security protocols, could be discovered at runtime through the protocol, and/or specified in the OAD as a constant from the SAF data structure.
An example of that is the GNAP as_url that can be discovered in the www-authenticate header in the 401 response, or specified in the OAD (based on the current proposal at time of writing).
After we spin the wheel on a couple of times on new SAFs (as @handrews has rightfully pointed out that we'll get better answers to those questions through a bit more experience on that new design approach), we should probably provide additional generic guidance that applies to all SAFs:
- outside of the OAS specification, for the people writing SAFs, when should a "field" that already can be discovered at runtime be available in the data structure as well?
- in the OAS specification, for users of the specification/SAFs: what to do when a value in the document contradicts a value discovered at runtime?
I hope this issue captures the 2 discussions on the topic accurately. And that it's articulate enough that when we revisit the issue in a couple of months we know what this is about :)
- 主要語言
- Markdown
- 星號
- 31.3k
- 分支
- 9.2k
- 平均合併
- 2 天 3 小時
- 30 天內合併 PR
- 8
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
OAI/OpenAPI-Specification 的其他 Issue
-
Housekeeping
難度 1/5 1 小時以內 新手友好度 8/100
OAI/OpenAPI-Specification#5571 ·
維護者通常 1 天內回覆
-
Housekeeping
難度 1/5 1 小時以內 新手友好度 45/100
OAI/OpenAPI-Specification#5566 · 5 則留言 ·
維護者通常 1 天內回覆
-
Housekeeping
難度 1/5 1 小時以內 新手友好度 35/100
OAI/OpenAPI-Specification#5562 · 4 則留言 ·
維護者通常 1 天內回覆
-
v3.2.1 release可能重新可做 @lornajane 於 36 天前認領，目前沒有進行中的 PR。 未關閉
OAI/OpenAPI-Specification#5460 · 11 則留言 · 1 個 reaction · 已指派 1 人 ·
維護者通常 1 天內回覆
-
param serialization
難度 5/5 一週以上 新手友好度 25/100
OAI/OpenAPI-Specification#5366 · 12 則留言 ·
維護者通常 1 天內回覆
查看 OAI/OpenAPI-Specification 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 76/100
melgarafael/DeskcommCRM#3000 ·
維護者通常 1 天內回覆
-
OFN writer emits `DocIRI` as a bare IRI, which becomes a version IRI or a parse error on re-read未關閉
難度 2/5 1-3 小時 新手友好度 72/100
phillord/horned-owl#338 ·
維護者通常 1 天內回覆
-
ai-driven-qa bug Cosmetic
難度 2/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 66/100