Align on Commonalities' subscription-model by using sink and sinkCredentials

[maxl2287]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

Aligns on Commonalities' updated subscription model.

Which issue(s) this PR fixes:

Fixes #332

[maxl2287]

@hdamker shell I also update the BadRequest with the error-examples?

    Generic400:
      description: Invalid input
      headers:
        x-correlator:
          $ref: "#/components/headers/x-correlator"
      content:
        application/json:
          schema:
            $ref: "#/components/schemas/ErrorInfo"
          examples:
            InvalidArgument:
              value:
                status: 400
                code: INVALID_ARGUMENT
                message: "Schema validation failed at  ..."
            InvalidCredential:
              value:
                status: 400
                code: INVALID_CREDENTIAL
                message: Only Access token is supported
            InvalidToken:
              value:
                status: 400
                code: INVALID_TOKEN
                message: Only bearer token is supported

[hdamker]

sinkCredentials are currently within the Design Guidelines quite restricted. Added here to the descriptions.

[jlurien]

You have to correct as well: bearerFormat: "{$request.body#/webhook/notificationAuthToken}" -> bearerFormat: "{$request.body#/sinkCredential.credentialType}"

[jlurien]

sinkCredentials are currently within the Design Guidelines quite restricted. Added here to the descriptions.

In QoD Provisioning I have adjusted the previous text to:

    * **Notification URL and token**:
    Developers may provide a callback URL (`sink`) on which notifications about all status change events (eg. provisioning termination) can be received from the service provider. This is an optional parameter. The notification will be sent as a CloudEvent compliant message. If `sink` is included, it is RECOMMENDED for the client to provide as well the `sinkCredential` property to protect the notification enpoint. In the current version,`sinkCredential.credentialType` MUST be set to `ACCESSTOKEN` if provided.

cc @maxl2287

[jlurien]

I have added also 410 as response to
callbacks:
notifications:
"{$request.body#/sink}":

As in the artifact because it has an explict reference to notifications:

Generic410:
  description: Gone
  headers:
    x-correlator:
      $ref: "#/components/headers/x-correlator"
  content:
    application/json:
      schema:
        $ref: "#/components/schemas/ErrorInfo"
      examples:
        GENERIC_410_GONE:
          description: Use in notifications flow to allow API Consumer to indicate that its callback is no longer available
          value:
            status: 410
            code: GONE
            message: Access to the target resource is no longer available.

[hdamker]

@maxl2287 The additions of Generic410 and Generic422 got mixed up ... may I ask to resolve the conflict?

[hdamker]

@hdamker shell I also update the BadRequest with the error-examples?

@maxl2287 the current Generic400 "BadRequest" is a copy from line 131ff of Commonalities/blob/main/artifacts/CAMARA_common.yaml and fits for the other endpoints.

INVALID_CREDENTIAL and INVALID_TOKEN are specific for createSession only - so I suppose you have to introduce and additional CreateSessionBadRequest400 similar as in the event-subscription-template?

@jlurien also relevant for #299