Meeting minutes
Minutes
<kaz> Mar-28
McCool: looking at the PR 1421 again
<McCool> we also need to look at this issue: https://
<JKRhb> https://
PR #1452 fix: allow uri value only for in field of APIKeySecurityScheme
https://
related Issue #1440 https://
McCool: check the spec actually what it's written
Jan: problem is, there is one definition 'in'
McCool: how we do handle case right now does not make senese
Jan: wouldn't it make sense to separate?
McCool: one suggestion is using different name for 'in', e.g., in_xx, and use the same label "in"
Jan: might cause confusion
McCool: let's think about it and the worst case just leave as it is now. we can write validation in json schema
McCool: we need to consider compatability
McCool: URI is not a problem for compatability
Make Security and Privacy Considerations Normative PR #295
https://
McCool: made a normative sections and RFC keywords. Now it has assertions and new wordings.
<kaz> s/related PR/related Issue/
Jiye: why 3x? is there any reference?
McCool: it's from QUIC/HTTP3.
Philipp: it makes sense when service accepts HTTP3
Philipp: you might want to add periodically chainging IP address?
McCool: good point, I will add it to the note.
McCool: do you know related RFC number?
Philipp: I will have a look
McCool: will not push to merge this right away, but will wait one week for a review
Review and Update Security and Privacy Considerations #726
https://
McCool: need to read through the document, and see what we can do
[adjourned]