Security - open issues

[mlagally]

Clarifications are needed:

• on OAuth credentials mechanism

• http specific protocols should be under the HTTP profile, needs some reorg of spec section

• Security Schemes are too loose #221

• Security Requirements for WebHook Consumer #222

• subscribeallevents security requirements #224

• List of required Security Schemes #220

Please use label "security" on all security issues.

[mlagally]

This is the full list - for profile 1.0 only a subset is in scope.

[mlagally]

@mmccool will lead the discussion in the security TF, and work with individual assignees on individual issues.

[mmccool]

Discussion in Security TF 2023.02.13:

• on OAuth credentials mechanism

  • Why do we have to say anything (else) here?
  • OAuth2 is a standard, it should be followed. However, it only technically applies to HTTP...

• http specific protocols should be under the HTTP profile, needs some reorg of spec section

  • Both Basic and OAuth2 should technically be under HTTP; only "nosecurity" is generic
  • Suggest moving whole section to HTTP Basic and out of "Common Constraints".
  • See resolution to Recommended Security #6; deals with this and several of the issues below, including List of required Security Schemes #220

• Security Schemes are too loose #221

  • should also be at least partially addressed by PR being developed for Recommended Security #6. For example, suggest limiting options for Basic to only use "header" (default value) for "in", make it specific to HTTP, etc. Set has already been limited; Security TF agrees with removal of Digest and only using nosec, basic, and oauth2 (code and client flows only).

• Security Requirements for WebHook Consumer #222

  • could not get to it this week, will look at in next Security TF.

• subscribeallevents security requirements #224

  • need to study and discuss more

• List of required Security Schemes #220

  • will be resolved by resolution to Recommended Security #6