Error Formatting with OpenID/OAuth 2.0 Standards

[izahirclemencia]

Problem Description:
The current error formatting structure in the camera project diverges from the established standards of OpenID/OAuth 2.0. Although it includes fields like status, code, and message, as outlined in the provided ErrorInfo, it lacks key components such as error, error_description, and optionally error_uri, which are vital for effective error handling according to OpenID/OAuth 2.0 standards.

Here is the existing ErrorInfo structure:

ErrorInfo:
  type: object
  required:
    - status
    - code
    - message
  properties:
    status:
      type: integer
      description: HTTP response status code
    code:
      type: string
      description: Code given to this error
    message:
      type: string
      description: Detailed error description

Expected Behavior:
To ensure compliance with OpenID/OAuth 2.0 standards, the error formatting for the camera project should include the following fields:

• error: Represents the error code or identifier.
• error_description (optional): Provides a human-readable explanation of the error.
• error_uri (optional): Includes a URI that offers additional information about the error.

Alternative Solution:
Alternatively, to align with OpenID/OAuth 2.0 standards, the camera project's error formatting can be updated as follows:

error:
  type: object
  required:
    - error
    - error_description
  properties:
    error:
      type: string
      description: Error code or identifier.
    error_description:
      type: string
      description: Optional human-readable description of the error.
    error_uri:
      type: string
      description: Optional URI providing additional information about the error.

Additional Context:
These suggested modifications closely adhere to the specifications outlined in the OpenID/OAuth 2.0 standard. For further clarity, please refer to the documentation provided in RFC 6749 - The OAuth 2.0 Authorization Framework, Section 4.1.2.1.

[rartych]

Whenever OIDC and OAuth2 are used in CAMARA the error responses MUST follow the respective OIDF and IETF standard.
Please refer to #128 (comment)

Since this issue is recurring, it looks that Section 6 of API Design Guidelines needs to be updated.

[PedroDiez]

Please also refer to #129 (comment)

OIDC and OAuth2 have their own error formats and within CAMARA, Service APIs are defined whose error format is defined in Commonalities Design Guidelines, so as it has not to be the same as defined for OpenID/OAuth 2.0

[izahirclemencia]

Whenever OIDC and OAuth2 are used in CAMARA the error responses MUST follow the respective OIDF and IETF standard. Please refer to #128 (comment)

Since this issue is recurring, it looks that Section 6 of API Design Guidelines needs to be updated.

Which working group is responsible for this?

[izahirclemencia]

Please also refer to #129 (comment)

OIDC and OAuth2 have their own error formats and within CAMARA, Service APIs are defined whose error format is defined in Commonalities Design Guidelines, so as it has not to be the same as defined for OpenID/OAuth 2.0

If the CAMARA standard is to be adopted by others, it should be defined in the same manner as OpenID/OAuth 2.0 to ensure consistency and simplify integration.

[rartych]

To be indicated in PR #213