Fix issue #619 - Simplify usage of PrivateKeyJwtCredentials for event notification

[patrice-conil]

Simplify usage of PrivateKeyJwtCredentials for event notification by adding clientId, tokenUri and jwksUri to PrivateKeyJwtCredentials

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

By integrating all the necessary information into PrivateKeyJwtCredentials, it is no longer necessary to specify it via the Operate API. Parameter changes do not require any modification of the contractual data.

Which issue(s) this PR fixes:

Fixes #619

Does this PR introduce a breaking change?

• Yes
• No

Special notes for reviewers:

Changelog input

 Add clientId, tokenUri and jwksUri to PrivateKeyJwtCredentials into CAMARA_event_common.yaml (request part)
 Add also sinkCredential of type PrivateKeyJwtCredentials into sample-service-subscriptions.yaml (response part)

Additional documentation

[rartych]

@patrice-conil Thanks for the proposal.
I think the guideline document should be also updated in 4.3.1 Pre-requisites for using credential type PRIVATE_KEY_JWT
and diagram in Appendix A

[rartych]

Probably the sinkCredential needs to be added also in sample-implicit-events.yaml around line 313 (Resource response)

        sinkCredential:
          $ref: "../common/CAMARA_event_common.yaml#/components/schemas/PrivateKeyJWTCredential"

[patrice-conil]

Probably the sinkCredential needs to be added also in sample-implicit-events.yaml around line 313 (Resource response)

        sinkCredential:
          $ref: "../common/CAMARA_event_common.yaml#/components/schemas/PrivateKeyJWTCredential"

Thanks @rartych,
Once again, being fast is not the same as being reliable... property added in sample-implicit-events.yaml.

[rartych]

Thanks @patrice-conil for quick reactions!
There is also one suggestion from my side regarding Guide document - fill free to modify it.

[rartych]

@m-nahum Please review the changes (somehow I cannot add you to reviewers here)

[PedroDiez]

When renderizing it (e.g. via redocly), it appears as well ACCESSTOKEN option.

Maybe it is better to reference common sinkCredential schema in api-templates responses
(we decided to take out based on data minimization paradigm):

sinkCredential:
  $ref: "../common/CAMARA_event_common.yaml#/components/schemas/sinkCredential"

and control somehow what is returned in case of ACCESSTOKEN option (in the same fashion as Rafal commented for PrivateKeyJWTCredential

Proposal - within "AccessTokenCredential" schema, make writeOnly:

• accessTokenType
• accessToken

So as an implementation that decides to return sinkCredential of ACCESSTOKEN (when settled) also provides accessTokenExpiresUtc (if it decides to not return sinkCredential, as per data minimization paradigm, no problem because it is API Consumer info).

In that way, i think makes it easier for validation tools and clearer for developers

Based on that, I can make/define alternative artifact tests to cover both approaches to make it clear for API implementations based on their decision in PR #626

[PedroDiez]

cc @rartych

[patrice-conil]

Thanks @PedroDiez,
Suggestions included in new commit