OAS 3.1 Security Schemes Relax "Scope" definition requirements - Updated Function/Rule ?

[dtolb]

Describe the bug

According to the OAS 3.1 security requirement objects. BearerAuth schemes in 3.1 are allowed to use scopes on the path without using Oauth2 schema. The rule oas3-operation-security-defined is incorrectly reporting failure for 3.1.x documents.

To Reproduce

1. Given this OpenAPI/AsyncAPI document '

openapi: 3.1.0
info:
  title: Non-oAuth Scopes example
  version: 1.0.0
paths:
  /users:
    get:
      security:
        - bearerAuth:
            - 'read:users'
            - 'public'
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: jwt
      description: 'note: non-oauth scopes are not defined at the securityScheme level'

3. Run this CLI command '....'

spectral -r oas.default.yaml my_oas.yaml

5. See error

... must be listed among scopes.

Expected behavior
Given this is a 3.1 document, I wouldn't expect an error for invalid OAS formatting from OAS 3.0. The oasSecurityDefined.ts function should support a new option 3_1 that allows updated security scopes

[ponelat]

Hey @dtolb, yup you are correct OAS 3.1, does indeed support having "roles" (to use the non-oAuth terminology) in the array within the security requirement.
So shouldn't report an error.

Would welcome a fix here, but it is a low priority.