Test Plan for Vendor Extensibility Feature

At this documentation you will have all information and related files and examples of test plan for this feature.

Test Case 1: Published API with vendor extensibility

Test ID: vendor_extensibility-1

Description:

This test case will check if a published API with vendorExt flag active and vendorSpecific, can be discovered by invoker with all vendorSpecific fields.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)
   2. This API includes "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
   1. includes supported-features with VendSpecQueryParams active (binary 010 -> string 2)

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • include vendor specific service in root of service api description.
   • include vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 100
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must include "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}

3. Response to Discover Request By Invoker:

   1. 200 OK response.
   2. Response body must follow DiscoveredAPIs data structure:
      • Check if DiscoveredAPIs contains the API Published previously
      • Check if contains the vendorSpecific keys

Test Case 2: Published API with vendor extensibility and discover with VendSpecQueryParams disabled

Test ID: vendor_extensibility-2

Description:

This test case will check if a published API with vendorExt flag active and vendorSpecific, but discovered filter only APIs without vendorSpecific parameter

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)
   2. This API includes "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • include vendor specific service in root of service api description.
   • include vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 100
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must include "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}
3. Response to Discover Request By Invoker:
   1. 404 Not Found response.
   2. Error Response Body must accomplish with ProblemDetails data structure with:
      • status 404
      • title with message "Not Found"
      • detail with message "API Invoker {api_invoker_id} has no API Published that accomplish filter conditions".
      • cause with message "No API Published accomplish filter conditions".

Test Case 3: Publish API with vendorExt active and discover without supported features filter

Test ID: vendor_extensibility-3

Description:

This test case will check if a published API with vendor extensions can be discovered by invoker but without verdorSpecific parameters if supported-features query parameter is not set properly

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)
   2. This API includes "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • include vendor specific service in root of service api description.
   • include vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 100
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must include "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}
3. Response to Discover Request By Invoker:
   1. 200 OK response.
   2. Response body must follow DiscoveredAPIs data structure:
      • Check if DiscoveredAPIs contains the API Published previously
      • Check NOT contains the vendorSpecific keys

Test Case 4: Publish API with vendorExt active but without vendorSpecifics

Test ID: vendor_extensibility-4

Description:

This test case will check if a published API with vendorExt flag active and without vendorSpecific gets a 400 Bad Request, because is not allowed by definition.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)
   2. This API NOT includes any "Vendor Specific" information.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • NOT INCLUDED vendor specific service in root of service api description.
   • NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 100
   • Use APF Certificate

Expected Result:

1. Response to Publish request must accomplish:
   1. 400 Bad Request
   2. Error Response Body must accomplish with ProblemDetails data structure with:
      • status 400
      • title with message "Bad Request"
      • detail with message "If and only if VendorExt feature is enabled, then vendor-specific fields should be defined".
      • cause with message "Vendor extensibility misconfiguration".

Test Case 5: Publish API with vendorExt inactive but with vendorSpecifics

Test ID: vendor_extensibility-5

Description:

This test case will check if a published API with vendorExt flag inactive and with vendorSpecific gets a 400 Bad Request, because is not allowed by definition.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)
   2. This API includes any "Vendor Specific" information.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • include vendor specific service in root of service api description.
   • include vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 000
   • Use APF Certificate

Expected Result:

1. Response to Publish request must accomplish:
   1. 400 Bad Request
   2. Error Response Body must accomplish with ProblemDetails data structure with:
      • status 400
      • title with message "Bad Request"
      • detail with message "If and only if VendorExt feature is enabled, then vendor-specific fields should be defined".
      • cause with message "Vendor extensibility misconfiguration".

Test Case 6: Published API without vendor extensibility discover with VendSpecQueryParams enabled

Test ID: vendor_extensibility-6

Description:

This test case will check if a published API with vendorExt flag inactive and vendorSpecific no presnet, but discovered filter only APIs with vendorSpecific parameter

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)
   2. This API NOT includes "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
   1. Supported-features: binary 010 -> string 2

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • NOT INCLUDED vendor specific service in root of service api description.
   • NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 00
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must NOT include any "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}

3. Response to Discover Request By Invoker:

   1. 404 Not Found response.
   2. Error Response Body must accomplish with ProblemDetails data structure with:
      • status 404
      • title with message "Not Found"
      • detail with message "API Invoker {api_invoker_id} has no API Published that accomplish filter conditions".
      • cause with message "No API Published accomplish filter conditions".

Test Case 7: Published API without vendor extensibility and discover with vendSpecQueryParams disabled

Test ID: vendor_extensibility-7

Description:

This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker filtering by vendSpecQueryParams.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 0)
   2. This API NOT includes any "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
   1. includes supported-features with VendSpecQueryParams active (binary 000 -> string 0)

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • NOT INCLUDE vendor specific service in root of service api description.
   • NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 0
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must NOT include "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}

3. Response to Discover Request By Invoker:

   1. 200 OK response.
   2. Response body must follow DiscoveredAPIs data structure:
      • Check if DiscoveredAPIs contains the API Published previously
      • Check if NOT contains any vendorSpecific keys

Test Case 8: Published API without vendor extensibility and discover without supported-features query parameter

Test ID: vendor_extensibility-8

Description:

This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker without filtering by vendSpecQueryParams.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
   1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)
   2. This API NOT includes any "Vendor Specific" information at service API Description and inside AEF Profile.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
   1. NOT includes supported-features

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • NOT INCLUDE vendor specific service in root of service api description.
   • NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.
   • supportedFeatures 000
   • Use APF Certificate
3. Request Discover Published APIs:
   • Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}
   • Param api-invoker-id is mandatory
   • Use Invoker Certificate

Expected Result:

1. Response to Publish request must accomplish:

   1. 201 Created
   2. Response Body must follow ServiceAPIDescription data structure with:
      • apiId
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}
   4. Response must NOT include "vendorSpecific" keys inside root and at AEF Profile.

2. Response to Onboard request must accomplish:

   1. 201 Created
   2. Response Body must follow APIInvokerEnrolmentDetails data structure with:
      • apiInvokerId
      • onboardingInformation->apiInvokerCertificate must contain the public key signed.
   3. Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}

3. Response to Discover Request By Invoker:

   1. 200 OK response.
   2. Response body must follow DiscoveredAPIs data structure:
      • Check if DiscoveredAPIs contains the API Published previously
      • Check if NOT contains any vendorSpecific keys

Test Case 9: Publish API without supportedFeatures

Test ID: vendor_extensibility-9

Description:

This test case will check if a published API without supportedFeatures receives the 400 Bad Request, because is not allowed by definition.

Pre-Conditions:

• Network App was registered previously
• Network App was onboarded previously with {onboardingId}

Execution Steps:

1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker

Information of Test:

1. Perform Provider Registration and Invoker Onboarding
2. Publish Service API at CCF:
   • Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with apiName service_1
   • without supportedFeatures parameter.
   • Use APF Certificate

Expected Result:

1. Response to Publish request must accomplish:
   1. 400 Bad Request
   2. Error Response Body must accomplish with ProblemDetails data structure with:
      • status 400
      • title with message "Bad Request"
      • detail with message "supportedFeatures not present in request".
      • cause with message "supportedFeatures not present".