Enhance Subscription Provider Endpoint to Include EDC Configuration Details

[jjeroch]

Description: Our current system, which integrates Self-Sovereign Identity (SSI) and Enterprise Data Centers (EDCs), lacks a crucial feature that allows app/service providers who manage an EDC on behalf of a customer, to verify that the EDC is accurately configured to the customer's wallet rather than the service/app provider's wallet. To address this, we need to enhance the endpoint GET /api/apps/{appId}/subscription/{subscriptionId}/provider to return additional configuration details.

Acceptance Criteria:

1. The endpoint response must be extended to include a new section named externalService.
2. The externalService section should contain the following fields with their respective data types:
   • trusted_issuer (string)
   • participant_id (string)
   • iatp_id (string)
   • did_resolver (string)
   • decentralIdentityManagementAuthUrl (string)
   • decentralIdentityManagementServiceUrl (string)

"trusted_issuer" iatp address of the issuer (e.g. did:web:dim-static-prod.dis-cloud-prod.cfapps.eu10-004.hana.ondemand.com:dim-hosted:2f45795c-d6cc-4038-96c9-63cedc0cd266:holder-iatp) "participant_id" Subscription customer BPNL "iatp_id" iatp address of the holder (e.g. did:web:dim-static-prod.dis-cloud-prod.cfapps.eu10-004.hana.ondemand.com:dim-hosted:2f45795c-d6cc-4038-96c9-63cedc0cd266:holder-iatp) "did_resolver" URL of the didResolver available inside the env. variables (e.g. https://bpn-did-resolution-service.int.demo.catena-x.net/api/directory) "DecentralIdentityManagementAuthURL" is configured inside the environment variables and displays the DIM e.g.https://dis-integration-service-prod.eu10.dim.cloud.sap/api/v2.0.0/iatp/catena-x-portal "DecentralIdentityManagementServiceURL" should be fetched from the portal backend which displays the customer wallet instance url - e.g. https://bpnl0000000001j2-j2.authentication.eu10.hana.ondemand.com/

3. The data for these fields must be retrieved from the subscription customer's configuration.
4. Ensure that the endpoint response schema is updated accordingly and that the response correctly reflects these changes when the endpoint is called.
5. The implementation must ensure backward compatibility, not affecting existing functionalities or endpoint responses without the new section.
6. Appropriate unit and integration tests must be written to cover the new functionality.
7. Update the endpoint documentation to include the new externalService section with an explanation of each field.

Tasks:

• [ ] Analyze the current implementation of the subscription provider endpoint.
• [ ] Design the changes needed in the endpoint to include the externalService section.
• [ ] Implement the changes in the codebase.
• [ ] Update the endpoint tests to account for the new changes.
• [ ] Perform unit and integration testing.
• [ ] Update the endpoint documentation with the new changes.
• [ ] Conduct a thorough review to ensure backward compatibility.
• [ ] Deploy to a staging environment for final testing before production release.

---

Proposed new response body details:

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "offerSubscriptionStatus": "PENDING",
  "name": "string",
  "provider": "string",
  "contact": [
    "string"
  ],
  "technicalUserData": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "name": "string",
      "permissions": [
        "string"
      ]
    }
  ],
  "connectorData": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "name": "string",
      "endpoint": "string"
    }
  ],
  "externalService": {
    "trusted_issuer": "string",
    "participant_id": "string" (BPNL of the customer),
    "iatp_id": "string",
    "did_resolver": "string",
    "decentralIdentityManagementAuthUrl": "string",
    "decentralIdentityManagementServiceUrl": "string"
  }
}

---

Test Case 1: Retrieve Subscription Provider with EDC Configuration Details

Objective: Ensure the endpoint returns the enhanced response including the externalService section.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{subscriptionId}/provider.
2. Verify the response code is 200 OK.
3. Validate the response structure matches the updated schema including the externalService section.
4. Check that the externalService fields contain expected data types and values.

Expected Result: The response includes the externalService section with correct details fetched from the subscription customer's configuration.

---

Test Case 2: Validate Field Data Types in externalService

Objective: Confirm that all fields in the externalService section have the correct data types.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{subscriptionId}/provider.
2. Verify that each field in the externalService section is of type string.

Expected Result: All fields in the externalService response are strings.

---

Test Case 3: Backward Compatibility

Objective: Ensure that the enhancement does not break existing functionality.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{subscriptionId}/provider using an API version that predates the enhancement.
2. Verify the response code is 200 OK.
3. Validate the response structure matches the original schema without the externalService section.

Expected Result: The response is as per the original schema and functionality remains unaffected for the old API version.

---

Test Case 4: Error Handling for Non-Existent Subscription

Objective: Verify that the endpoint handles requests for non-existent subscriptions correctly.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{nonExistentSubscriptionId}/provider.
2. Verify the response code is 404 Not Found.
3. Confirm the response message indicates that the subscription was not found.

Expected Result: The endpoint returns a 404 Not Found for non-existent subscriptions.

---

Test Case 5: Security and Authorization Check

Objective: Ensure that only authorized users can access the EDC configuration details.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{subscriptionId}/provider without proper authorization.
2. Verify the response code is 401 Unauthorized or 403 Forbidden.

Expected Result: Unauthorized users cannot retrieve EDC configuration details from the endpoint.

---

Test Case 6: Documentation and Schema Validation

Objective: Confirm that the endpoint documentation has been updated and the schema is valid.

Steps:

1. Review the updated endpoint documentation to ensure it includes the externalService section and its fields.
2. Validate the API schema against the documentation to ensure accuracy and completeness.

Expected Result: The documentation accurately reflects the endpoint's updated schema and functionality.

---

Test Case 7: Field Presence Validation

Objective: Check that all new fields in the externalService section are always present in the response.

Steps:

1. Make a GET request to /api/apps/{appId}/subscription/{subscriptionId}/provider.
2. Verify that all fields within the externalService section are present, regardless of whether they are populated or null.

Expected Result: The response always contains the externalService section with all expected fields.

[evegufy]

relates to https://github.com/eclipse-tractusx/sig-release/issues/731

[jjeroch]

@Phil91 can you please check once how the iatp and issuer id is getting created as part of GET /api/administration/companydata/decentralidentity/urls? ideally we use the same for this endpoint.

[evegufy]

@sachinargade123 @ciprianherciu it's ready for testing