Page Comparison

...

For APIs that are targeting to become a stable public API, for M3, the Release Management team shall request a review by Commonalities and ICM teams.

...

ICM team review - details

THese These points are taken from: https://github.com/camaraproject/IdentityAndConsentManagement/issues/189#issuecomment-2315026741 )

...

•  Check the ICM-defined info.description template (Authorization and Authentication section).  Reference
  Example: Checked https://github.com/camaraproject/SimpleEdgeDiscovery/blob/r1.2/code/API_definitions/simple-edge-discovery.yaml#L203
•  Check the use of openIdConnect for securitySchemes. Reference
  Example: Checked https://github.com/camaraproject/SimpleEdgeDiscovery/blob/r1.2/code/API_definitions/simple-edge-discovery.yaml#L391
•  Check the use of the security property according to ICM definitions. Reference
  Example: Checked the one endpoint
  https://github.com/camaraproject/SimpleEdgeDiscovery/blob/r1.2/code/API_definitions/simple-edge-discovery.yaml#L253
•  Error codes are defined by Commonalities e.g. INVALID_TOKEN_CONTEXT.
  Example: https://github.com/camaraproject/SimpleEdgeDiscovery/blob/r1.2/code/API_definitions/simple-edge-discovery.yaml#L551
  However, the ICM could check the definition of a 403 INVALID_TOKEN_CONTEXT if it applies to a specific API (e.g. APIs using device object or phoneNumber in the API request). Reflects an inconsistency between information in some field of the API request and the access token.
  
•  ⚠️ OK with comments. The API specification has its own section Identifying the Device. The API specification does not include the recommended section called "Identifying a device from the access token" in info.description that provides a detailed description of the expected handling of the device object in the API request as it relates to the access token. It is specified in Appendix A: info.description template for device identification from access token and it is required for APIs that use the device object in the API requests.
  @Kevsy @crissancas @javierlozallu please check whether the recommended section is applicable
•  Verify that there is no unexpected leakage of users' personal information, such as API responses containing identifiers or information beyond the API functionality. 

Example: OK SimpleEdgeCloud , the API can be used to verify a phone number like NumberVerification does. Please see API misuse Commonalities#259. If Phone-Number is part of the SimpleEdgeCloud API request then response tells the API consumer the same as a request to NumberVerification does.

•  For APIs including a device object, check that Appendix A of the API-Design-Guidelines.md is respected: info.description template for device identification from access token

...

Q&A

• Who can approve the M3 release PR ? Code Owners after RM approval is noted in the release PR or its issue. 

• When to create a RM review issue ? when When the release-management_maintainers list is included as a reviewer in a release PR. 

• When do I tick a review issue task ?

  • Review actions: tick after checking the related file(s) and putting the review comment(s) in the PR/PR issue about the(se) files. Also put just OK for the file if no comments.

  • Also put a comment in the review issue with the major review comments and the overall state of the API.

  • Release actions: tick when task is done.

• When do we close the review issue ? When all tasks in the review issue are ticked as done. Close as completed.

• Question: should Should we add a milestone label so we can filter on it later ? 

• How to know if an APIs API is covered by RM ?  Use a comment in the comment fields of the API release tracker, visible on the Meta-release pageOnce a review issue is created it links to the PR. and should be visible in the comments.

• Is there a way to know if an API requires consent request ? No, this is local regulation. It is covered when using the security scheme and the scope rules.

Open questions

• should the test file files contain the API version number ? e.g. Feature: CAMARA Call Fowarding Signal  API, v0.1.0 - Operation call-forwardings - is it required to include the version (as people forget to update it) As the tests are in the same release package, can the version number be avoided in the test features ?

• can we automate test generation for an API - which tools ? - which ensures that all API spec errors/cases are covered by the tests ?

• add guideline to use error codes in scenario names ?