From d527ce58c9684c3a963abc56221251926eba28aa Mon Sep 17 00:00:00 2001
From: Jorge <jorge.moratinossalcines@telefonica.com>
Date: Thu, 3 Apr 2025 07:26:37 +0000
Subject: [PATCH] Deployed 1f1e07a to develop in public with MkDocs 1.6.1 and
mike 2.1.3
---
public/develop/404.html | 15 ++--
public/develop/FAQ/index.html | 15 ++--
.../develop/api-status/api-status/index.html | 15 ++--
public/develop/architecture/index.html | 15 ++--
.../configuration/configuration/index.html | 15 ++--
.../develop/contribute/documenting/index.html | 15 ++--
.../event-filter/event-filter/index.html | 15 ++--
.../example-clients/index.html | 15 ++--
.../gettingstarted/howtorun/index.html | 15 ++--
.../gettingstarted/repository/index.html | 15 ++--
public/develop/helper/helper/index.html | 15 ++--
public/develop/helper/swagger/index.html | 15 ++--
public/develop/index.html | 15 ++--
public/develop/register/register/index.html | 15 ++--
public/develop/register/swagger/index.html | 15 ++--
public/develop/releasenotes/index.html | 18 +++--
.../develop/sandbox/relevantinfo/index.html | 15 ++--
.../develop/sandbox/requestaccess/index.html | 15 ++--
public/develop/sandbox/sandbox/index.html | 15 ++--
public/develop/sdk/sdk/index.html | 15 ++--
public/develop/search/search_index.json | 2 +-
public/develop/sitemap.xml | 72 +++++++++---------
public/develop/sitemap.xml.gz | Bin 543 -> 543 bytes
public/develop/testing/postman/index.html | 15 ++--
.../develop/testing/robotframework/index.html | 15 ++--
.../api_access_control_policy/index.html | 15 ++--
.../testplan/api_auditing_service/index.html | 15 ++--
.../testplan/api_discover_service/index.html | 15 ++--
.../testplan/api_events_service/index.html | 15 ++--
.../api_invoker_management/index.html | 15 ++--
.../testplan/api_logging_service/index.html | 15 ++--
.../api_provider_management/index.html | 15 ++--
.../testplan/api_publish_service/index.html | 15 ++--
.../testplan/api_security_service/index.html | 15 ++--
.../testing/testplan/api_status/index.html | 15 ++--
.../testplan/common_operations/index.html | 15 ++--
.../testing/testplan/event_filter/index.html | 15 ++--
public/develop/testing/testplan/index.html | 15 ++--
.../testplan/vendor_extensibility/index.html | 15 ++--
.../develop/vendor-ext/vendor-ext/index.html | 15 ++--
40 files changed, 373 insertions(+), 259 deletions(-)
diff --git a/public/develop/404.html b/public/develop/404.html
index 26049c1..2e7a9e7 100644
--- a/public/develop/404.html
+++ b/public/develop/404.html
@@ -16,7 +16,7 @@
<link rel="icon" href="/develop/images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -120,11 +120,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -156,6 +158,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/FAQ/index.html b/public/develop/FAQ/index.html
index e4145f6..da80045 100644
--- a/public/develop/FAQ/index.html
+++ b/public/develop/FAQ/index.html
@@ -20,7 +20,7 @@
<link rel="icon" href="../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -129,11 +129,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -165,6 +167,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/api-status/api-status/index.html b/public/develop/api-status/api-status/index.html
index a69bd73..52602c6 100644
--- a/public/develop/api-status/api-status/index.html
+++ b/public/develop/api-status/api-status/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/architecture/index.html b/public/develop/architecture/index.html
index e80a68b..07bdcea 100644
--- a/public/develop/architecture/index.html
+++ b/public/develop/architecture/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/configuration/configuration/index.html b/public/develop/configuration/configuration/index.html
index 87d4412..529b5cd 100644
--- a/public/develop/configuration/configuration/index.html
+++ b/public/develop/configuration/configuration/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/contribute/documenting/index.html b/public/develop/contribute/documenting/index.html
index 6563cc9..3dd69f9 100644
--- a/public/develop/contribute/documenting/index.html
+++ b/public/develop/contribute/documenting/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/event-filter/event-filter/index.html b/public/develop/event-filter/event-filter/index.html
index 1df48f9..736e918 100644
--- a/public/develop/event-filter/event-filter/index.html
+++ b/public/develop/event-filter/event-filter/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/example-clients/example-clients/index.html b/public/develop/example-clients/example-clients/index.html
index fe71764..1ba8e3d 100644
--- a/public/develop/example-clients/example-clients/index.html
+++ b/public/develop/example-clients/example-clients/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/gettingstarted/howtorun/index.html b/public/develop/gettingstarted/howtorun/index.html
index 2b3783d..1df1df1 100644
--- a/public/develop/gettingstarted/howtorun/index.html
+++ b/public/develop/gettingstarted/howtorun/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/gettingstarted/repository/index.html b/public/develop/gettingstarted/repository/index.html
index 756d433..1b287a6 100644
--- a/public/develop/gettingstarted/repository/index.html
+++ b/public/develop/gettingstarted/repository/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -122,11 +122,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -158,6 +160,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/helper/helper/index.html b/public/develop/helper/helper/index.html
index 0cbfdfc..c8082f6 100644
--- a/public/develop/helper/helper/index.html
+++ b/public/develop/helper/helper/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/helper/swagger/index.html b/public/develop/helper/swagger/index.html
index a752a1d..e191573 100644
--- a/public/develop/helper/swagger/index.html
+++ b/public/develop/helper/swagger/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/index.html b/public/develop/index.html
index 96a9cbd..76ee15d 100644
--- a/public/develop/index.html
+++ b/public/develop/index.html
@@ -20,7 +20,7 @@
<link rel="icon" href="images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -129,11 +129,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -165,6 +167,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/register/register/index.html b/public/develop/register/register/index.html
index d250229..6146e82 100644
--- a/public/develop/register/register/index.html
+++ b/public/develop/register/register/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/register/swagger/index.html b/public/develop/register/swagger/index.html
index 128ca4a..6c16b5b 100644
--- a/public/develop/register/swagger/index.html
+++ b/public/develop/register/swagger/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/releasenotes/index.html b/public/develop/releasenotes/index.html
index 695ff13..c84d35f 100644
--- a/public/develop/releasenotes/index.html
+++ b/public/develop/releasenotes/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
@@ -2176,6 +2179,9 @@
<li>New Event Filter test suite with 8 tests. <a href="../testing/testplan/event_filter/">Event Filter test suite</a></li>
</ul>
<h3 id="technical-debt-solved"><strong>Technical Debt Solved</strong></h3>
+<ul>
+<li>Implemented in the API Provider Management the supported features negotiation for the suppFeat field during provider registration. The server now decodes the negotiated feature set based on client capabilities and system support.</li>
+</ul>
<h4 id="hardening-on-startup-scripts-for-services-interacting-with-vault"><strong>Hardening on startup scripts for services interacting with Vault</strong></h4>
<p>The startup scripts of the <strong><em>Invoker Management Service</em></strong>, <strong><em>Provider Management Service</em></strong>, and <strong><em>Security Service</em></strong> have been improved to ensure reliability when the Vault service takes longer to become ready. These new scripts check responses from the Vault to ensure the returned information is valid before starting each service.</p>
<p>This will also helps on the restart issue on k8s deployed OpenCAPIF.</p>
diff --git a/public/develop/sandbox/relevantinfo/index.html b/public/develop/sandbox/relevantinfo/index.html
index d3a4cfd..b351461 100644
--- a/public/develop/sandbox/relevantinfo/index.html
+++ b/public/develop/sandbox/relevantinfo/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/sandbox/requestaccess/index.html b/public/develop/sandbox/requestaccess/index.html
index 2d61a91..845ce98 100644
--- a/public/develop/sandbox/requestaccess/index.html
+++ b/public/develop/sandbox/requestaccess/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/sandbox/sandbox/index.html b/public/develop/sandbox/sandbox/index.html
index d481015..3a58a9a 100644
--- a/public/develop/sandbox/sandbox/index.html
+++ b/public/develop/sandbox/sandbox/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/sdk/sdk/index.html b/public/develop/sdk/sdk/index.html
index cf33a0b..b34bff8 100644
--- a/public/develop/sdk/sdk/index.html
+++ b/public/develop/sdk/sdk/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/search/search_index.json b/public/develop/search/search_index.json
index 4a11499..f80ae6d 100644
--- a/public/develop/search/search_index.json
+++ b/public/develop/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Introduction","text":""},{"location":"#what-is-opencapif","title":"What is OpenCAPIF?","text":"<p>OpenCAPIF is an open source implementation of the CAPIF Core Function APIs plus the logic and additional services required to fulfill the 3GPP requirements and deliver the expected functionality.</p> <p>CAPIF is the \u201cCommon API Framework\u201d defined by 3GPP to manage the APIs exposed by 3GPP networks in their northbound interfaces.</p> <p>3GPP specifications for CAPIF defines three types of entities:</p> <ul> <li>API Providers, which are the entities exposing APIs (e.g., NEF)</li> <li>API Invokers, which are the entities that consume APIs (e.g., Applications), and</li> <li>the CAPIF Core Function, which manages the relationships between the other two.</li> </ul> <p></p> <p>The CAPIF Core Function is the cornerstone of the Common API Framework and provides the following capabilities:</p> <ul> <li>Authenticating the API Invoker based on its identity and other information;</li> <li>Supporting mutual authentication with the API Invoker;</li> <li>Providing authorization for the API Invoker prior to accessing the exposed APIs;</li> <li>Publishing, storing, and supporting the discovery of service APIs information;</li> <li>Controlling the service API access based on PLMN operator configured policies;</li> <li>Storing the logs for the service API invocations and providing the service API invocation logs to authorized entities;</li> <li>Charging based on the logs of the service API invocations;</li> <li>Monitoring the service API invocations;</li> <li>Onboarding a new API Invoker and offboarding an API Invoker;</li> <li>Storing policy configurations related to CAPIF and service APIs;</li> <li>Support for accessing the logs for auditing (e.g., detecting abuse); and</li> <li>Support for publishing and discovery of service APIs information among CAPIF Core Function (CAPIF interconnection).</li> </ul> <p>The following diagram shows how API Invokers and API Providers interact with the CAPIF Core Function to Register in CAPIF, Publish APIs, Discover APIs and Consume APIs. It is important to highlight that the CAPIF Core Function is not a classical API Gateway. The API consumption takes place directly between the API Invoker and the API Provider. Therefore, CAPIF does not impact API performance in API consumption between API Invokers and API Providers.</p> <p></p> <p>If you want to know more about OpenCAPIF check The story behind openCAPIF</p>"},{"location":"#repository-structure","title":"Repository structure","text":"<p>You can check the code at OpenCAPIF Repository</p> <pre><code>CAPIF_API_Services\n\u2514\u2500\u2500\u2500helm\n\u2514\u2500\u2500\u2500monitoring\n\u2514\u2500\u2500\u2500services\n\u2514\u2500\u2500\u2500tests\n\u2514\u2500\u2500\u2500tools\n \u2514\u2500\u2500\u2500robot\n \u2514\u2500\u2500\u2500open_api_script\n</code></pre> <ul> <li>helm: This folder contains helm files to deploy capif under k8s environment.</li> <li>monitoring: This folder contains grafana helm files to deploy capif under k8s environment.</li> <li>services: Services developed following CAPIF API specifications. Also, other complementary services (e.g., NGINX and JWTauth services for the authentication of API consuming entities).</li> <li>tools: Auxiliary tools. Robot Framework related code and OpenAPI scripts.</li> <li>test: Tests developed using Robot Framework.</li> </ul>"},{"location":"#capif_api_services","title":"CAPIF_API_Services","text":"<p>This repository has the python-flask Mockup servers created with openapi-generator related with CAPIF APIS defined here: Open API Descriptions of 3GPP 5G APIs</p>"},{"location":"#how-to-test-capif-apis","title":"How to test CAPIF APIs","text":"<p>The above APIs can be tested either with POSTMAN tool or running the developed tests with Robot Framework.</p>"},{"location":"#test-plan-documentation","title":"Test Plan Documentation","text":"<p>Complete documentation of tests is available here: Test Plan Directory</p>"},{"location":"#robot-framework","title":"Robot Framework","text":"<p>In order to ensure that modifications over CAPIF services still fulfills the required functionality, the Robot Framework Test Suite must be successfully run.</p> <p>The Robot Test Suite covers the requirements described in the test plan at Test Plan Directory folder.</p> <p>Please check the Testing with Robot Framework Section</p>"},{"location":"#using-postman","title":"Using PostMan","text":"<p>You can also test the CAPIF flow using the Postman tool. To do this, we have created a collection with some examples of CAPIF requests with everything necessary to carry them out.</p> <p>For more information on how to test the APIs with POSTMAN, go to this POSTMAN Section.</p>"},{"location":"#important-urls","title":"Important urls:","text":""},{"location":"#mongo-capifs-db-dashboard","title":"Mongo CAPIF's DB Dashboard","text":"<pre><code>http://localhost:8082/ (if accessed from localhost) \n\nor\n\nhttp://<Mongo CAPIF Express Host IP>:8082/ (if accessed from another host)\n</code></pre>"},{"location":"#mongo-registers-db-dashboard","title":"Mongo Register's DB Dashboard","text":"<pre><code>http://localhost:8083/ (if accessed from localhost) \n\nor\n\nhttp://<Mongo Register Express Host IP>:8083/ (if accessed from another host)\n</code></pre>"},{"location":"#faq-documentation","title":"FAQ Documentation","text":"<p>Frequently asked questions can be found here: FAQ Section</p>"},{"location":"FAQ/","title":"Frequently Asked Questions (FAQ)","text":""},{"location":"FAQ/#does-the-user-have-to-develop-the-3-elements-of-the-provider-aef-amf-and-apf","title":"Does the user have to develop the 3 elements of the provider (AEF, AMF and APF)?","text":"<p>No, you only have to make the request to the \"/onboarding\" endpoint. In it you must specify a CSR for the AEF, APF and AMF and you will receive the certificates for each of them in the response.</p>"},{"location":"FAQ/#there-is-one-party-that-publishes-the-api-and-another-that-exposes-it-what-is-the-difference","title":"There is one party that publishes the API and another that exposes it, what is the difference?","text":"<p>There are different services, the APF, intended for publishing the APIs, and the AEF, intended so that the invoker can call it. The APF is what connects to the Capif Core Function to publish the service and when the service is up, you need the AEF service so that invokers can connect to it.</p>"},{"location":"FAQ/#before-publishing-an-api-do-you-have-to-be-registered-in-capif","title":"Before publishing an API, do you have to be registered in CAPIF?","text":"<p>Yes, before publishing an API you must register using the POST /register endpoint.</p>"},{"location":"FAQ/#where-is-the-registration-done","title":"Where is the registration done?","text":"<p>Registration is done in a REST API outside of the CAPIF specification taht we have implemented.</p>"},{"location":"FAQ/#is-the-username-and-password-chosen-by-the-user-when-registering-or-is-it-assigned-when-requesting-registration-to-capif-public-instance","title":"Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?","text":"<p>When you make the request to the \"/endpoint\" of register, you will be returned a username and a password determined by CAPIF.</p>"},{"location":"FAQ/#what-is-a-csr","title":"What is a CSR?","text":"<p>A CSR is a Certificate Signing Request. It is a generated data block where the certificate is planned to be installed and contains key information such as public key, organization, and location, and is used to request a certificate from a certificate authority (CA). In CAPIF, 3 CSRs are necessary to register a provider, for AEF, APF and AMF.</p>"},{"location":"FAQ/#when-doing-the-register_provider-where-can-i-find-the-csrs-that-are-generated","title":"When doing the register_provider where can I find the CSRs that are generated?","text":"<p>When using the \"register_provider\" command, if you add the \"debug\" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.</p>"},{"location":"FAQ/#how-to-use-the-example-client-capif_invoker_gui","title":"How to use the example client (CAPIF_INVOKER_GUI)?","text":"<p>First you have to make a \"./run.sh host:port\" indicating the address of the public CAPIF. Once the Docker containers are up, you have to do a \"./terminal_to_py_netapp.sh\" and then a \"python main.py\". At this point we will find ourselves in a console with some predefined commands to use the Client. If we press tab twice it will bring up the list of available commands.</p>"},{"location":"FAQ/#where-is-the-capif-public-instance-located","title":"Where is the CAPIF public instance located?","text":"<p>The CAPIF public instance can be found at the following URLs: - capif.mobilesandbox.cloud:37211 (HTTPS) - capif.mobilesandbox.cloud:37212 (HTTP)</p>"},{"location":"FAQ/#do-you-have-to-publish-3-apis-one-for-each-instance","title":"Do you have to publish 3 APIs? one for each instance?","text":"<p>No, you only have to publish a single API but each component is responsible for a specific service, whether publishing or exposing.</p>"},{"location":"FAQ/#once-the-api-is-published-is-it-always-active-or-do-you-have-to-republish-it-every-time-you-want-to-use-it","title":"Once the API is published, is it always active? Or do you have to republish it every time you want to use it?","text":"<p>It is better to unsubscribe the API every time you exit the application since otherwise it could be republished and it would be double.</p>"},{"location":"FAQ/#would-the-same-username-and-password-be-valid-for-different-invokers","title":"Would the same username and password be valid for different invokers?","text":"<p>Yes, a user can have multiple invokers at the same time, and as such, the username and password would be the same.</p>"},{"location":"FAQ/#what-is-the-notfication-destination-field-in-the-register_invoker-request","title":"What is the notfication destination field in the register_invoker request?","text":"<p>This is the callback URL used to notify events. CAPIF has an Event service to subscribe to that notifies actions such as a subscription to an API, a change in the state of an API...</p>"},{"location":"FAQ/#is-the-notification_destination-a-required-field-in-the-register_invoker","title":"Is the notification_destination a required field in the register_invoker","text":"<p>No, it is not mandatory, but if you do not enter it you will not receive any CAPIF events. For example, the APF may delete the API, you will not be notified that the API is no longer available.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-discover_service-function-in-the-invoker-client","title":"What is the purpose of the \"discover_service\" function in the invoker client?","text":"<p>The discover_service returns a json with all the services that exist exposed in CAPIF at that moment.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-get_security_auth-function-in-the-invoker-client","title":"What is the purpose of the \"get_security_auth\" function in the invoker client?","text":"<p>Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-register_security_context-function-in-the-invoker-client","title":"What is the purpose of the \"register_security_context\" function in the invoker client?","text":"<p>To consume the API it is necessary to have a Security Context registered with the data and the authentication method.</p>"},{"location":"FAQ/#is-a-user-the-same-as-an-exposer","title":"Is a user the same as an exposer?","text":"<p>No, a user registers in CAPIF and once done can have the role of invoker, provider or both.</p>"},{"location":"FAQ/#where-can-i-put-my-endpoint","title":"Where can I put my endpoint?","text":"<p>You have to set your endpoint when doing the \"publish_service\" functionality: <code>publish_service capif_ops/config_files/service_api_description_hello.json</code></p> <p>In the file \"service_api_description_hello.json\" you configure the service that is going to be exposed and by developing one to suit you, you expose your API.</p>"},{"location":"architecture/","title":"Introduction","text":""},{"location":"architecture/#architecture","title":"Architecture","text":"<p>The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:</p> <p></p> <p>Each component is separated into different namespaces and all communications between them use Rest APIs.</p> <p>Apart from the communication between components, there are 2 other entities that can use them:</p> <ul> <li>Admin/superadmin: Responsible for managing users with the Register or carrying out special operations in the CCF.</li> <li>Users: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the CCF.</li> </ul>"},{"location":"architecture/#register-ns","title":"Register NS","text":"<p>This namespace belongs to the Register service, and we find 2 components:</p> <ul> <li>Register Service: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.</li> <li>Register MONGO DATABASE: It is the Register database, in it we store all the information about registered users.</li> </ul>"},{"location":"architecture/#vault-ns","title":"Vault NS","text":"<p>This namespace belongs to Vault. </p> <p>This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.</p>"},{"location":"architecture/#mon-ns","title":"Mon NS","text":"<p>This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:</p> <ul> <li>NGINX: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.</li> <li>REDIS: Used for internal communication of services.</li> <li>CAPIF MONGO DATABASE: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.</li> <li>HELPER: Service that simplifies integration with third parties such as external management portals.</li> </ul>"},{"location":"architecture/#new-architecture","title":"New Architecture","text":"<p>You can check the details of all these changes in the conversation on the OCF wiki.</p>"},{"location":"releasenotes/","title":"Release Notes","text":""},{"location":"releasenotes/#release-3xx","title":"Release 3.x.x","text":""},{"location":"releasenotes/#new-features","title":"New Features","text":""},{"location":"releasenotes/#added-event-filters","title":"Added Event Filters","text":"<ul> <li>Check Event Filter section</li> <li>New filters for Event service subscriptions.<ul> <li>You can now specify from which API, AEF, or Invoker you want to receive the event notifications.</li> <li>These filters are specified in the eventFilters of the subscription if the Enhanced Event Report feature of the Supported Features is activated.</li> </ul> </li> <li>More detailed information about event filters can be found in [Event Filter].</li> </ul>"},{"location":"releasenotes/#testing","title":"Testing","text":"<ul> <li>New Event Filter test suite with 8 tests. Event Filter test suite</li> </ul>"},{"location":"releasenotes/#technical-debt-solved","title":"Technical Debt Solved","text":""},{"location":"releasenotes/#hardening-on-startup-scripts-for-services-interacting-with-vault","title":"Hardening on startup scripts for services interacting with Vault","text":"<p>The startup scripts of the Invoker Management Service, Provider Management Service, and Security Service have been improved to ensure reliability when the Vault service takes longer to become ready. These new scripts check responses from the Vault to ensure the returned information is valid before starting each service.</p> <p>This will also helps on the restart issue on k8s deployed OpenCAPIF.</p>"},{"location":"releasenotes/#dynamic-configurations","title":"Dynamic configurations","text":"<ul> <li>Add new collection in CAPIF mongo with the init configuration.</li> <li>New endpoints in Helper to manage the CAPIF configuration.</li> <li>Add new collection in Register mongo with the init configuration.</li> <li>New endpoints in Register to manage the Register configuration.</li> <li>Documentation about Dynamic Configuration.</li> <li>Documentation about Helper and Register swaggers.</li> </ul>"},{"location":"releasenotes/#documentation","title":"Documentation","text":""},{"location":"releasenotes/#improvements-over-documentation","title":"Improvements over documentation","text":"<ul> <li>New Event Filter section</li> <li>New Vendor Extensibility section</li> <li>New API Status section</li> <li>New Dynamic Configuration section</li> </ul>"},{"location":"releasenotes/#testplan","title":"Testplan","text":"<ul> <li>New tests related with Api Status Feature.</li> <li>New tests related with Event Filter Feature.</li> <li>New tests related with Vendor Extensibility</li> <li>Security Service Testplan updated according to new features and Technical debts.</li> </ul>"},{"location":"releasenotes/#release-200","title":"Release 2.0.0","text":""},{"location":"releasenotes/#new-features_1","title":"New Features","text":""},{"location":"releasenotes/#upgrade-code-to-3gpp-capif-release-18","title":"Upgrade code to 3GPP CAPIF release 18","text":"<ul> <li>New endpoints included in new release 18 with new logic.</li> <li>Supported Features now are mandatory for all POST and PUT Requests as is described on TS 29.222. To keep in mind:<ul> <li>All POST/PUT request now must include Supported Features attribute, default can me set to <code>0</code> to keep all features inactive.</li> <li>On subscription to Event, if you need eventDetails information on notification you must activate Enhanced Event Report feature by setting properly the Supported Features flag.</li> </ul> </li> <li>Detailed information about models and endpoints upgrade on Upgrade Release 17 to 18 Wiki</li> </ul>"},{"location":"releasenotes/#vendor-extensibility","title":"Vendor Extensibility","text":"<ul> <li>Check Vendor Extensibility section</li> <li>Publish API:<ul> <li>On publishing a service API, SupportedFeatures is read and checked whether VendExt feature is enabled.</li> <li>When VendExt is enabled, vendor-specific fields are searched and stored in the db inside the ServiceAPIDescription object</li> <li>Vendor-specific fields are added according to the specific format:</li> </ul> </li> </ul> <pre><code>\n \"vendorSpecific-urn:<organization>:<field name>\": {\n \"key1\": \"value1\",\n ...\n \"keyN\": \"valueN\",\n }\n\n e.g. \n \"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n }\n\n where organization is \"etsi:mec\" and field name \"capifext:transport-info\"\n\n</code></pre> <ul> <li>Discover API:<ul> <li>On Discover request SupportedFeatures is read and checked whether VendSpecQueryParams feature is enabled.</li> <li>When VendSpecQueryParams is enabled, vendor-specific query parameters are parsed</li> <li>Vendor specific query parameters are added on the GET request according to the following format:</li> </ul> </li> </ul> <pre><code> https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-<query parameter name>={\n \"target\": <string that contains the JSON pointer to the attribute in the resource representation>, \n \"value\": <query parameter value>\n }\n\n e.g. \n https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-type={\n \"target\": \"/vendorSpecific-urn:etsi:mec:capifext:transport-info\", \n \"value\": \"REST_HTTP\"\n }\n</code></pre>"},{"location":"releasenotes/#api-status-feature","title":"Api Status feature","text":"<ul> <li>Check API Status section</li> <li>New logic to support API Status feature on Publish and Events Services.</li> <li>Events API:<ul> <li>Event internal notifications between services improved to accomplish specification.</li> <li>On event subscription SupportedFeatures is read and stored in db to accomplish specification.</li> <li>Also SupportedFeatures is checked before send event notification, in order to accomplish specification, sending eventDetails and related information according to enhanced_event_report and apiStatusMonitoring supported features activated.</li> </ul> </li> </ul>"},{"location":"releasenotes/#remote-scripts","title":"Remote Scripts","text":"<p>New scripts developed to help on remote deployment, configuration and testing. All this script are stored under helm/scripts in capif repository.</p> <p>variables.sh contains all configuration that will be used on remote operation. This file must be filled carefully before run remote scripts.</p> <ul> <li> <p>Deployment Scripts:</p> <ul> <li>install_vault.sh: Deploy Vault component from k8s cluster, only needed if vault is not previously deployed. If it\u2019s deployed you can setup vault token on variables.sh.</li> <li>install_monitoring.sh: Deploy monitoring on k8s cluster.</li> <li>install_capif.sh: Deploy OpenCAPIF on k8s cluster. It will be deployed on configured namespace with domain and hostnames configured under variables.sh.</li> <li>uninstall_vault.sh: Rollback Vault component from k8s cluster.</li> <li>uninstall_monitoring.sh: Rollback monitoring components from k8s cluster.</li> <li>uninstall_capif.sh: Rollback OpenCAPIF from k8s cluster.</li> </ul> </li> <li> <p>Manage remote users:</p> <ul> <li>create_remote_users.sh: This script create users setup by parameters on deployed OpenCAPIF. Those users are created by administrator.</li> <li>remove_remote_users.sh: This script removes user from deployed OpenCAPIF.</li> <li>remove_remote_users_by_prefix.sh:: This script removes users by prefix.</li> </ul> </li> <li> <p>Configuration of bastion machine, this simplify DNS fixed resolution:</p> <ul> <li>get_ingress.sh: This create a configuration for dns fixed resolution for ingress configured in namespace passed by parameters.</li> <li>set_ingress.sh: This scripts adds to /etc/hosts the fixed DNS resolution for ingress setup for namespace passed by parameters.</li> </ul> </li> <li> <p>Execute robot tests over remote deployment.</p> <ul> <li>run_remote_capif_tests.sh: This scripts launch Robot Test docker image on current machine to reach deployed OpenCAPIF. Is useful to launch with \u201c--include smoke\u201d in order to ensure all is deployed properly.</li> </ul> </li> <li> <p>Just for testing, next scripts upload dummy information to deployed OpenCAPIF:</p> <ul> <li>populate_create_remote_dummy_users.sh: : Create Dummy providers and invokers, publish service APIs and creates security context for invokers.</li> <li>populate_remove_remote_dummy_users.sh: Remove dummy information created.</li> </ul> </li> </ul>"},{"location":"releasenotes/#new-tools-and-components","title":"New Tools and Components","text":""},{"location":"releasenotes/#sdk","title":"SDK","text":"<p>New Python SDK is developed in order to simplify the creation and operation of providers and invokers. Please check the SDK repository for more information, there you can get more information about how to use it and also how to contibute to it.</p>"},{"location":"releasenotes/#provider-and-invoker-example-clients","title":"Provider and Invoker example Clients","text":"<p>In order to help developers to create their own invokers/providers entities and try the behavior of the OpenCAPIF, we also add to the OCF respository two example with console interaction at example clients repository:</p> <ul> <li>invoker-cli</li> <li>provider-cli</li> </ul> <p>More information on README of each component.</p>"},{"location":"releasenotes/#testing_1","title":"Testing","text":"<ul> <li>New Vendor Extensibility test suite with 9 tests. Api Events Service</li> <li>New API Status feature test suite with 20 tests.</li> <li>Improved Events test suite with 8 new tests.</li> <li>Test plan updated with default supported features for all request set to \"0\" (all inactive by default) See common operations.</li> </ul>"},{"location":"releasenotes/#technical-debt-solved_1","title":"Technical Debt Solved","text":""},{"location":"releasenotes/#local-scripts","title":"Local Scripts","text":"<ul> <li>All scripts were reviewed and improved.</li> <li>New scripts to manage users on local deployment added:<ul> <li>create_users.sh: This script create users setup by parameters in local deployment.. Those users are created by administrator.</li> <li>remove_users.sh: This script removes user in local deployment.</li> </ul> </li> </ul>"},{"location":"releasenotes/#issues","title":"Issues","text":"<ul> <li>Solved issue to get ready REDIS on deployment: REDIS scheduled on start to allow receive notification since service is deployed.</li> <li>Solved problem removing service APIs published is provider register more than one APF.</li> <li>Solved Superadmin problem deleting service API published through helper service if provider is not present.</li> <li>Increased the overall stability, fixing some corner cases.</li> <li>Location headers now are filled in same way at all services that needs it.</li> <li>Security issues solved.</li> <li>Base docker images present on ETSI registry.</li> <li>Robot image uploaded to ETSI Registry.</li> </ul>"},{"location":"releasenotes/#documentation_1","title":"Documentation","text":"<ul> <li>Postman examples are updated, including flows.</li> <li>New tests are detailed descripted on Test plan section</li> <li>New Contribute section.</li> <li>New SDK Section</li> </ul>"},{"location":"releasenotes/#release-100","title":"Release 1.0.0","text":""},{"location":"releasenotes/#new-features_2","title":"New Features","text":""},{"location":"releasenotes/#registration-flow-improved","title":"Registration Flow improved","text":"<ul> <li>Eliminated access from CAPIF to the Register user database when onboarding is performed.</li> <li>Isolation between CCF and Register services, interaction now is only by HTTPS requested between Register, CCF and Vault.</li> <li>Eliminated the \"role\" in user creation.<ul> <li>Now a user can be an invoker or a provider at the same time</li> </ul> </li> <li>Administrator User:<ul> <li>New entity in charge of registering and managing users of the register service.</li> </ul> </li> <li>UUID to identify users.<ul> <li>When you create a user, a uuid is associated with it</li> <li>The uuid will be contained in the token requested by the user and will be used to relate invokers and providers with users.</li> </ul> </li> <li>Endpoints changed and created:<ul> <li>Administrator endpoints:<ul> <li>/createUser: /register endpoint changed to createUser. Used to register new users.</li> <li>/deleteUser: /remove endpoint changed to this. Used to delete users and all the entities they had created.</li> <li>/login: Allows administrator to log in to obtain the necessary tokens for their requests.</li> <li>/refresh: Retrieve new access token token.</li> <li>/getUsers: Returns the list with all registered users.</li> </ul> </li> <li>Customer User:<ul> <li>/getauth now also returns the urls needed to use CAPIF, used by customer.</li> </ul> </li> </ul> </li> <li> <p>Security improvements:</p> <ul> <li>/login uses basic auth with administrator credentials.</li> <li>/getauth uses basic auth with customer user credentials.</li> <li>Other requests use the administrator access token obtained from login.</li> </ul> </li> <li> <p>Current fields on user creation by administrator:</p> </li> </ul> <pre><code>required_fields = {\n \"username\": str,\n \"password\": str,\n \"enterprise\": str,\n \"country\": str,\n \"email\": str,\n \"purpose\": str\n}\n\noptional_fields = {\n \"phone_number\": str,\n \"company_web\": str,\n \"description\": str\n}\n</code></pre> <ul> <li>Test plan has been updated with the new register flow. Please check OCF Registration Flow</li> <li>Video with explanation and demonstration of new register flow New Registration Demo</li> </ul>"},{"location":"releasenotes/#new-opencapif-architecture","title":"New OpenCAPIF architecture","text":"<ul> <li>New arquitecture with separated namespaces for Vault, CCF and Register components. Communication between them now are only allowed by using REST APIs.</li> <li> <p>New helper service inside CCF, it will simplify integration with third parties like external management portals.</p> </li> <li> <p>Helper endpoints:</p> <ul> <li>/getInvokers : Get the list of invokers from CAPIF</li> <li>/getProviders: Get the list of providers from CAPIF</li> <li>/getServices : Get the list of services published in CAPIF</li> <li>/getSecurityContext : Get the list of security contexts from CAPIF</li> <li>/getEvents : Get the list of events subscriptions from CAPIF</li> <li>/deleteEntities: Removes all entities registered by a user from the register</li> </ul> </li> <li> <p>Security in the helper</p> <ul> <li>To make requests to the helper you will need a superadmin certificate and password.</li> </ul> </li> </ul>"},{"location":"releasenotes/#events-api-upgrade","title":"Events API Upgrade","text":"<ul> <li>The event management at CCF is improved, EventNotification include Event Details with required information.</li> <li>Events updated:<ul> <li>SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE with apiIds</li> <li>SERVICE_API_UPDATE with serviceAPIDescriptions</li> <li>API_INVOKER_ONBOARDED, API_INVOKER_UPDATED, API_INVOKER_OFFBOARDED with apiInvokerIds.</li> </ul> </li> <li>Events Included:<ul> <li>SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE with invocationLogs</li> </ul> </li> <li>Test plan include 7 new tests in order to check new events implemented and scenarios of each notification implemented, with a complete check of Event Notification.</li> <li>Test plan documentation includes the new event tests OCF Event test plan documentation.</li> </ul>"},{"location":"releasenotes/#inital-implementation-of-cicd","title":"Inital implementation of CI/CD","text":"<ul> <li>The inital implementation of CI/CD on gitlab was performed.</li> <li>Detailed information in the CICD Wiki.</li> <li>Implement initial CI/CD:<ul> <li>Description of the CI process.<ul> <li>In CI phase, created design, jobs and security checks when a branch is pushed.</li> <li>The CI has jobs as:<ul> <li>Linting code, unit test (if needed),</li> <li>Build and push artifacts (images) in Git OCI register</li> <li>Security checks,</li> <li>SCA, CVS, SAST</li> <li>The vulnerabilities are exposed in Merge Request panel to be solved.</li> </ul> </li> </ul> </li> <li>Description of the CD process:<ul> <li>Defined the environments to OCF.<ul> <li>Production env.</li> <li>Pre-production env.</li> <li>Validation env.</li> <li>Dev-1, dev-2\u2026 envs (ephemeral)</li> </ul> </li> <li>Defined the naming convention to OCF releases<ul> <li>Tag in prod: v0.0.1-release</li> <li>Tag non-prod: v0.0.1-rc</li> <li>Other tags: v0.0.1-test, v0.0.1-smt</li> </ul> </li> <li>Defined the jobs of CD<ul> <li>CD ensures the deployment in multiple envs. Therefore, the CD pipeline has deploy-ocf, delete-ocf (if needed) jobs</li> </ul> </li> </ul> </li> <li>ETSI HIVE Labs:<ul> <li>Designed, created and the Kuberntes OCF cluster is running to support OCFs deployments.</li> <li>Iterating with ETSI HIVE\u2019s support to solve computing issues.<ul> <li>CPU compatibilities with OCF services (MongoDB): Fixed</li> </ul> </li> </ul> </li> </ul> </li> </ul>"},{"location":"releasenotes/#documentation_2","title":"Documentation","text":""},{"location":"releasenotes/#improvements-on-documentation","title":"Improvements on documentation","text":"<ul> <li>Documentation stored in OCF Documentation Repository</li> <li>Continuous Integration included at repository for web documentation:<ul> <li>Develop version of documentation is automatically generated on each merge to develop branch.</li> <li>Tagged version from main create documentation with related tag as version.</li> </ul> </li> </ul>"},{"location":"releasenotes/#technical-debt-solved_2","title":"Technical Debt Solved","text":""},{"location":"releasenotes/#improved-testing-with-robot-in-order-to-cover","title":"Improved Testing with Robot in order to cover","text":"<ul> <li>Support of new Register flows.</li> <li>Allow different URLs for register, ccf and vault services.</li> <li>New Variables included to manage new architecture under test.</li> <li>Mock server developed to add the functionality of write tests involving notification from Service Under Test.</li> <li>Docker image improved generation and libraries upgraded to Robot Framework 7.</li> </ul>"},{"location":"releasenotes/#improved-security-on-db","title":"Improved security on DB","text":"<ul> <li>Credentials requested to access mongo databases.</li> <li>Credentials requested also by mongo-express.</li> </ul>"},{"location":"releasenotes/#scripts-upgraded","title":"Scripts upgraded","text":"<ul> <li>Docker compose version 2 used on them.</li> <li>New cleaning script developed.</li> <li>Scripts upgraded:<ul> <li>check_services_are_running.sh: Checks if all essential services (Vault, CCF and Register) are running.</li> <li>clean_capif_docker_services.sh: Shutdowns and removes all services essential services.</li> <li>clean_capif_temporary_files.sh: Removes temporaly files from local repository. </li> <li>run.sh: Launch Essential services locally using docker compose, also monitoring can be launched.</li> <li>run_capif_tests.sh: Launch Robot Framwork Tests.</li> <li>show_logs.sh: Show locally logs of Services running.</li> <li>run_mock_server.sh: Launch mock server locally on all interfaces. This axiliary server is only used by tagged mockserver tests on Robot Framework.</li> <li>clean_mock_server.sh: Remove mock server local deployment.</li> <li>deploy.sh: This script simplify the way to download capif repository.</li> </ul> </li> </ul>"},{"location":"releasenotes/#codebase-improvements","title":"Codebase Improvements","text":"<ul> <li>Documentation is now on splitted repository OCF Documentation Repository</li> <li>Test plan was moved to OCF Documentation Repository</li> <li>Obsolote data is removed.</li> <li>Repository Reorganization: Enhanced structure and maintainability with a better directory layout and clearer module separation.</li> <li>Code Quality Enhancements: Refactored code and fixed known issues</li> </ul>"},{"location":"releasenotes/#migration-to-gunicorn","title":"Migration to GUNICORN","text":"<ul> <li>Include production server on each microservice: Release 0 use Flask developer server, now we use GUNICORN.</li> </ul>"},{"location":"releasenotes/#release-00","title":"Release 0.0","text":"<p>The APIs included in Release 0.0 are:</p> <ul> <li>JWT Authentication APIs</li> <li>CAPIF Invoker Management API</li> <li>CAPIF Publish API</li> <li>CAPIF Discover API</li> <li>CAPIF Security API</li> <li>CAPIF Events API</li> <li>CAPIF Provider Management API</li> </ul> <p>This Release also includes a Robot Test Suite for all those services and a Postman Test Suite for simple testing.</p>"},{"location":"api-status/api-status/","title":"API Status Feature","text":"<p>The API Status feature, introduced in the 3GPP Common API Framework (CAPIF) technical specifications starting from Release 17, offers significant enhancements for operators and developers.</p> <p>This feature in OpenCAPIF provides real-time insights into the operational status of APIs, enabling stakeholders to quickly determine whether an API is functioning as expected. By improving API availability tracking, it helps users make more informed decisions about integration and usage.</p>"},{"location":"api-status/api-status/#how-it-works","title":"How it works","text":"<p>This new functionality is found in two CAPIF services, the publish service and the events service.</p>"},{"location":"api-status/api-status/#publish-service","title":"Publish service","text":"<p>The API Status in the publish service allows providers to show in which AEFs the published API is available.</p> <p>In order to use the API Status, it is necessary to have apiStatusMonitoring enabled in supportedFeatures when publishing an API. With this enabled, we can use the publication's apiStatus, which is composed of a list of AEF identifiers in which the API is available.</p> <p>This gives us 4 options for displaying the status of an API:</p> <ul> <li>If the apiStatus contains a list of aefIds, the api will be available on all aefs in the list.</li> <li>If the apiStatus contains an empty list of aefIds it means that the API is NOT available in any AEF.</li> <li>If the apiStatus is not used, it is understood that the api is available in all AEFs of the aefProfiles.</li> <li>If the apiStatusMonitoring was not supported, the api would be available in all AEFs in the aefProfiles.</li> </ul> <p>If apiStatusMonitoring is not supported and apiStatus is used to show API availability, a 400 error will be returned.</p>"},{"location":"api-status/api-status/#events-service","title":"Events service","text":"<p>The API Status within the Events service provides critical insights into the availability of subscribed services.</p> <p>Both API Invokers and Providers can subscribe to the SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE events to receive timely notifications about the operational status of an API, whether it becomes available or unavailable.</p> <p>Additionally, if the enhanced_event_report function is supported, the API description could be received as event details in the eventDetails field if apiStatusMonitoring is also enabled. This will make it easier for event subscribers to know if any changes have been made to the API, such as a change in API availability to other AEFs.</p>"},{"location":"configuration/configuration/","title":"CAPIF Dynamic Configuration","text":""},{"location":"configuration/configuration/#overview","title":"Overview","text":"<p>CAPIF supports dynamic configuration management, enabling modifications without requiring redeployment. This is achieved by storing configurations in MongoDB collections for both CAPIF and Register services, allowing CAPIF to retrieve and apply configuration changes dynamically.</p> <p>This new approach provides:</p> <ul> <li>Real-time configuration updates: Modify parameters on the fly.</li> <li>Extensibility: Add new parameters or sections dynamically.</li> <li>Improved flexibility: Reduce static configuration dependencies.</li> </ul>"},{"location":"configuration/configuration/#capif-configuration","title":"CAPIF Configuration","text":"<p>In the CAPIF MongoDB instance, it is included a collection of the configuration.</p> <pre><code>capif_configuration: {\n \"config_name\": \"default\",\n \"version\": \"1.0\",\n \"description\": \"Default CAPIF Configuration\",\n \"settings\": {\n \"certificates_expiry\": {\n ttl_superadmin_cert: \"4300h\",\n ttl_invoker_cert: \"4300h\",\n ttl_provider_cert: \"4300h\",\n },\n \"security_method_priority\": {\n oauth: 1,\n pki: 2,\n psk: 3\n },\n \"acl_policy_settings\": {\n allowed_total_invocations: 5,\n allowed_invocations_per_second: 10,\n allowed_invocation_time_range_days: 365\n }\n }\n}\n</code></pre>"},{"location":"configuration/configuration/#register-configuration","title":"Register Configuration","text":"<p>Similarly, the Register service includes a dynamic configuration stored in its MongoDB instance:</p> <pre><code>capif_configuration: {\n \"config_name\": \"default\",\n \"version\": \"1.0\",\n \"description\": \"Default Register Configuration\",\n \"settings\": {\n \"certificates_expiry\": {\n ttl_superadmin_cert: \"4300h\",\n }\n }\n}\n</code></pre>"},{"location":"configuration/configuration/#configuration-management-endpoints","title":"Configuration Management Endpoints","text":"<p>Both CAPIF and the register configuration are managed via API, the general configuration of CAPIF from the Helper service and the register configuration from the register. In both services these endpoints enable:</p> <ol> <li> <p>Retrieving the current configuration \u2013 View the existing settings stored in MongoDB.</p> </li> <li> <p>Modifying configuration parameters \u2013 Update specific values dynamically.</p> </li> <li> <p>Adding new configuration settings \u2013 Introduce additional parameters within existing sections or create entirely new sections in the configuration.</p> </li> </ol> <p>For more details, you can check the API documentation of the Helper and Register services:</p> <ul> <li>Helper Service API Documentation</li> <li>Register Service API Documentation</li> </ul>"},{"location":"contribute/documenting/","title":"Documenting","text":"<p>OpenCAPIF's documentation runs on MkDocs.</p>"},{"location":"contribute/documenting/#eligibility","title":"Eligibility","text":"<p>Documenting OpenCAPIF is limited to active contributors. So, if you:</p> <ol> <li>are an active member or participant;</li> <li>wish to contribute to it;</li> <li>you're ready!</li> </ol>"},{"location":"contribute/documenting/#system-and-structure","title":"System and Structure","text":"<p>MkDocs is a fast and simple static site generator that's geared towards building project documentation. Documentation source files are written in <code>Markdown</code>, and configured with a single <code>YAML</code> configuration file. Start by reading the introductory tutorial, then check the User Guide for more information.</p>"},{"location":"contribute/documenting/#how-does-it-work","title":"How does it work?","text":"<p>There are 2 ways to upgrade documentation published on the OCF Documentation website:</p> <ul> <li>Push any change on develop branch will force update of the develop version on the OCF Documentation website;</li> <li>Create a tag, this will create a version with the tag name on the OCF Documentation website.</li> </ul>"},{"location":"contribute/documenting/#branches","title":"Branches","text":"<p>This documentation repository has 2 protected branches:</p> <ul> <li>main: stable timeline on which tags are made;</li> <li>develop: edge timeline, also published on the OCF Documentation website.</li> </ul>"},{"location":"contribute/documenting/#structure","title":"Structure","text":"<p>In the <code>mkdocs.yml</code> file you will find the navigation structure of the documentation, there you can sections with sub-sections.</p> <p>For example:</p> <pre><code>nav:\n - Overview:\n - Introduction: index.md\n - Getting Started:\n - How to Run: ./gettingstarted/howtorun.md\n - Testing:\n - Test Plan: ./testing/testplan/README.md\n - Robot Framework: ./testing/robotframework/README.md\n - Postman: ./testing/postman/README.md\n - FAQ: ./FAQ.md\n</code></pre> <p>As you can see here, we have at the time of writing this page, 5 main sections:</p> <ul> <li>Overview: here we placed high-level information like version changelog, some initial scripts, ...;</li> <li>Getting Started: this section contains a simple way to start working with the project;</li> <li>Testing: detailed information of how to test OpenCAPIF, and test plan developed to ensure the code has all implemented functionality checked;</li> <li>Contribute: details about how to contribute code and docs;</li> <li>FAQ.</li> </ul> <p>Please take a moment to understand the current structure of the documentations and think to update after contributing if necessary.</p>"},{"location":"contribute/documenting/#main-page","title":"Main Page","text":"<p>The page shown first is at doc/index.md. That page should be updated with the latest changes of OpenCAPIF and should reference the version (useful shortcut is <code>{{{ documentation_version }}}</code>).</p>"},{"location":"contribute/documenting/#getting-started","title":"Getting Started","text":"<p>To contribute to OpenCAPIF's documentation, you need to follow these easy steps:</p> <p>1) Clone the Documentation repository with:</p> <pre><code>git clone https://labs.etsi.org/rep/ocf/documentation.git\n</code></pre> <p>2) Checkout the develop branch (incoming contributions are only accepted to the develop branch):</p> <pre><code>cd ./documentation\ngit checkout develop\n</code></pre> <p>3) Setup a virtual environment:</p> <ul> <li>On Linux/macOS:</li> </ul> <pre><code>python3 -m venv venv # Linux/macOS\nsource venv/bin/activate #Linux/macOS\n</code></pre> <ul> <li>On Windows:</li> </ul> <pre><code>python -m venv venv # Windows\nvenv\\Scripts\\activate # Windows\n</code></pre> <p>4) Setup a local <code>mkdocs</code> server by installing requirements:</p> <pre><code>python -m pip install -r requirements.txt\n</code></pre> <p>4) Wait for all downloads to finish and start the local <code>mkdocs</code> server:</p> <pre><code>mkdocs serve\n</code></pre> <p>5) Document! \ud83d\ude0a</p> <p>You should always make sure that the local MkDocs server terminal is not producing any <code>INFO</code>/<code>WARNING</code> messages regarding your contributions.</p>"},{"location":"contribute/documenting/#add-documentation-during-development","title":"Add Documentation During Development","text":"<p>To update the documentation properly during development, follow those additional steps:</p> <ol> <li>Create an issue on the documentation GitLab repository;</li> <li>Create a new branch with the develop branch as a source;</li> <li>Update the documentation and any relevant parts (ie: the <code>index.md</code> with new functionalities for the latest version or if a new test plan has been defined, remember to update the test plan documentation);</li> <li>Check if errors are not being produced by <code>mkdocs</code> locally;</li> <li>Commit and push changes to the new branch;</li> <li>Create a merge/pull request towards develop;</li> <li>Send the request for review and approval to at least one TSC Member.</li> </ol> <p>The documentation website supports branches, so your accepted changes will be reflected to the develop branch which then becomes the release branch after each corresponding cycle.</p>"},{"location":"contribute/documenting/#release-a-new-version-of-the-documentation","title":"Release a New Version of the Documentation","text":"<p>When OpenCAPIF code repository is ready for a new release, we need to follow these steps (made by a TSC Member):</p> <ol> <li>Create a PR from develop towards main;</li> <li>When develop is merged to main... then create a tag with the released version scheme... and you're done!</li> </ol>"},{"location":"event-filter/event-filter/","title":"Event Filter","text":"<p>The Event Filter is a feature of the CAPIF Events service that allows you to receive specific notifications about the events you are subscribed to. This tool is essential for efficiently managing and monitoring relevant events, ensuring that users receive only the information they need.</p>"},{"location":"event-filter/event-filter/#how-it-works","title":"How it works","text":"<p>To specify the desired filter during subscription, you can use the eventFilters field, provided that the Enhanced Event Report flag is enabled in the Supported Features characteristics.</p> <p>The eventFilters field consists of a list of filters that correspond one-to-one with the list of events in the events field. Thus, the first element of the filter list corresponds to the first element of the events list, the second filter element to the second event element, and so on.</p> <p>Each filter contains three lists:</p> <ul> <li>apiIds: Identifiers of the APIs from which you want to receive notifications.</li> <li>apiInvokerIds: Identifiers of the invokers from which you want to receive notifications.</li> <li>aefIds: Identifiers of the AEFs from which you want to receive notifications.</li> </ul> <p>Depending on the event you subscribe to, you can use one or more of these lists. The following table shows the filtering options available for each event:</p> Event apiIds aefIds apiInvokerIds SERVICE_API_AVAILABLE X SERVICE_API_UNAVAILABLE X SERVICE_API_UPDATE X API_INVOKER_ONBOARDED X API_INVOKER_OFFBOARDED X API_INVOKER_UPDATED X ACCESS_CONTROL_POLICY_UPDATE X X SERVICE_API_INVOCATION_SUCCESS X X X SERVICE_API_INVOCATION_FAILURE X X X API_TOPOLOGY_HIDING_CREATED API_TOPOLOGY_HIDING_REVOKED <p>In cases where 2 or 3 lists are specified simultaneously for an event, notifications will only be sent when there is at least one matching element in each of the subscription lists. For example, if you subscribe to the ACCESS_CONTROL_POLICY_UPDATE event using the apiIds and apiInvokerIds filter lists, you will only be notified when the access control policy update corresponds to an API in the apiIds list and an invoker in the apiInvokerIds list at the same time.</p>"},{"location":"example-clients/example-clients/","title":"Invoker and Provider CLIs","text":"<p>The Invoker and Provider CLIs serve as examples for developers and integrators looking to connect their Network Applications (NetApps) to CAPIF. </p> <p>They demonstrate, using Python, how to develop the necessary code for seamless communication with CAPIF, offering a practical guide to implementing the required API calls and interactions.</p>"},{"location":"example-clients/example-clients/#provider-cli","title":"Provider CLI","text":"<p>When using the Provider Console, users can create a provider entity that registers and publishes APIs to make them available within the CAPIF ecosystem. </p>"},{"location":"example-clients/example-clients/#commands","title":"Commands","text":"<p>With the provider console you can make the following requests to CAPIF:</p>"},{"location":"example-clients/example-clients/#provider_get_auth","title":"provider_get_auth","text":"<p>It is used to request the token and the ca_root certificate in order to perform the provider onboarding.</p> <pre><code>provider_get_auth <username> <password>\n</code></pre> <p>The token has an expiration time of 10 minutes, so if it expires you will have to request a new one.</p>"},{"location":"example-clients/example-clients/#register_provider","title":"register_provider","text":"<p>It is used to perform the onboarding of a provider.</p> <pre><code>register_provider <name>\n</code></pre> <p>This request uses the api_provider_domain.json file as a template and creates the certificates and keys for each of the entities that make up the Provider.</p>"},{"location":"example-clients/example-clients/#publish_service","title":"publish_service","text":"<p>It is used to publish an api as a provider.</p> <pre><code>publish_service <service file route>\n</code></pre> <p>For this request the demo_api_one.json file is used as a template.</p>"},{"location":"example-clients/example-clients/#get_services","title":"get_services","text":"<p>It is used to see what services the provider has published.</p> <pre><code>get_service \n</code></pre> <p>Returns a list of API names.</p>"},{"location":"example-clients/example-clients/#remove_service","title":"remove_service","text":"<p>It is used to unpublish an API.</p> <pre><code>remove_service <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#remove_provider","title":"remove_provider","text":"<p>It is used to remove the provider.</p> <pre><code>remove_provider\n</code></pre> <p>Once the provider is deleted, you will not be able to publish or perform other operations that require certificates.</p>"},{"location":"example-clients/example-clients/#additionally","title":"Additionally","text":"<p>In addition, an API example is provided with which you can see how the token used by invokers to use the API published by the provider is decrypted and used.</p> <p>Once the API is published, the file can be executed with the next command:</p> <pre><code>python3 service_oauth.py\n</code></pre> <p>With this, the API will be raised to be able to make the calls.</p>"},{"location":"example-clients/example-clients/#invoker-cli","title":"Invoker CLI","text":"<p>When using the Invoker Console, users can create an Invoker entity that discover APIs to consume them with the CAPIF ecosystem. </p>"},{"location":"example-clients/example-clients/#commands_1","title":"Commands","text":"<p>With the Invoker console you can make the following requests to CAPIF:</p>"},{"location":"example-clients/example-clients/#get_auth","title":"get_auth","text":"<p>It is used to request the token and CA cert to be able to perform the onboarding.</p> <pre><code>get_auth <username> <password>\n</code></pre> <p>The token has an expiration time of 10 minutes, so if it expires you will have to request a new one.</p>"},{"location":"example-clients/example-clients/#register_invoker","title":"register_invoker","text":"<p>It is usedd to perform the onboarding of an Invoker,</p> <pre><code>register_invoker <name>\n</code></pre> <p>This request uses the invoker_details.json file as a template and creates the certificate and keys of the Invoker.</p>"},{"location":"example-clients/example-clients/#discover_service","title":"discover_service","text":"<p>It is used to discover the APIs published in CAPIF.</p> <pre><code>discover_service\n</code></pre> <p>Returns a list with the names of the services published in CAPIF.</p>"},{"location":"example-clients/example-clients/#register_security_context","title":"register_security_context","text":"<p>It is used to make the request to create a security context.</p> <pre><code>register_security_context <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#get_security_auth","title":"get_security_auth","text":"<p>It is used to request the token necessary for the cunsumption of an API.</p> <pre><code>get_security_auth <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#call_service","title":"call_service","text":"<p>It is used to consume the API</p> <pre><code>call_service <api name> <method> <endpoint> <body route>\n</code></pre> <p>For the request you must specify the name of the API you want to use, the method and endpoint you want to consume, and the path of the body to use.</p>"},{"location":"example-clients/example-clients/#remove_security_context","title":"remove_security_context","text":"<p>It is used to delete the created security context.</p> <pre><code>remove_security_context\n</code></pre>"},{"location":"example-clients/example-clients/#remove_invoker","title":"remove_invoker","text":"<p>It is used to delete the Invoker</p> <pre><code>remove_invoker\n</code></pre> <p>Once the invoker is deleted, you will not be able to discover or perform other operations that require the Invoker certificate.</p>"},{"location":"example-clients/example-clients/#other-commands","title":"Other commands","text":"<p>Apart from these operations, with the Invoker and Provider console you can also perform operations as administrator if you have a CAPIF instance locally.</p>"},{"location":"example-clients/example-clients/#admin-commands","title":"Admin commands","text":"<p>As an administrator, you can manage which users can use CAPIF with the following commands.</p>"},{"location":"example-clients/example-clients/#login_admin","title":"login_admin","text":"<p>It is used to login as an administrator and obtain the tokenes needed to perform admin operations</p> <pre><code>login_admin <admin username> <admin password>\n</code></pre>"},{"location":"example-clients/example-clients/#refresh_admin","title":"refresh_admin","text":"<p>It is used to refresh the tokenes of the admin user</p> <pre><code>refresh_admin\n</code></pre>"},{"location":"example-clients/example-clients/#register_user","title":"register_user","text":"<p>It is used to register a new user</p> <pre><code>register_user\n</code></pre> <p>uses the data in the credentials.properties file as the data to record.</p>"},{"location":"example-clients/example-clients/#remove_user","title":"remove_user","text":"<p>It is used to remove the created user.</p> <pre><code>remove_user\n</code></pre>"},{"location":"example-clients/example-clients/#tips","title":"Tips","text":"<p>This section explains some tips that may be useful for developers who are using consoles.</p>"},{"location":"example-clients/example-clients/#help-command","title":"help command","text":"<p>In both consoles you can use the help command to display a list of available commands.</p> <pre><code>help\n</code></pre>"},{"location":"example-clients/example-clients/#exit-command","title":"exit command","text":"<p>In both consoles you can use the exit command to exit the console.</p> <pre><code>exit\n</code></pre>"},{"location":"example-clients/example-clients/#delete-the-entities","title":"Delete the entities","text":"<p>It is recommended to delete all providers, Invokers and users created by the consoles if they are not going to be used anymore.</p>"},{"location":"example-clients/example-clients/#debug-mode","title":"debug mode","text":"<p>You can add the debug flag at the end of each command to show the complete inputs and outputs of each request and thus better understand what is being done.</p> <pre><code>register_invoker ocf debug\n</code></pre>"},{"location":"gettingstarted/howtorun/","title":"How to Run","text":"<p>Capif services are developed under services folder.</p>"},{"location":"gettingstarted/howtorun/#downloading-the-project","title":"Downloading the project","text":"<p>You can easily download CAPIF to run in local environment following next steps:</p>"},{"location":"gettingstarted/howtorun/#1-create-a-folder-to-download-the-project","title":"1. Create a folder to download the project","text":"<pre><code>mkdir OpenCAPIF\n\ncd OpenCAPIF\n</code></pre>"},{"location":"gettingstarted/howtorun/#2-download-the-deployment-script","title":"2. Download the deployment script","text":"<p>Download the deployment / environment preparation script (press here to directly download script):</p> <pre><code>wget https://labs.etsi.org/rep/ocf/capif/-/raw/staging/deploy.sh\n</code></pre> <p>Make it executable:</p> <pre><code>chmod +x deploy.sh\n</code></pre>"},{"location":"gettingstarted/howtorun/#3-run-the-deployment-script","title":"3. Run the deployment script","text":"<p>This script selects the branch for capif repository project to pull from.</p> <p>If you run the script without selecting a branch the the main branch is going to be selected.</p> <p>We recommend:</p> <ul> <li>main branch for the most stable experience and staging branch for an experience with the latest features (for staging branch installation, it is strongly advisable that you may as well follow the staging documentation)</li> </ul> <pre><code># ./deploy.sh [branch to fetch] [true or false (default) to install monitoring stack or not]\n\nsudo ./deploy.sh staging\n</code></pre> <p>We recommend running the deploy.sh script with root permissions! In other case, some directories may not be accessible by the project building tools and hinder the smooth installation.</p>"},{"location":"gettingstarted/howtorun/#run-all-capif-services-locally-with-docker-images","title":"Run All CAPIF Services locally with Docker images","text":"<p>To run using docker and docker compose, version 2.10 or higher, you must ensure you have those tools installed in your machine. Also to simplify the process, we have 3 scripts allowing docker images to deploy, check and cleanup.</p> <p>All these scripts are available under services directory.</p> <p>To run CAPIF APIs locally using docker and docker-compose you can use run.sh script:</p> <pre><code>./run.sh -h\n\nUsage: ./run.sh <options>\n -c : Setup different hostname for capif\n -m : Launch monitoring service\n -h : show this help\n</code></pre> <p>This script builds and runs all services using docker images, including mongodb and nginx locally and in the background, and imports ca.crt to nginx. By default monitoring is not activated and Nginx is deployed use capifcore as a hostname.</p> <p>Some examples of use:</p> <pre><code># Default values, No monitoring and capifcore as CAPIF_HOSTNAME\n./run.sh\n\n# opencapif.etsi.org as CAPIF_HOSTNAME\n./run.sh -c opencapif.etsi.org\n\n# opencapif.etsi.org as CAPIF_HOSTNAME and monitoring activated\n./run.sh -c opencapif.etsi.org -m \n\n</code></pre> <p>IMPORTANT NOTE: In some versions change of hostname in local deployment (setting some value different than capifcore) creates wrong certificates on vault component. This prevents successful requests using the certificates. if this is your case, here is a little workaround to solve this issue meanwhile SDG is solving it:</p> <ul> <li>Modify the hostname in the file capif/services/vault/vault_prepare_certs.sh on lines 43, 68, and 95.</li> <li>Update the url parameter of the CCF from capifcore to the desired hostname in the file capif/services/register/config.yaml.</li> </ul> <p>If you want to check if all CAPIF services are running properly in a local machine after executing run.sh, you can use:</p> <pre><code>./check_services_are_running.sh\n</code></pre> <p>This shell script will return 0 if all services are running properly.</p> <p>When we need to stop all CAPIF services, we can use next bash script:</p> <pre><code>./clean_capif_docker_services.sh -a\n</code></pre> <p>NOTE: You can use different flags if you only want to stop some of them, please check the help using:</p> <pre><code>./clean_capif_docker_services.sh -h\n\nUsage: clean_capif_docker_services.sh <options>\n -c : clean capif services\n -v : clean vault service\n -r : clean register service\n -m : clean monitoring service\n -a : clean all services\n -h : show this help\n</code></pre> <p>This shell script will remove and clean all CAPIF services started previously with run.sh</p> <p>On the other hand you can check logs using show_logs.sh script, please check options:</p> <pre><code>./show_logs.sh\nYou must specify an option when running the script.\nUsage: ./show_logs.sh <options>\n -c : Show capif services\n -v : Show vault service\n -r : Show register service\n -m : Show monitoring service\n -a : Show all services\n -f : Follow log output\n -h : Show this help\n</code></pre> <p>You can also use option -f in order to follow log output in real time</p>"},{"location":"gettingstarted/howtorun/#run-all-capif-services-locally-with-docker-images-and-deploy-monitoring-stack","title":"Run All CAPIF Services locally with Docker images and deploy monitoring stack","text":"<p>It is now possible to deploy a monitoring stack for CAPIF with Grafana, Prometheus, FluentBit, Loki, Cadvisor, Tempo and Opentelemetry.</p> <p>To deploy CAPIF together with the monitoring stack, it is only necessary to execute the following.</p> <pre><code>./run.sh -m true\n</code></pre> <p>After they have been built, the different panels can be consulted in Grafana at the url</p> <pre><code>http://localhost:3000\n</code></pre> <p>By default, the monitoring option is set to false. Once up, all data sources and dashboards are automatically provisioned.</p>"},{"location":"gettingstarted/howtorun/#run-each-service-using-docker","title":"Run each service using Docker","text":"<p>Also you can run OpenCAPIF service by service using docker:</p> <pre><code>cd <Service>\ndocker build -t capif_security .\ndocker run -p 8080:8080 capif_security\n</code></pre>"},{"location":"gettingstarted/howtorun/#run-each-service-using-python","title":"Run each service using Python","text":"<p>Run using python</p> <pre><code>cd <Service>\npip3 install -r requirements.txt\npython3 -m <service>\n</code></pre>"},{"location":"gettingstarted/howtorun/#start-your-testing-with-opencapif","title":"Start Your Testing with OpenCAPIF","text":"<p>Related with OpenCAPIF Testing, the following sections help you to understand testing implemented and how to run it by yourself:</p> <ul> <li>Test Plan Directory: Here you can find the complete test plan definition that are accomplish by all versions released of OpenCAPIF.</li> <li>Testing with Robot Framework: At this section you can find all information about how to run the test suite implemented using Robot Framework.</li> <li>Testing with Postman: Easy way to understand the complete basic OpenCAPIF flow, acting as invoker and provider.</li> </ul>"},{"location":"helper/helper/","title":"Introduction to the Helper Service","text":""},{"location":"helper/helper/#overview","title":"Overview","text":"<p>CAPIF does not include any built-in mechanism to expose data via API. This makes it difficult to retrieve essential information such as the number of registered API Invokers, a list of available API Invokers, etc.</p> <p>Without a dedicated tool, accessing this data requires direct database queries, making it inefficient and impractical.</p>"},{"location":"helper/helper/#helper-service","title":"Helper Service","text":"<p>The Helper Service addresses this limitation by acting as an intermediary that exposes CAPIF\u2019s stored data in a structured and accessible manner. This service provides APIs that allow users to query the CAPIF database and obtain valuable insights, such as:</p> <ul> <li>The total count and details of registered API Invokers and API Providers.</li> <li>A structured and API-driven way to retrieve CAPIF-related information.</li> <li>Simplified access to important data without the need for direct database interactions.</li> <li>Access to security contexts, helping manage authentication and authorization processes.</li> <li>Retrieval of event records, providing insight into CAPIF system activities.</li> <li>The ability to delete different CAPIF entities, facilitating resource management.</li> <li>Full control over CAPIF dynamic configuration, including:<ul> <li>Retrieving the current configuration.</li> <li>Modifying specific parameters.</li> <li>Adding or updating configuration settings dynamically.</li> </ul> </li> </ul> <p>By this Helper Service, CAPIF users can effortlessly retrieve and manage critical system information, improving overall visibility and efficiency.</p>"},{"location":"helper/helper/#api-documentation","title":"API Documentation","text":"<p>For a detailed API reference, please check the Helper Service Swagger Documentation:</p> <p>\u27a1\ufe0f Helper Service API Documentation</p>"},{"location":"helper/swagger/","title":"Swagger","text":""},{"location":"helper/swagger/#helper-api-documentation","title":"Helper API Documentation","text":""},{"location":"register/register/","title":"Register Service","text":""},{"location":"register/register/#overview","title":"Overview","text":"<p>The Register Service is responsible for user management within the CAPIF ecosystem. It provides a structured way to register, authenticate, and manage user that interact with CAPIF, ensuring a secure and efficient process.</p>"},{"location":"register/register/#api-documentation","title":"API Documentation","text":"<p>For more details, refer to the API documentation:</p> <ul> <li>Register Service API Documentation</li> </ul>"},{"location":"register/swagger/","title":"Swagger","text":""},{"location":"register/swagger/#register-api-documentation","title":"Register API Documentation","text":""},{"location":"sandbox/relevantinfo/","title":"Relevant Information","text":"<p>This section provides users with essential details to interact with the OpenCAPIF Sandbox, including endpoint URLs, example requests, and client implementation references.</p>"},{"location":"sandbox/relevantinfo/#public-sandbox-urls","title":"Public Sandbox URLs","text":"<p>Below are the key endpoints required for API interactions within the sandbox environment:</p> <ul> <li>Registration Service: <code>https://register-opencapif.etsi.org</code></li> <li>OpenCAPIF Service: <code>https://opencapif.etsi.org</code></li> </ul>"},{"location":"sandbox/relevantinfo/#postman-collection-and-flows","title":"Postman collection and flows","text":"<p>To facilitate API testing and integration, we provide example requests that can be used in Postman:</p> <ul> <li>Postman Collection for OpenCAPIF: A ready-to-use collection with predefined requests to interact with the sandbox APIs including flows.</li> </ul>"},{"location":"sandbox/relevantinfo/#example-client-implementations","title":"Example Client Implementations","text":"<p>For users who wish to integrate OpenCAPIF into their applications, we provide invoker and provider example clients:</p> <ul> <li>Invoker Client: invoker-cli Repository</li> <li>Provider Client: provider-cli Repository</li> </ul> <p>These resources are continuously updated to align with the latest OpenCAPIF developments, ensuring users have access to functional and relevant examples.</p>"},{"location":"sandbox/relevantinfo/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sandbox/requestaccess/","title":"How to Request Access","text":"<p>To request access to the OpenCAPIF Sandbox, users can choose one of the following methods:</p> <ul> <li>Email Request: Send an email to OCF_TECH with the required information.</li> <li>Slack Channel: Contact us through the OpenCAPIF User an Developer Communities Slack channel #sandbox-access and provide the necessary details.</li> </ul>"},{"location":"sandbox/requestaccess/#required-information","title":"Required Information","text":"<p>Regardless of the method chosen, users must include the following details in their request:</p> <ul> <li>Company Name: The name of the organization requesting access.</li> <li>Purpose of Access: A brief description of why access is needed.</li> <li>Contact Information: Email address (mandatory), telephone number (optional).</li> <li>Preferred Username: A desired username for the account (subject to availability; may require modification if already in use).</li> </ul> <p>Once the request is received, the OpenCAPIF team will review the details and provide the necessary credentials or follow up if additional information is required.</p>"},{"location":"sandbox/requestaccess/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sandbox/sandbox/","title":"Introduction","text":"<p>The OpenCAPIF Sandbox is a dedicated environment designed to allow developers, researchers, and potential users to explore and test the latest developments in OpenCAPIF. This controlled setting provides a safe and isolated space to interact with OpenCAPIF APIs, ensuring that users can evaluate functionalities, experiment with integrations, and validate use cases without affecting live systems.</p>"},{"location":"sandbox/sandbox/#benefits-of-using-the-sandbox","title":"Benefits of Using the Sandbox","text":"<ul> <li>Risk-Free Testing: Users can experiment with the latest OpenCAPIF features without impacting production environments.</li> <li>Hands-On Experience: Gain practical insights into OpenCAPIF capabilities through real API interactions.</li> <li>Rapid Prototyping: Test and refine API integrations efficiently before deploying in real-world scenarios.</li> <li>Up-to-Date Environment: Always access the most recent OpenCAPIF developments and improvements.</li> </ul> <p>For more details on accessing the Sandbox and utilizing its features, please refer to the following sections:</p> <ul> <li>Request Access: Learn how to create a user account and obtain credentials to interact with the Sandbox.</li> <li>Relevant Information: Find important details such as endpoint URLs and links to example use cases in the documentation.</li> </ul>"},{"location":"sandbox/sandbox/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sdk/sdk/","title":"SDK","text":"<p>Check SDK repository for further information.</p>"},{"location":"testing/postman/","title":"Postman","text":"<p>This section shows how OpenCAPIF is used through requests made with Postman, from the creation of a provider together with the publication of an api, to the creation of an invoker and the consumption of the published api. Everything you need to run the test is in Postman-Test.zip.</p>"},{"location":"testing/postman/#requisites","title":"Requisites","text":"<ul> <li>We will need to have Node.js installed since we will use a small script to create the CSRs of the certificates.</li> <li>An instance of CAPIF (If it is not local, certain variables would have to be modified both in the Node.js script and in the Postman environment variables).</li> </ul>"},{"location":"testing/postman/#first-steps","title":"First steps","text":"<ol> <li>Install the Node dependencies package.json to run the script with:</li> </ol> <pre><code>npm i\n</code></pre> <ol> <li>Run the script.js with the following command:</li> </ol> <pre><code>node script.js\n</code></pre> <ol> <li>Import Postman collection and environment variables (CAPIF.postman_collection.json and CAPIF.postman_environment.json)</li> <li>Select CAPIF Environment before start testing.</li> <li>Install the necessary dependencies from requirements.txt using the following command:</li> </ol> <pre><code>pip install -r requirements.txt\n</code></pre>"},{"location":"testing/postman/#remote-capif","title":"Remote CAPIF","text":"<p>If the CAPIF is not local, the host and port of both the CAPIF and the register would have to be specified in the variables, and the CAPIF_HOSTNAME in the script, necessary to obtain the server certificate.</p> <p>Enviroments in Postman</p> <pre><code>CAPIF_HOSTNAME capifcore\nCAPIF_PORT 8080\nREGISTER_HOSTNAME register\nREGISTER_PORT 8084\n</code></pre> <p>Const in script.js</p> <pre><code>CAPIF_HOSTNAME capifcore\n</code></pre>"},{"location":"testing/postman/#capif-flows","title":"CAPIF Flows","text":"<p>Once the first steps have been taken, we can now use Postman requests. These requests are numbered in the order that must be followed to obtain everything necessary from CAPIF.</p>"},{"location":"testing/postman/#creation-of-user-by-admin","title":"Creation of User by Admin","text":"<p>The first step would be for an administrator to create a user with which a provider and an invoker will be created. To do this, the admin must log in to obtain the token needed in admin requests.</p>"},{"location":"testing/postman/#01-login_admin","title":"01-Login_admin","text":""},{"location":"testing/postman/#02-creation-of-user","title":"02-Creation of User","text":""},{"location":"testing/postman/#publication-of-an-api","title":"Publication of an API","text":"<p>The next step is to register a provider using the user created by the administrator in order to publish an API.</p>"},{"location":"testing/postman/#03-getauth_provider","title":"03-getauth_provider","text":""},{"location":"testing/postman/#04-onboard_provider","title":"04-onboard_provider","text":""},{"location":"testing/postman/#05-publish_api","title":"05-publish_api","text":"<p>At this point we move on to using certificate authentication in CAPIF. In Postman it is necessary to add the certificates manually and using more than one certificate for the same host as we do in CAPIF complicates things. For this reason, we use the script to overwrite a certificate and a key when it is necessary to have a specific one.</p> <p>To configure go to settings in Postman and open the certificates section. </p> <ul> <li>Here, activate the CA certificates option and add the ca_cert.pem file found in the Responses folder.</li> <li>Adds a client certificate specifying the CAPIF host being used and the files client_cert.crt and client_key.key in the Responses folder.</li> </ul> <p>Once this is done, the node script will be in charge of changing the certificate that is necessary in each request.</p> <p></p> <p>Once the api is published, we can start it. In this case we have a test one created in python called hello_api.py that can be executed with the following command:</p> <pre><code>python3 hello_api.py\n</code></pre> <p>The API publication interface is set to localhost with port 8088, so the service must be set up locally. If you wanted to build it on another site, you would have to change the interface description in the body of publish_api.</p> <p>With this the provider part would be finished.</p>"},{"location":"testing/postman/#calling-the-api","title":"Calling the API","text":"<p>Finally, we will create an invoker with the user given by the administrator to be able to use the published api.</p>"},{"location":"testing/postman/#06-getauth_invoker","title":"06-getauth_invoker","text":""},{"location":"testing/postman/#07-onboard_invoker","title":"07-onboard_invoker","text":""},{"location":"testing/postman/#08-discover","title":"08-discover","text":"<p>At this point we move on to using certificate authentication in CAPIF. If you did not configure the provider's certificates, you would have to do it now.</p> <p></p>"},{"location":"testing/postman/#09-security_context","title":"09-security_context","text":""},{"location":"testing/postman/#10-get_token","title":"10-get_token","text":""},{"location":"testing/postman/#11-call_service","title":"11-call_service","text":"<p>With this, we would have made the API call and finished the flow.</p>"},{"location":"testing/postman/#other-requests","title":"Other requests","text":"<p>Other requests that we have added are the following:</p> <ul> <li>offboard_provider Performs offboarding of the provider, thereby eliminating the published APIs.</li> <li>offboard_invoker Offboards the invoker, also eliminating access to the APIs of that invoker.</li> <li>remove_user Delete the user.</li> <li>refresh_admin_token Return a new access token to the admin.</li> </ul>"},{"location":"testing/postman/#notes","title":"Notes","text":"<ul> <li>This process is designed to teach how requests are made in Postman and the flow that should be followed to publish and use an API.</li> <li>It is possible that if external CAPIFs are used (Public CAPIF) the test data may already be used or the API already registered.</li> <li>It is necessary to have the Node service running to make the certificate change for the requests, otherwise it will not work.</li> <li>We are working on adding more requests to the Postman collection.</li> <li>This collection is a testing guide and is recommended for testing purposes only.</li> </ul>"},{"location":"testing/robotframework/","title":"Robot Framework","text":""},{"location":"testing/robotframework/#steps-to-test","title":"Steps to Test","text":"<p>To run any test locally you will need docker and docker-compose installed in order run services and execute test plan. Steps will be:</p> <ul> <li> <p>Run All Services: See section Run All CAPIF Services</p> </li> <li> <p>Run desired tests: At this point we have 2 options:</p> </li> <li> <p>Using helper script: Script Test Execution</p> </li> <li>Build robot docker image and execute manually robot docker: Manual Build And Test Execution</li> </ul>"},{"location":"testing/robotframework/#script-test-execution","title":"Script Test Execution","text":"<p>This script will build robot docker image if it's need and execute tests selected by \"include\" option. Just go to service folder, execute and follow steps.</p> <pre><code>./run_capif_tests.sh --include <TAG>\n</code></pre> <p>Results will be stored at /results <p>Please check parameters (include) under Test Execution at Manual Build And Test Execution.</p>"},{"location":"testing/robotframework/#mock-server","title":"Mock Server","text":"<p>Some tests on Test Plans require mockserver. That mock server must be deployed and reachable by Robot Framework and CCF under test.</p> <p>To run Mock Server locally you can just execute the next script:</p> <pre><code>cd services\n./run_mock_server.sh\n\nor\n./run.sh -s\n</code></pre> <p>If you want to launch only tests that not needed mockserver, just add \"--exclude mockserver\" parameter to robot execution:</p> <pre><code>./run_capif_tests.sh --include <TAG> --exclude mockserver\n</code></pre> <p>After run tests the Mock Server can be removed from local deployment:</p> <pre><code>./clean_mock_server.sh\n\nor\n./clean_capif_docker_services.sh -s\n</code></pre>"},{"location":"testing/robotframework/#manual-build-and-test-execution","title":"Manual Build And Test Execution","text":"<ul> <li>Build Robot docker image:</li> </ul> <pre><code>cd tools/robot\ndocker build . -t capif-robot-test:latest\n</code></pre> <ul> <li>Tests Execution:</li> </ul> <p>Execute all tests locally:</p> <pre><code><PATH_TO_REPOSITORY>=path in local machine to repository cloned.\n<PATH_RESULT_FOLDER>=path to a folder on local machine to store results of Robot Framework execution.\n<CAPIF_HOSTNAME>=Is the hostname set when run.sh is executed, by default it is capifcore.\n<CAPIF_HTTP_PORT>=This is the port to reach when robot framework want to reach CAPIF deployment using http, this should be set to port without TLS set on Nginx, 8080 by default.\n<CAPIF_HTTPS_PORT>=This is the port to be used when we want to use https connection, this should be set to port with TLS set on Nginx, 443 by default\n<CAPIF_REGISTER>=This is the hostname of register service deployed. By default it is register.\n<CAPIF_REGISTER_PORT>=This is the port to be used to reach register service deployed. By default it is 8084.\n<CAPIF_VAULT>=This is the hostname of vault service. By default it is vault.\n<CAPIF_VAULT_PORT>=This is the port to be used to reach vault service. By default it is 8200.\n<CAPIF_VAULT_TOKEN>=Vault token to be used on request through vault. By default it is \"read-ca-token\".\n<MOCK_SERVER_URL>=Setup Mock server url to be used in notifications at tests marked with mockserver tag. By default it is not set.\n\nTo execute all tests run :\ndocker run -ti --rm --network=\"host\" \\\n --add-host host.docker.internal:host-gateway \\\n --add-host vault:host-gateway \\\n --add-host register:host-gateway \\\n --add-host mock-server:host-gateway \\\n -v <PATH_TO_REPOSITORY>/tests:/opt/robot-tests/tests \\\n -v <PATH_RESULT_FOLDER>:/opt/robot-tests/results capif-robot-test:latest \\\n --variable CAPIF_HOSTNAME:$CAPIF_HOSTNAME \\\n --variable CAPIF_HTTP_PORT:$CAPIF_HTTP_PORT \\\n --variable CAPIF_HTTPS_PORT:$CAPIF_HTTPS_PORT \\\n --variable CAPIF_REGISTER:$CAPIF_REGISTER \\\n --variable CAPIF_REGISTER_PORT:$CAPIF_REGISTER_PORT \\\n --variable CAPIF_VAULT:$CAPIF_VAULT \\\n --variable CAPIF_VAULT_PORT:$CAPIF_VAULT_PORT \\\n --variable CAPIF_VAULT_TOKEN:$CAPIF_VAULT_TOKEN \\\n --variable MOCK_SERVER_URL:$MOCK_SERVER_URL \\\n --include all\n</code></pre> <p>Execute specific tests locally:</p> <pre><code>To run more specific tests, for example, only one functionality:\n<TAG>=Select one from list:\n \"capif_api_acl\",\n \"capif_api_auditing_service\",\n \"capif_api_discover_service\",\n \"capif_api_events\",\n \"capif_api_invoker_management\",\n \"capif_api_logging_service\",\n \"capif_api_provider_management\",\n \"capif_api_publish_service\",\n \"capif_security_api\",\n \"api_status\",\n \"vendor_extensibility\",\n \"smoke\"\n\nAnd Run:\ndocker run -ti --rm --network=\"host\" \\\n --add-host host.docker.internal:host-gateway \\\n --add-host vault:host-gateway \\\n --add-host register:host-gateway \\\n --add-host mock-server:host-gateway \\\n -v <PATH_TO_REPOSITORY>/tests:/opt/robot-tests/tests \\\n -v <PATH_RESULT_FOLDER>:/opt/robot-tests/results capif-robot-test:latest \\\n --variable CAPIF_HOSTNAME:$CAPIF_HOSTNAME \\\n --variable CAPIF_HTTP_PORT:$CAPIF_HTTP_PORT \\\n --variable CAPIF_HTTPS_PORT:$CAPIF_HTTPS_PORT \\\n --variable CAPIF_REGISTER:$CAPIF_REGISTER \\\n --variable CAPIF_REGISTER_PORT:$CAPIF_REGISTER_PORT \\\n --variable CAPIF_VAULT:$CAPIF_VAULT \\\n --variable CAPIF_VAULT_PORT:$CAPIF_VAULT_PORT \\\n --variable CAPIF_VAULT_TOKEN:$CAPIF_VAULT_TOKEN \\\n --variable MOCK_SERVER_URL:$MOCK_SERVER_URL \\\n --include <TAG>\n</code></pre>"},{"location":"testing/robotframework/#test-result-review","title":"Test result review","text":"<p>In order to Review results after tests, you can check general report at /report.html or if you need more detailed information /log.html, example: <ul> <li> <p>Report: </p> </li> <li> <p>Detailed information: </p> </li> </ul> <p>NOTE: If you need more detail at Robot Framework Logs you can set log level option just adding to command --loglevel DEBUG</p>"},{"location":"testing/testplan/","title":"Test Plan Index","text":"<p>List of Common API Services implemented:</p> <ul> <li>Common Operations</li> <li>Api Invoker Management</li> <li>Api Provider Management</li> <li>Api Publish Service</li> <li>Api Discover Service</li> <li>Api Events Service</li> <li>Api Security Service</li> <li>Api Logging Service</li> <li>Api Auditing Service</li> <li>Api Access Control Policy</li> </ul>"},{"location":"testing/testplan/#features","title":"Features","text":"<ul> <li>Vendor Extensibility</li> <li>Api Status</li> <li>Event Filter</li> </ul>"},{"location":"testing/testplan/api_access_control_policy/","title":"Test Plan for CAPIF Api Access Control Policy","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_access_control_policy/#test-case-1-retrieve-acl","title":"Test Case 1: Retrieve ACL","text":"<p>Test ID: capif_api_acl-1</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-2-retrieve-acl-with-2-service-apis-published","title":"Test Case 2: Retrieve ACL with 2 Service APIs published","text":"<p>Test ID: capif_api_acl-2</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF for 2 different serviceApis published.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had two Service API Published on CAPIF</li> <li>API Invoker had a Security Context for both Service APIs published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information for service_1.</li> <li>Provider Get ACL information for service_2.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId1</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId2</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId2}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-3-retrieve-acl-with-security-context-created-by-two-different-invokers","title":"Test Case 3: Retrieve ACL with security context created by two different Invokers","text":"<p>Test ID: capif_api_acl-3</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF containing 2 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain two objects.</li> <li>One object must match with apiInvokerId1 and the other one with apiInvokerId2 an registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-4-retrieve-acl-filtered-by-api-invoker-id","title":"Test Case 4: Retrieve ACL filtered by api-invoker-id","text":"<p>Test ID: capif_api_acl-4</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL filtering by apiInvokerId from CAPIF containing 1 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information with query parameter indicating first api-invoker-id.</li> <li>Provider Get ACL information with query parameter indicating second api-invoker-id.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId1</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={apiInvokerId1}</li> <li>Use serviceApiId, aefId and apiInvokerId1</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId2</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={apiInvokerId2}</li> <li>Use serviceApiId, aefId and apiInvokerId2</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with apiInvokerId1.</li> </ol> </li> </ol> </li> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with apiInvokerId2.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-5-retrieve-acl-filtered-by-supported-features","title":"Test Case 5: Retrieve ACL filtered by supported-features","text":"<p>Test ID: capif_api_acl-5</p> <p>Description:</p> <p>CURRENTLY NOT SUPPORTED FEATURE</p> <p>This test case will check that an API Provider can retrieve ACL filtering by supportedFeatures from CAPIF containing 1 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information with query parameter indicating first supported-features.</li> <li>Provider Get ACL information with query parameter indicating second supported-features.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}&supported-features={apiInvokerId1}</li> <li>Use serviceApiId, aefId and apiInvokerId1</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}&supported-features={apiInvokerId2}</li> <li>Use serviceApiId, aefId and apiInvokerId2</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with supportedFeatures1.</li> </ol> </li> </ol> </li> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with supportedFeatures1.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-6-retrieve-acl-with-aef-id-not-valid","title":"Test Case 6: Retrieve ACL with aef-id not valid","text":"<p>Test ID: capif_api_acl-6</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if aef-id is not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${AEF_ID_NOT_VALID}</li> <li>Use serviceApiId and AEF_ID_NOT_VALID</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {service_api_id}, aef_id: {aef_id}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-7-retrieve-acl-with-service-id-not-valid","title":"Test Case 7: Retrieve ACL with service-id not valid","text":"<p>Test ID: capif_api_acl-7</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if service-api-id is not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${NOT_VALID_SERVICE_API_ID}?aef-id=${aef_id}</li> <li>Use NOT_VALID_SERVICE_API_ID and aef_id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {service_api_id}, aef_id: {aef_id}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-8-retrieve-acl-with-service-api-id-and-aef-id-not-valid","title":"Test Case 8: Retrieve ACL with service-api-id and aef-id not valid","text":"<p>Test ID: capif_api_acl-8</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if service-api-id and aef-id are not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${NOT_VALID_SERVICE_API_ID}?aef-id=${AEF_ID_NOT_VALID}</li> <li>Use NOT_VALID_SERVICE_API_ID and aef_id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-9-retrieve-acl-without-securitycontext-created-previously-by-invoker","title":"Test Case 9: Retrieve ACL without SecurityContext created previously by Invoker","text":"<p>Test ID: capif_api_acl-9</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL if no invoker had requested Security Context to CAPIF</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker created but no Security Context for Service API published had been requested.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li> <p>Discover published APIs</p> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-10-retrieve-acl-filtered-by-api-invoker-id-not-present","title":"Test Case 10: Retrieve ACL filtered by api-invoker-id not present","text":"<p>Test ID: capif_api_acl-10</p> <p>Description:</p> <p>This test case will check that an API Provider get not found response if filter by not valid api-invoker-id doesn't match any registered ACL.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={NOT_VALID_API_INVOKER_ID}</li> <li>Use serviceApiId, aefId and NOT_VALID_API_INVOKER_ID</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-11-retrieve-acl-with-apf-certificate","title":"Test Case 11: Retrieve ACL with APF Certificate","text":"<p>Test ID: capif_api_acl-11</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using APF Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use APF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-12-retrieve-acl-with-amf-certificate","title":"Test Case 12: Retrieve ACL with AMF Certificate","text":"<p>Test ID: capif_api_acl-12</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using AMF Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AMF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-13-retrieve-acl-with-invoker-certificate","title":"Test Case 13: Retrieve ACL with Invoker Certificate","text":"<p>Test ID: capif_api_acl-13</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using Invoker Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-14-no-acl-for-invoker-after-be-removed","title":"Test Case 14: No ACL for invoker after be removed","text":"<p>Test ID: capif_api_acl-14</p> <p>Description:</p> <p>This test case will check that ACLs are removed after invoker is removed.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published and ACL is present</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information of invoker.</li> <li>Remove Invoker from CAPIF.</li> <li>Provider Get ACL information of invoker.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={api-invoker-id}</li> <li>Use serviceApiId, aefId and api-invoker-id</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Remove Invoker from CAPIF</li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={api-invoker-id}</li> <li>Use serviceApiId, aefId and api-invoker-id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result: 1. ACL Response: 1. 200 OK Response. 2. body returned must accomplish AccessControlPolicyList data structure. 3. apiInvokerPolicies must: 1. contain only one object. 2. apiInvokerId must match apiInvokerId registered previously.</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: None and supportedFeatures: None\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/","title":"Test Plan for CAPIF Api Auditing Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_auditing_service/#test-case-1-get-capif-log-entry","title":"Test Case 1: Get CAPIF Log Entry.","text":"<p>Test ID: capif_api_auditing-1</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>200 OK</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-2-get-capif-log-entry-with-no-log-entry-in-capif","title":"Test Case 2: Get CAPIF Log Entry With no Log entry in CAPIF.","text":"<p>Test ID: capif_api_auditing-2</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found Log Entry in CAPIF\".</li> <li>cause with message \"Not Exist Logs with the filters applied\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-3-get-capif-log-entry-without-aef-id-and-api-invoker-id","title":"Test Case 3: Get CAPIF Log Entry without aef-id and api-invoker-id.","text":"<p>Test ID: capif_api_auditing-3</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is no pre-authorised (has no valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"aef_id and api_invoker_id parameters are mandatory\".</li> <li>cause with message \"Mandatory parameters missing\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-4-get-capif-log-entry-with-filtter-api-version","title":"Test Case 4: Get CAPIF Log Entry with filtter api-version.","text":"<p>Test ID: capif_api_auditing-4</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}&api-version={v1}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>200 OK</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-5-get-capif-log-entry-with-filter-api-version-but-not-exist-in-log-entry","title":"Test Case 5: Get CAPIF Log Entry with filter api-version but not exist in log entry.","text":"<p>Test ID: capif_api_auditing-4</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}&api-version={v58}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>detail with message \"Parameters do not match any log entry\"</li> <li>cause with message \"No logs found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/","title":"Test Plan for CAPIF Discover Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_discover_service/#test-case-1-discover-published-service-apis-by-authorised-api-invoker","title":"Test Case 1: Discover Published service APIs by Authorised API Invoker","text":"<p>Test ID: capif_api_discover_service-1</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-2-discover-published-service-apis-by-non-authorised-api-invoker","title":"Test Case 2: Discover Published service APIs by Non Authorised API Invoker","text":"<p>Test ID: capif_api_discover_service-2</p> <p>Description:</p> <p>This test case will check that an API Publisher can't discover published APIs because is not authorized.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by no invoker entity</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs by no invoker entity:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use not Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By no invoker entity:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-3-discover-published-service-apis-by-not-registered-api-invoker","title":"Test Case 3: Discover Published service APIs by not registered API Invoker","text":"<p>Test ID: capif_api_discover_service-3</p> <p>Description:</p> <p>This test case will check that a not registered invoker is forbidden to discover published APIs.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Publisher</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs with not valid apiInvoker:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={INVOKER_NOT_REGISTERED}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker does not exist\".</li> <li>cause with message \"API Invoker id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-4-discover-published-service-apis-by-registered-api-invoker-with-1-result-filtered","title":"Test Case 4: Discover Published service APIs by registered API Invoker with 1 result filtered","text":"<p>Test ID: capif_api_discover_service-4</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>At least 2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover filtered by api-name service_1 Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs filtering by api-name:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&api-name=service_1**</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> <li>filter by api-name service_1</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains previously registered Service APIs published.</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains only Service API published with api-name service_1</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-5-discover-published-service-apis-by-registered-api-invoker-filtered-with-no-match","title":"Test Case 5: Discover Published service APIs by registered API Invoker filtered with no match","text":"<p>Test ID: capif_api_discover_service-5</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>At least 2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover filtered by api-name not published Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs filtering by api-name not published:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&api-name=NOT_VALID_NAME</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> <li>filter by api-name NOT_VALID_NAME</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains previously registered Service APIs published.</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-6-discover-published-service-apis-by-registered-api-invoker-not-filtered","title":"Test Case 6: Discover Published service APIs by registered API Invoker not filtered","text":"<p>Test ID: capif_api_discover_service-6</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover without filter by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs not filtered:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the 2 previously registered Service APIs published.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/","title":"Test Plan for CAPIF Api Events Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_events_service/#test-case-1-creates-a-new-individual-capif-event-subscription","title":"Test Case 1: Creates a new individual CAPIF Event Subscription.","text":"<p>Test ID: capif_api_events-1</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) can Subscribe to Events</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-2-creates-a-new-individual-capif-event-subscription-with-invalid-subscriberid","title":"Test Case 2: Creates a new individual CAPIF Event Subscription with Invalid SubscriberId","text":"<p>Test ID: capif_api_events-2</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Subscribe to Events without valid SubcriberId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is not pre-authorised (has invalid InvokerId or apfId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{SUBSCRIBER_NOT_REGISTERED}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker or APF or AEF or AMF Not found\".</li> <li>cause with message \"Subscriber Not Found\".</li> </ul> </li> </ol> </li> <li> <p>Event Subscriptions are not stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-3-deletes-an-individual-capif-event-subscription","title":"Test Case 3: Deletes an individual CAPIF Event Subscription","text":"<p>Test ID: capif_api_events-3</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) can Delete an Event Subscription</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Remove Event Subscription</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subscription:</p> <ol> <li>Send DELETE to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li> <p>Remove Event Subscription:</p> <ol> <li>204 No Content</li> </ol> </li> <li> <p>Event Subscription is not present at CAPIF Database.</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-4-deletes-an-individual-capif-event-subscription-with-invalid-subscriberid","title":"Test Case 4: Deletes an individual CAPIF Event Subscription with invalid SubscriberId","text":"<p>Test ID: capif_api_events-4</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Delete to Events without valid SubcriberId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId).</li> <li>CAPIF subscriber is subscribed to Events.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve Location Header with subscriptionId.</li> <li>Remove Event Subscribed with not valid Subscriber.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subcription with not valid subscriber:</p> <ol> <li>Send DELETE to https://{CAPIF_HOSTNAME}/capif-events/v1/{SUBSCRIBER_ID_NOT_VALID}/subscriptions/{subcriptionId}</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li> <p>Error Response Body must accomplish with ProblemDetails data structure with:</p> <ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker or APF or AEF or AMF Not found\".</li> <li>cause with message \"Subscriber Not Found\".</li> </ul> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-5-deletes-an-individual-capif-event-subscription-with-invalid-subscriptionid","title":"Test Case 5: Deletes an individual CAPIF Event Subscription with invalid SubscriptionId","text":"<p>Test ID: capif_api_events-5</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Delete an Event Subscription without valid SubscriptionId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has invalid InvokerId or apfId).</li> <li>CAPIF subscriber is subscribed to Events.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve Location Header with subscriptionId.</li> <li>Remove Event Subscribed with not valid Subscriber.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subcription with not valid subscriber:</p> <ol> <li>Send DELETE to to https://{CAPIF_HOSTNAME}/capif-events/v1/{subcriberId}/subscriptions/{SUBSCRIPTION_ID_NOT_VALID}</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li>Remove Event Subscription with not valid subscriber:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>detail with message \"Service API not existing\".</li> <li>cause with message \"Event API subscription id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-6-invoker-receives-service-api-invocation-events","title":"Test Case 6: Invoker receives Service API Invocation events","text":"<p>Test ID: capif_api_events-6, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE, receive the notification when AEF Send TO logging service result of invocations to their APIs. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE event filtering by aefId. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Emulate Success and Failure on API invocation of provider by Invoker, using Invocation Logs API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']</li> <li>eventFilter: only receive events from provider's aefId.</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Create Log Entry emulating provider receive Success and Failure api invocation from invoker:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body with:<ol> <li>aefId from provider published.</li> <li>apiInvokerId from invoker onboarded.</li> <li>apiId of published API</li> <li>apiName of published API</li> <li>200 and 400 results in two logs.</li> </ol> </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to creation of log entry on CCF must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/api-invocation-logs/{apiVersion}/{aefId}/subscriptions/{logId}</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with invocationLog in eventDetail parameter.<ol> <li>One should be SERVICE_API_INVOCATION_SUCCESS related with 200 result at Log.</li> <li>The other one must be SERVICE_API_INVOCATION_FAILURE related with 400 result at Log.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-7-invoker-subscribe-to-service-api-available-and-unavailable-events","title":"Test Case 7: Invoker subscribe to Service API Available and Unavailable events","text":"<p>Test ID: capif_api_events-7, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, receive the notification when AEF publish and remove it. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE event. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Provider publish new API.</li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Publish new Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of service_2 published API.</li> <li>The other one must be SERVICE_API_UNAVAILABLE apiId of service_1 published API.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-8-invoker-subscribe-to-service-api-update","title":"Test Case 8: Invoker subscribe to Service API Update","text":"<p>Test ID: capif_api_events-8, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_UPDATE, receive the notification when AEF Update some information on API Published. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_UPDATE event. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header at event subscription</li> <li>Provider update information of Service API Published.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> <li>Store serviceApiId</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_UPDATE:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> <li>eventFilter set to apiId from published API.</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body [service api description] with overrided apiName to service_1_modified**</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Update Published Service API:<ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified**</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with serviceAPIDescriptions in eventDetail parameter.<ol> <li>Event should be SERVICE_API_UPDATE with eventDetail with modified apiName.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-9-provider-subscribe-to-api-invoker-events","title":"Test Case 9: Provider subscribe to API Invoker events","text":"<p>Test ID: capif_api_events-9, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to API Invoker events (API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED), receive the notifications when Invoker is onboarded, updated and removed respectively. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Subscribe Provider to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events. Enhanced_event_report active at supported features.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> <li>Offboard Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Event Subscription to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['API_INVOKER_ONBOARDED', 'API_INVOKER_UPDATED', 'API_INVOKER_OFFBOARDED']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Perform invoker onboarding</li> <li>Update information of previously onboarded Invoker:<ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> <li>Offboard:<ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiInvokerIds in eventDetail parameter.<ol> <li>One Event should be API_INVOKER_ONBOARDED with eventDetail with modified apiInvokerId.</li> <li>One Event should be API_INVOKER_UPDATED with eventDetail with modified apiInvokerId.</li> <li>One Event should be API_INVOKER_OFFBOARDED with eventDetail with modified apiInvokerId.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-10-provider-subscribed-to-acl-update-event","title":"Test Case 10: Provider subscribed to ACL update event","text":"<p>Test ID: capif_api_events-10, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE receive a notification when ACL Changes. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>API Invoker had a Security Context for the Service API published by provider.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Provider to ACCESS_CONTROL_POLICY_UPDATE event. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UPDATE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UPDATE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, with accCtrlPolListExt in eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UPDATE with eventDetail with accCtrlPolListExt including the apiId and apiInvokerPolicies.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-11-provider-receives-an-acl-unavailable-event-when-invoker-remove-security-context","title":"Test Case 11: Provider receives an ACL unavailable event when invoker remove Security Context.","text":"<p>Test ID: capif_api_events-11, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to ACCESS_CONTROL_POLICY_UNAVAILABLE will receive the notification when AEF remove Security Context created previously. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE event. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL.</li> <li>Remove Security Context for Invoker.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Delete Security Context of Invoker by Provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Delete security context:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-12-invoker-receives-an-invoker-authorization-revoked-and-acl-unavailable-event-when-provider-revoke-invoker-authorization","title":"Test Case 12: Invoker receives an Invoker Authorization Revoked and ACL unavailable event when Provider revoke Invoker Authorization.","text":"<p>Test ID: capif_api_events-12, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to API_INVOKER_AUTHORIZATION_REVOKED and ACCESS_CONTROL_POLICY_UNAVAILABLE receive both notification when AEF revoke invoker's authorization. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED events. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Revoke Authorization by Provider.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE','API_INVOKER_AUTHORIZATION_REVOKED']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Revoke Authorization by Provider:<ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>Revoke Authorization:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> <li>One Event should be API_INVOKER_AUTHORIZATION_REVOKED without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-13-creates-a-new-individual-capif-event-subscription-without-supported-features-attribute","title":"Test Case 13: Creates a new individual CAPIF Event Subscription without supported features attribute.","text":"<p>Test ID: capif_api_events-13</p> <p>Description:</p> <p>This test case will check error when CAPIF subscriber (Invoker or Publisher) Subscribe to Events without supported features attribute.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events without supported features</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body<ol> <li>supportedFeatures NOT PRESENT.</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"supportedFeatures not present in request\".</li> <li>cause with message \"supportedFeatures not present\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-14-invoker-receives-service-api-invocation-events-without-enhanced-event-report","title":"Test Case 14: Invoker receives Service API Invocation events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-14, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE, receive the notification when AEF Send TO logging service result of invocations to their APIs. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Emulate Success and Failure on API invocation of provider by Invoker, using Invocation Logs API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Create Log Entry emulating provider receive Success and Failure api invocation from invoker:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body with:<ol> <li>aefId from provider published.</li> <li>apiInvokerId from invoker onboarded.</li> <li>apiId of published API</li> <li>apiName of published API</li> <li>200 and 400 results in two logs.</li> </ol> </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to creation of log entry on CCF must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/api-invocation-logs/{apiVersion}/{aefId}/subscriptions/{logId}</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_INVOCATION_SUCCESS related with 200 result at Log.</li> <li>The other one must be SERVICE_API_INVOCATION_FAILURE related with 400 result at Log.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-15-invoker-subscribe-to-service-api-available-and-unavailable-events-without-enhanced-event-report","title":"Test Case 15: Invoker subscribe to Service API Available and Unavailable events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-15, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, receive the notification when AEF publish and remove it. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Provider publish new API.</li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Publish new Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of service_2 published API.</li> <li>The other one must be SERVICE_API_UNAVAILABLE apiId of service_1 published API.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-16-invoker-subscribe-to-service-api-update-without-enhanced-event-report","title":"Test Case 16: Invoker subscribe to Service API Update without Enhanced Event Report","text":"<p>Test ID: capif_api_events-16, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_UPDATE, receive the notification when AEF Update some information on API Published. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_UPDATE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header at event subscription</li> <li>Provider update information of Service API Published.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> <li>Store serviceApiId</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_UPDATE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_UPDATE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body [service api description] with overrided apiName to service_1_modified**</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Update Published Service API:<ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified**</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with serviceAPIDescriptions in eventDetail parameter.<ol> <li>Event should be SERVICE_API_UPDATE with eventDetail with modified apiName.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-17-provider-subscribe-to-api-invoker-events-without-enhanced-event-report","title":"Test Case 17: Provider subscribe to API Invoker events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-17, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to API Invoker events (API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED), receive the notifications when Invoker is onboarded, updated and removed respectively. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Subscribe Provider to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events. Enhanced_event_report inactive at supported features.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> <li>Offboard Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Event Subscription to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['API_INVOKER_ONBOARDED', 'API_INVOKER_UPDATED', 'API_INVOKER_OFFBOARDED']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Perform invoker onboarding</li> <li>Update information of previously onboarded Invoker:<ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> <li>Offboard:<ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be API_INVOKER_ONBOARDED</li> <li>One Event should be API_INVOKER_UPDATED</li> <li>One Event should be API_INVOKER_OFFBOARDED</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-18-provider-subscribed-to-acl-update-event-without-enhanced-event-report","title":"Test Case 18: Provider subscribed to ACL update event without Enhanced Event Report","text":"<p>Test ID: capif_api_events-18, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE receive a notification when ACL Changes. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>API Invoker had a Security Context for the Service API published by provider.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Provider to ACCESS_CONTROL_POLICY_UPDATE event. Enhanced_event_report inactive at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UPDATE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UPDATE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UPDATE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-19-provider-receives-an-acl-unavailable-event-when-invoker-remove-security-context-without-enhanced-event-report","title":"Test Case 19: Provider receives an ACL unavailable event when invoker remove Security Context without Enhanced Event Report","text":"<p>Test ID: capif_api_events-19, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to ACCESS_CONTROL_POLICY_UNAVAILABLE will receive the notification when AEF remove Security Context created previously. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE event. Enhanced_event_report inactive at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL.</li> <li>Remove Security Context for Invoker.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Delete Security Context of Invoker by Provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Delete security context:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-20-invoker-receives-an-invoker-authorization-revoked-and-acl-unavailable-event-when-provider-revoke-invoker-authorization-without-enhanced-event-report","title":"Test Case 20: Invoker receives an Invoker Authorization Revoked and ACL unavailable event when Provider revoke Invoker Authorization without Enhanced Event Report","text":"<p>Test ID: capif_api_events-20, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to API_INVOKER_AUTHORIZATION_REVOKED and ACCESS_CONTROL_POLICY_UNAVAILABLE receive both notification when AEF revoke invoker's authorization. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED events.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Revoke Authorization by Provider.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE','API_INVOKER_AUTHORIZATION_REVOKED']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Revoke Authorization by Provider:<ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>Revoke Authorization:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> <li>One Event should be API_INVOKER_AUTHORIZATION_REVOKED without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/","title":"Test Plan for CAPIF Api Invoker Management","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_invoker_management/#test-case-1-onboard-network-app","title":"Test Case 1: Onboard Network App","text":"<p>Test ID: capif_api_invoker_management-1</p> <p>Description:</p> <p>This test will try to register new Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was not registered previously</li> <li>Network App was not onboarded previously</li> <li>Preconditions: The administrator must have previously registered the User.</li> </ul> <p>Execution Steps:</p> <ol> <li>Retrieve access_token by User from register</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at invoker</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Onboard Invoker:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-2-onboard-network-app-already-onboarded","title":"Test Case 2: Onboard Network App Already onboarded","text":"<p>Test ID: capif_api_invoker_management-2</p> <p>Description:</p> <p>This test will check second onboard of same Network App is not allowed.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Network App at CCF</li> <li>Onboard Network App at CCF</li> <li>Store signed Certificate at Network App</li> <li>Onboard Again the Network App at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Repeat Onboard Invoker:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Second Onboard of Network App must accomplish:<ol> <li>403 Forbidden</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 403</li> <li>title with message \"Forbidden\"</li> <li>detail with message \"Invoker Already registered\".</li> <li>cause with message \"Identical invoker public key\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-3-update-onboarded-network-app","title":"Test Case 3: Update Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-3</p> <p>Description:</p> <p>This test will try to update information of previous onboard Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Update information of previously onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-4-update-not-onboarded-network-app","title":"Test Case 4: Update Not Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-4</p> <p>Description:</p> <p>This test will try to update information of not onboarded Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was not onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF of not onboarded</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Update information of not onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{INVOKER_NOT_REGISTERED}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> </ol> </li> <li>Response to Update Request (PUT) must contain:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Please provide an existing Network App ID\".</li> <li>cause with message \"Not exist Network App ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-5-offboard-network-app","title":"Test Case 5: Offboard Network App","text":"<p>Test ID: capif_api_invoker_management-5</p> <p>Description:</p> <p>This test case will check that a Registered Network App can be deleted.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Offboard Invoker at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Offboard:</p> <ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-6-offboard-not-previsouly-onboarded-network-app","title":"Test Case 6: Offboard Not previsouly Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-6</p> <p>Description:</p> <p>This test case will check that a Non-Registered Network App cannot be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was not onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Offboard Invoker at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Offboard:</p> <ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{INVOKER_NOT_REGISTERED}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Please provide an existing Network App ID\".</li> <li>cause with message \"Not exist Network App ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-7-update-onboarded-network-app-certificate","title":"Test Case 7: Update Onboarded Network App Certificate","text":"<p>Test ID: capif_api_invoker_management-7</p> <p>Description:</p> <p>This test will try to update public key and get a new signed certificate by CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId} and {public_key_1}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Update Onboarding Information at CCF with new public key</li> <li>Update Onboarding Information at CCF with minor change</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding with public_key_1.</p> </li> <li> <p>Create {public_key_2}</p> </li> <li> <p>Update information of previously onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>[\"onboardingInformation\"][\"apiInvokerPublicKey\"]: {public_key_2},</li> <li>Store new certificate.</li> </ul> </li> <li> <p>Update information of previously onboarded Invoker Using new certificate:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> <li>Use new Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with new public key:<ol> <li>200 OK response.</li> <li>apiInvokerCertificate with new certificate on response -> store to use.</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/","title":"Test Plan for CAPIF Api Logging Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_logging_service/#test-case-1-creates-a-new-individual-capif-log-entry","title":"Test Case 1: Creates a new individual CAPIF Log Entry.","text":"<p>Test ID: capif_api_logging-1</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid aefId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invocation-logs/v1/{aefId}/logs/{logId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-2-creates-a-new-individual-capif-log-entry-with-invalid-aefid","title":"Test Case 2: Creates a new individual CAPIF Log Entry with Invalid aefId","text":"<p>Test ID: capif_api_logging-2</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is not pre-authorised (has not valid aefId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{not-valid-aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Exposer not exist\".</li> <li>cause with message \"Exposer id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-3-creates-a-new-individual-capif-log-entry-with-invalid-serviceapi","title":"Test Case 3: Creates a new individual CAPIF Log Entry with Invalid serviceAPI","text":"<p>Test ID: capif_api_logging-3</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid aefId from CAPIF Authority)</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with serviceAPI apiName apiId not valid]</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not exist\".</li> <li>cause with message \"Invoker id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-4-creates-a-new-individual-capif-log-entry-with-invalid-apiinvokerid","title":"Test Case 4: Creates a new individual CAPIF Log Entry with Invalid apiInvokerId","text":"<p>Test ID: capif_api_logging-4</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid aefId from CAPIF Authority)</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with invokerId not valid]</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> <li> <p>Response to Logging Service must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not exist\".</li> <li>cause with message \"Invoker id not found\".</li> </ul> </li> </ol> </li> <li> <p>Log Entry are not stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-5-creates-a-new-individual-capif-log-entry-with-invalid-aefid-in-body","title":"Test Case 5: Creates a new individual CAPIF Log Entry with Invalid aefId in body","text":"<p>Test ID: capif_api_logging-5</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId in body</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with bad aefId] </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"AEF id not matching in request and body\".</li> <li>cause with message \"Not identical AEF id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/","title":"Test Plan for CAPIF Api Provider Management","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_provider_management/#test-case-1-register-api-provider","title":"Test Case 1: Register Api Provider","text":"<p>Test ID: capif_api_provider_management-1</p> <p>Description:</p> <p>This test case will check that Api Provider can be registered con CCF</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid certificate from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Register Provider at Provider Management:<ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-2-register-api-provider-already-registered","title":"Test Case 2: Register Api Provider Already registered","text":"<p>Test ID: capif_api_provider_management-2</p> <p>Description:</p> <p>This test case will check that a Api Provider previously registered cannot be re-registered</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider.</li> <li>Re-Register Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Re-Register Provider:</p> <ul> <li>Same regSec than Previous registration</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Re-Register Provider:<ol> <li>403 Forbidden response.</li> <li> <p>body returned must accomplish ProblemDetails data structure, with:</p> <ul> <li>status 403</li> <li>title with message \"Forbidden\"</li> <li>detail with message \"Provider already registered\".</li> <li>cause with message \"Identical provider reg sec\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-3-update-registered-api-provider","title":"Test Case 3: Update Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-3</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider</li> <li>Update Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Create public and private key at provider for provider itself and each function (apf, aef and amf)</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Get Resource URL from Location</li> </ul> </li> <li> <p>Update Provider:</p> <ul> <li>Send PUT to Resource URL returned at registration https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>body provider request body with apiProvDomInfo set to ROBOT_TESTING_MOD</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Register Provider:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> <li> <p>Update Provider:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure, with:<ul> <li>apiProvDomInfo set to ROBOT_TESTING_MOD</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-4-update-not-registered-api-provider","title":"Test Case 4: Update Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-4</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Update Not Registered Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Update Not Registered Provider:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_PROVIDER_NOT_REGISTERED}</li> <li>body provider request body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update Not Registered Provider:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-5-partially-update-registered-api-provider","title":"Test Case 5: Partially Update Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-5</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be partially updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Partial update provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Partial update provider:</p> <ul> <li>Send PATCH https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>body provider request patch body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Partial update provider at Provider Management:<ol> <li>200 OK response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure, with:<ul> <li>apiProvDomInfo with \"ROBOT_TESTING_MOD\"</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-6-partially-update-not-registered-api-provider","title":"Test Case 6: Partially Update Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-6</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be partially updated </p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Partial update provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Partial update Provider:</p> <ul> <li>Send PATCH https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_API_PROVIDER_NOT_REGISTERED}</li> <li>body provider request patch body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Partial update provider:<ol> <li>404 Not Found response.</li> <li> <p>body returned must accomplish ProblemDetails data structure, with:</p> <ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-7-delete-registered-api-provider","title":"Test Case 7: Delete Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-7</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Delete Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Delete registered provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete Provider:<ol> <li>204 No Content response.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-8-delete-not-registered-api-provider","title":"Test Case 8: Delete Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-8</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Delete registered provider at Provider Management:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_PROVIDER_NOT_REGISTERED}</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete Provider:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/","title":"Test Plan for CAPIF Api Publish Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_publish_service/#test-case-1-publish-api-by-authorised-api-publisher","title":"Test Case 1: Publish API by Authorised API Publisher","text":"<p>Test ID: capif_api_publish_service-1</p> <p>Description:</p> <p>This test case will check that an API Publisher can Publish an API</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li> <p>Register Provider at CCF and store certificates.</p> </li> <li> <p>Publish Service API</p> </li> <li> <p>Retrieve {apiId} from body and Location header with new resource created from response</p> </li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> </li> <li> <p>Send POST to ccf_publish_url: https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</p> </li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Published Service API is stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-2-publish-api-by-non-authorised-api-publisher","title":"Test Case 2: Publish API by NON Authorised API Publisher","text":"<p>Test ID: capif_api_publish_service-2</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Publish an API withot valid apfId </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API with invalid APF ID</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API with invalid APF ID at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{APF_ID_NOT_VALID}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Publisher not existing\".</li> <li>cause with message \"Publisher id not found\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-3-retrieve-all-apis-published-by-authorised-apfid","title":"Test Case 3: Retrieve all APIs Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-3</p> <p>Description:</p> <p>This test case will check that an API Publisher can Retrieve all API published</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>At least 2 service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API service_1</li> <li>Retrieve {apiId1} from body and Location header with new resource created from response</li> <li>Publish Service API service_2</li> <li>Retrieve {apiId2} from body and Location header with new resource created from response</li> <li>Retrieve All published APIs and check if both are present.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Other Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve all published APIs:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to service 1 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId1}</li> </ol> </li> <li> <p>Response to service 2 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId2}</li> </ol> </li> <li> <p>Published Service APIs are stored in CAPIF Database</p> </li> <li> <p>Response to Retrieve all published APIs:</p> <ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-4-retrieve-all-apis-published-by-non-authorised-apfid","title":"Test Case 4: Retrieve all APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-4</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Retrieve API published when apfId is not authorised </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Retrieve All published APIs</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Retrieve all published APIs:</p> <ul> <li>Send GET to https://{CAPIF_HOSTNAME}/published-apis/v1/{APF_ID_NOT_VALID}/service-apis</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>401 Non Authorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Provider not existing\".</li> <li>cause with message \"Provider id not found\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-5-retrieve-single-apis-published-by-authorised-apfid","title":"Test Case 5: Retrieve single APIs Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-5</p> <p>Description:</p> <p>This test case will check that an API Publisher can Retrieve API published one by one</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>At least 2 service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API service_1.</li> <li>Retrieve {apiId1} from body and Location header with new resource created from response.</li> <li>Publish Service API service_2.</li> <li>Retrieve {apiId2} from body and Location header with new resource created from response.</li> <li>Retrieve service_1 API Detail.</li> <li>Retrieve service_2 API Detail.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Other Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve service_1 published APIs detail:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{apiId1}</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve service_2 published APIs detail:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{apiId2}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to service 1 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId1}</li> </ol> </li> <li> <p>Response to service 2 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId2}</li> </ol> </li> <li> <p>Published Service APIs are stored in CAPIF Database</p> </li> <li> <p>Response to Retrieve service_1 published API using apiId1:</p> <ol> <li>200 OK</li> <li>Response body must return a ServiceAPIDescription data.</li> <li>Array must contain same information than service_1 published registration response.</li> </ol> </li> <li> <p>Response to Retrieve service_2 published API using apiId2:</p> <ol> <li>200 OK</li> <li>Response body must return a ServiceAPIDescription data.</li> <li>Array must contain same information than service_2 published registration response.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-6-retrieve-single-apis-non-published-by-authorised-apfid","title":"Test Case 6: Retrieve single APIs non Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-6</p> <p>Description:</p> <p>This test case will check that an API Publisher try to get detail of not published api.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>No published api</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Retrieve not published API Detail.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration</li> <li>Retrieve not published APIs detail:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Retrieve for NOT published API must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"No Service with specific credentials exists\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-7-retrieve-single-apis-published-by-non-authorised-apfid","title":"Test Case 7: Retrieve single APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-7</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Retrieve detailed API published when apfId is not authorised </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API at CCF</li> <li>Retrieve {apiId} from body and Location header with new resource created from response.</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Invoker Certificate</li> <li>Retrieve detailed published API acting as Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve detailed published APIs:</p> <ul> <li>Send GET to https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/${apiId}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Retrieve Detailed published API acting as Invoker must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-8-update-api-published-by-authorised-apfid-with-valid-serviceapiid","title":"Test Case 8: Update API Published by Authorised apfId with valid serviceApiId","text":"<p>Test ID: capif_api_publish_service-8</p> <p>Description:</p> <p>This test case will check that an API Publisher can Update published API with a valid serviceApiId </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>A service APIs is published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API</li> <li>Retrieve {apiId} from body and Location header with new resource url created from response</li> <li>Update published Service API.</li> <li>Retrieve detail of Service API</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>get resource url from location Header.</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body service api description with overrided apiName to service_1_modified</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve detail of service API:</p> <ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>check apiName is service_1_modified</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Update Published Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified</li> </ul> </li> </ol> </li> <li> <p>Response to Retrieve detail of Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-9-update-apis-published-by-authorised-apfid-with-invalid-serviceapiid","title":"Test Case 9: Update APIs Published by Authorised apfId with invalid serviceApiId","text":"<p>Test ID: capif_api_publish_service-9</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Update published API with a invalid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Update published Service API.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>body service api description with overrided apiName to service_1*_modified*</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Update Published Service API:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"Service API id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-10-update-apis-published-by-non-authorised-apfid","title":"Test Case 10: Update APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-10</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Update API published when apfId is not authorised</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API at CCF</li> <li>Retrieve {apiId} from body and Location header with new resource created from response.</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Invoker Certificate</li> <li>Update published API at CCF as Invoker</li> <li>Retrieve detail of Service API as publisher</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>body service api description with overrided apiName to service_1*_modified*</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Retrieve detail of service API:</p> <ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>check apiName is service_1</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Update published API acting as Invoker must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> <li> <p>Response to Retrieve Detail of Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-11-delete-api-published-by-authorised-apfid-with-valid-serviceapiid","title":"Test Case 11: Delete API Published by Authorised apfId with valid serviceApiId","text":"<p>Test ID: capif_api_publish_service-11</p> <p>Description:</p> <p>This test case will check that an API Publisher can Delete published API with a valid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> <li>A service APIs is published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API</li> <li>Retrieve {apiId} from body and Location header with new resource created from response</li> <li>Remove published API at CCF</li> <li>Try to retreive deleted service API from CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Use APF Certificate</li> </ul> </li> <li>Retrieve detail of service API:<ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Published Service API is stored in CAPIF Database</p> </li> <li> <p>Response to Remove published Service API at CCF:</p> <ol> <li>204 No Content</li> </ol> </li> <li> <p>Response to Retrieve for DELETED published API must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"No Service with specific credentials exists\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-12-delete-apis-published-by-authorised-apfid-with-invalid-serviceapiid","title":"Test Case 12: Delete APIs Published by Authorised apfId with invalid serviceApiId","text":"<p>Test ID: capif_api_publish_service-12</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Delete with invalid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Remove published API at CCF with invalid serviceId</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Remove published Service API at CCF with invalid serviceId:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Remove published Service API at CCF:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"Service API id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-13-delete-apis-published-by-non-authorised-apfid","title":"Test Case 13: Delete APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-13</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Delete API published when apfId is not authorised</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Register Invoker and onboard Invoker at CCF</li> <li>Remove published API at CCF with invalid serviceId as Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF with invalid serviceId as Invoker:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Remove published Service API at CCF:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-14-check-two-published-apis-with-different-apfs-are-removed-when-provider-is-deleted","title":"Test Case 14: Check Two Published APIs with different APFs are removed when Provider is deleted","text":"<p>Test ID: capif_api_publish_service-13</p> <p>Description:</p> <p>This test case will check that a Provider registered with two APFs, with one API published with each APF are removed properly when provider is removed. </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider with 2 APFs at CCF and store certificates.</li> <li>Publish service_1 API with APF_1</li> <li>Publish service_2 API with APF_2</li> <li>Retrieve APIs published by APF_1</li> <li>Retrieve APIs published by APF_2</li> <li>Remove Provider by AMF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish service_1 Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId1}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF_1 Certificate</li> </ul> </li> <li>Publish service_2 Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId2}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF_2 Certificate</li> </ul> </li> <li>Retrieve all published APIs by APF_1:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId1}/service-apis</li> <li>Use APF_1 Certificate</li> </ul> </li> <li>Retrieve all published APIs by APF_2:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId2}/service-apis</li> <li>Use APF_2 Certificate</li> </ul> </li> <li>Get Number of services published by superadmin:<ol> <li>Store value obtained in services_present_on_ccf_after_publish</li> </ol> </li> <li>Delete registered provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>Use AMF Certificate.</li> </ul> </li> <li>Get Number of services published by superadmin:<ol> <li>Store value obtained in services_present_on_ccf_after_delete_provider</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId1}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId2}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Retrieve all published APIs by APF_1:<ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs by APF_1.</li> </ol> </li> <li>Response to Retrieve all published APIs by APF_2:<ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs by APF_2.</li> </ol> </li> <li>Delete Provider:<ol> <li>204 No Content response.</li> </ol> </li> <li>Check two APIs where removed after remove provider:<ol> <li>services_present_on_ccf_after_publish - services_present_on_ccf_after_delete_provider = 2</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/","title":"Test Plan for CAPIF Api Security Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_security_service/#test-case-1-create-a-security-context-for-an-api-invoker","title":"Test Case 1: Create a security context for an API invoker","text":"<p>Test ID: capif_security_api-1</p> <p>Description:</p> <p>This test case will check that an API Invoker can create a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body with aefId and apiId</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-2-create-a-security-context-for-an-api-invoker-with-provider-role","title":"Test Case 2: Create a security context for an API invoker with Provider role","text":"<p>Test ID:: capif_security_api-2</p> <p>Description:</p> <p>This test case will check that an Provider cannot create a Security context with valid apiInvokerId.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with Provider role</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF.</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker but using Provider certificate.<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Create security context using Provider certificate:</p> <ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\".</li> </ul> </li> </ol> </li> <li> <p>No context stored at DB</p> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-3-create-a-security-context-for-an-api-invoker-with-provider-entity-role-and-invalid-apiinvokerid","title":"Test Case 3: Create a security context for an API invoker with Provider entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-3</p> <p>Description:</p> <p>This test case will check that an Provider cannot create a Security context with invalid apiInvokerID.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with Provider role</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this not valid apiInvokerId and using Provider certificate.<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context using Provider certificate:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\".</li> </ul> </li> </ol> </li> <li>No context stored at DB</li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-4-create-a-security-context-for-an-api-invoker-with-invoker-entity-role-and-invalid-apiinvokerid","title":"Test Case 4: Create a security context for an API invoker with Invoker entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-4</p> <p>Description:</p> <p>This test case will check that an Invoker cannot create a Security context with valid apiInvokerId.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with invalid apiInvokerId</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker:<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Create security context using Provider certificate:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> <li> <p>No context stored at DB</p> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-5-retrieve-the-security-context-of-an-api-invoker","title":"Test Case 5: Retrieve the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-5, smoke</p> <p>Description:</p> <p>This test case will check that an provider can retrieve the Security context of an API Invoker</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Retrieve Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker.</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-6-retrieve-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 6: Retrieve the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-6</p> <p>Description:</p> <p>This test case will check that an provider can retrieve the Security context of an API Invoker</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Retrieve Security Context by Provider of invalid invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of invalid Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-7-retrieve-the-security-context-of-an-api-invoker-with-invalid-apfid","title":"Test Case 7: Retrieve the Security Context of an API Invoker with invalid apfId","text":"<p>Test ID:: capif_security_api-7</p> <p>Description:</p> <p>This test case will check that an Provider cannot retrieve the Security context of an API Invoker without valid apfId</p> <p>Pre-Conditions:</p> <ul> <li>API Exposure Function is not pre-authorised (has invalid apfId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Retrieve Security Context as Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context as Invoker role:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-8-delete-the-security-context-of-an-api-invoker","title":"Test Case 8: Delete the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-8, smoke</p> <p>Description:</p> <p>This test case will check that an Provider can delete a Security context</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Delete Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker but using Provider certificate.</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> <li> <p>Delete Security Context of Invoker by Provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Delete security context:</p> <ol> <li>204 No Content response.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Security context not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-9-delete-the-security-context-of-an-api-invoker-with-invoker-entity-role","title":"Test Case 9: Delete the Security Context of an API Invoker with Invoker entity role","text":"<p>Test ID:: capif_security_api-9</p> <p>Description:</p> <p>This test case will check that an Invoker cannot delete a Security context</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Delete Security Context by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Delete Security Context of Invoker:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-10-delete-the-security-context-of-an-api-invoker-with-invoker-entity-role-and-invalid-apiinvokerid","title":"Test Case 10: Delete the Security Context of an API Invoker with Invoker entity role and invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-10</p> <p>Description:</p> <p>This test case will check that an Invoker cannot delete a Security context with invalid </p> <p>Pre-Conditions:</p> <ul> <li>Invoker is pre-authorised.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Security Context by invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Delete Security Context of Invoker:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-11-delete-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 11: Delete the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-11</p> <p>Description:</p> <p>This test case will check that an Provider cannot delete a Security context of invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Security Context by provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Delete Security Context of Invoker by Provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-12-update-the-security-context-of-an-api-invoker","title":"Test Case 12: Update the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-12, smoke</p> <p>Description:</p> <p>This test case will check that an API Invoker can update a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context By Invoker</li> <li>Update Security Context By Invoker</li> <li>Retrieve Security Context By Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Update Security Context of Invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/update</li> <li>body service security body but with notification destination modified to http://robot.testing2</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Update security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this returned object match with modified one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-13-update-the-security-context-of-an-api-invoker-with-provider-entity-role","title":"Test Case 13: Update the Security Context of an API Invoker with Provider entity role","text":"<p>Test ID:: capif_security_api-13</p> <p>Description:</p> <p>This test case will check that an Provider cannot update a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized.</li> <li>Invoker has created the Security Context previously.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Update Security Context as Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Update Security Context of Invoker by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/update</li> <li>body service security body but with notification destination modified to http://robot.testing2</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\". </li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-14-update-the-security-context-of-an-api-invoker-with-aef-entity-role-and-invalid-apiinvokerid","title":"Test Case 14: Update the Security Context of an API Invoker with AEF entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-14</p> <p>Description:</p> <p>This test case will check that an Provider cannot update a Security context of invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized.</li> <li>Invoker has created the Security Context previously.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Update Security Context as Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update Security Context of Invoker by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\". </li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-15-update-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 15: Update the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-15</p> <p>Description:</p> <p>This test case will check that an API Invoker cannot update a Security context not valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Update Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update Security Context of Invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-16-revoke-the-authorization-of-the-api-invoker-for-apis","title":"Test Case 16: Revoke the authorization of the API invoker for APIs.","text":"<p>Test ID:: capif_security_api-16</p> <p>Description:</p> <p>This test case will check that a Provider can revoke the authorization for APIs</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context by Invoker</li> <li>Revoke Security Context by Provider</li> <li>Retrieve Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context By Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Revoke Authorization by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Authorization:</p> <ol> <li>204 No Content response.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Security context not found\".</li> <li>cause with message \"API Invoker has no security context\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-17-revoke-the-authorization-of-the-api-invoker-for-apis-without-valid-apfid","title":"Test Case 17: Revoke the authorization of the API invoker for APIs without valid apfID.","text":"<p>Test ID:: capif_security_api-17</p> <p>Description:</p> <p>This test case will check that an Invoker can't revoke the authorization for APIs</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Revoke Security Context by invoker</li> <li>Retrieve Security Context</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Revoke Authorization by invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Security Context by invoker:</p> <ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be provider\". </li> </ul> </li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this returned object match with created one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-18-revoke-the-authorization-of-the-api-invoker-for-apis-with-invalid-apiinvokerid","title":"Test Case 18: Revoke the authorization of the API invoker for APIs with invalid apiInvokerId.","text":"<p>Test ID:: capif_security_api-18</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot revoke the authorization for APIs for invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Revoke Security Context by Provider</li> <li>Retrieve Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Revoke Authorization by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}?authenticationInfo=true&authorizationInfo=true</li> <li>This request will ask with parameter to retrieve authenticationInfo and authorizationInfo</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Security Context by invoker:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this return one object that match with created one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-19-retrieve-access-token","title":"Test Case 19: Retrieve access token","text":"<p>Test ID:: capif_security_api-19, smoke</p> <p>Description:</p> <p>This test case will check that an API Invoker can retrieve a security access token OAuth 2.0.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerId)</li> <li>Service API of Provider is published</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token:</li> <li>body access token req body and example example</li> <li>securityId is apiInvokerId.</li> <li>grant_type=client_credentials.</li> <li>Create Scope properly for request: 3gpp#{aef_id}:{api_name}</li> <li>Using Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>200 OK</li> <li>body must follow AccessTokenRsp with:<ol> <li>access_token present</li> <li>token_type=Bearer</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-20-retrieve-access-token-by-provider","title":"Test Case 20: Retrieve access token by Provider","text":"<p>Test ID:: capif_security_api-20</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot revoke the authorization for APIs for invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by provider:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token:</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error unauthorized_client</li> <li>error_description=Role not authorized for this API route</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-21-retrieve-access-token-by-provider-with-invalid-apiinvokerid","title":"Test Case 21: Retrieve access token by Provider with invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-21</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token without valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by provider:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{API_INVOKER_NOT_VALID}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error unauthorized_client</li> <li>error_description=Role not authorized for this API route</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-22-retrieve-access-token-with-invalid-apiinvokerid","title":"Test Case 22: Retrieve access token with invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-22</p> <p>Description:</p> <p>This test case will check that an API Invoker can't retrieve a security access token without valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs not filtered:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li>Create Security Context for this Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li>Request Access Token by invoker:<ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{API_INVOKER_NOT_VALID}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails29571 data structure, with:<ul> <li>status 404</li> <li>title Not Found</li> <li>detail Security context not found</li> <li>cause API Invoker has no security context</li> </ul> </li> </ol> </li> </ol> <p>NOTE: ProblemDetails29571 is the definition present for this request at swagger of ProblemDetails, and this is different from definition of ProblemDetails across other CAPIF Services</p>"},{"location":"testing/testplan/api_security_service/#test-case-23-retrieve-access-token-with-invalid-client_id","title":"Test Case 23: Retrieve access token with invalid client_id","text":"<p>Test ID:: capif_security_api-23</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token without valid client_id at body</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>client_id is not-valid </li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_client</li> <li>error_description=Client Id not found</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-24-retrieve-access-token-with-unsupported-grant_type","title":"Test Case 24: Retrieve access token with unsupported grant_type","text":"<p>Test ID:: capif_security_api-24</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with unsupported grant_type</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=not_valid</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>title=Bad Request</li> <li>detail='not_valid' is not one of \\['client_credentials', 'authorization_code'\\] - 'grant_type'</li> <li>status=400</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-25-retrieve-access-token-with-invalid-scope","title":"Test Case 25: Retrieve access token with invalid scope","text":"<p>Test ID:: capif_security_api-25</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with complete invalid scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=not-valid-scope</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=The first characters must be '3gpp'</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-26-retrieve-access-token-with-invalid-aefid-at-scope","title":"Test Case 26: Retrieve access token with invalid aefid at scope","text":"<p>Test ID:: capif_security_api-26</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with invalid aefId at scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=3gpp#1234:*service_1*</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=One of aef_id not belongs of your security context</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-27-retrieve-access-token-with-invalid-apiname-at-scope","title":"Test Case 27: Retrieve access token with invalid apiName at scope","text":"<p>Test ID:: capif_security_api-27</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with invalid apiName at scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=3gpp#{aef_id}:not-valid</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=One of the api names does not exist or is not associated with the aef id provided</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/","title":"Test Plan for API Status Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/api_status/#test-case-1-publish-without-apistatus-feature-receive-eventdetails-with-serviceapidescription","title":"Test Case 1: Publish without apiStatus feature receive eventDetails with serviceAPIDescription","text":"<p>Test ID: api_status-1</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing apiIds and serviceAPIDescription at eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report and apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-2-publish-without-apistatus-feature-receive-eventdetails-without-serviceapidescription","title":"Test Case 2: Publish without apiStatus feature receive eventDetails without serviceAPIDescription","text":"<p>Test ID: api_status-2</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with only Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing apiIds at eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report active at supported features (binary 0100-> string 4)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-3-publish-without-apistatus-feature-receive-eventdetails-without-eventdetails-apimonitoringstatus-active","title":"Test Case 3: Publish without apiStatus feature receive eventDetails without eventDetails (apiMonitoringStatus active)","text":"<p>Test ID: api_status-3</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with only apiStatusMonitoring active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, not containing eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1000-> string 8)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1000 -> string 8</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-4-publish-without-apistatus-feature-receive-eventdetails-without-eventdetails","title":"Test Case 4: Publish without apiStatus feature receive eventDetails without eventDetails","text":"<p>Test ID: api_status-4</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report not active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, not containing eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 0000-> string 0)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-5-publish-with-apistatus-present-but-apistatusmonitoring-inactive-receive-bad-request","title":"Test Case 5: Publish with apiStatus present but apiStatusMonitoring inactive receive bad Request","text":"<p>Test ID: api_status-5</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report not active, receive Bad Request when api is published by a provider.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring and Enhanced_event_report inactive at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>No Events have been received.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-6-publish-with-apistatus-feature-active-receive-eventdetails-with-serviceapidescription","title":"Test Case 6: Publish with apiStatus feature active receive eventDetails with serviceAPIDescription","text":"<p>Test ID: api_status-6</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification including apiIds and serviceAPIDescriptions.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-7-publish-with-apistatus-active-feature-receive-eventdetails-without-serviceapidescription","title":"Test Case 7: Publish with apiStatus active feature receive eventDetails without serviceAPIDescription","text":"<p>Test ID: api_status-7</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring inactive and Enhanced_event_report active, receive event notification including only apiIds.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report active and apiStatusMonitoring inactive at supported features (binary 0100-> string 4)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with only apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-8-publish-with-apistatus-active-feature-receive-eventdetails-without-eventdetails-with-apistatus-apimonitoringstatus-active","title":"Test Case 8: Publish with apiStatus active feature receive eventDetails without eventDetails with apiStatus (apiMonitoringStatus active)","text":"<p>Test ID: api_status-8</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring active and Enhanced_event_report inactive, receive event notification without eventDetails.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report inactive and apiStatusMonitoring active at supported features (binary 1000-> string 8)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1000 -> string 8</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-9-publish-with-apistatus-active-feature-receive-eventdetails-without-eventdetails","title":"Test Case 9: Publish with apiStatus active feature receive eventDetails without eventDetails","text":"<p>Test ID: api_status-9</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report inactive, receive event notification without eventDetails.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report and apiStatusMonitoring inactive at supported features (binary 0000-> string 0)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-10-publish-with-apistatus-feature-active-no-aefid-active-receive-eventdetails-with-serviceapidescription-with-apistatus-empty-array","title":"Test Case 10: Publish with apiStatus feature active no aefId active receive eventDetails with serviceAPIDescription with apiStatus empty array","text":"<p>Test ID: api_status-10</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification SERVICE_API_UNAVAILABLE including apiIds and serviceAPIDescriptions when API is published containing apiStatus with empty array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty aefIds array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with empty aefIds array. </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>Only one SERVICE_API_UNAVAILABLE event.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-11-publish-with-apistatus-not-present-but-apistatusmonitoring-feature-active-receive-eventdetails-with-serviceapidescription-without-apistatus","title":"Test Case 11: Publish with apiStatus not present but apiStatusMonitoring feature active receive eventDetails with serviceAPIDescription without apiStatus","text":"<p>Test ID: api_status-11</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE including apiIds and serviceAPIDescriptions when API is published wihtout apiStatus.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus not present. </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>First SERVICE_API_AVAILABLE event.</li> <li>Other with SERVICE_API_UNAVAILABLE event.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-12-update-published-api-without-apistatus-and-apistatusmonitoring-inactive","title":"Test Case 12: Update published API without apiStatus and apiStatusMonitoring inactive","text":"<p>Test ID: api_status-12</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, and SERVICE_API_UPDATE after update apiStatus to not present.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus Not present</li> <li>aipStatusMonitoring feature not active (binary 0 0000 0000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus not present.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetail with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetail containing serviceAPIDescription updated.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-13-update-published-api-with-apistatus-empty-and-apistatusmonitoring-inactive","title":"Test Case 13: Update published API with apiStatus empty and apiStatusMonitoring inactive","text":"<p>Test ID: api_status-13</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, and SERVICE_API_UPDATE after update apiStatus to empty aefIds array with ApiStatusMonitoring inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature not active (binary 0 0000 0000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with empty aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li> <p>Response to Update request must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>One Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-14-update-published-api-with-apistatus-empty-and-apistatusmonitoring-active","title":"Test Case 14: Update published API with apiStatus empty and apiStatusMonitoring active","text":"<p>Test ID: api_status-14</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, SERVICE_API_UPDATE and SERVICE_API_UNAVAILABLE after update apiStatus to empty aefIds array with ApiStatusMonitoring active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with empty aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>One should be SERVICE_API_UPDATE.</li> <li>One should be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-15-update-published-api-with-apistatus-only-aef2-and-apistatusmonitoring-active","title":"Test Case 15: Update published API with apiStatus only aef2 and apiStatusMonitoring active","text":"<p>Test ID: api_status-15</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails and SERVICE_API_UPDATE after update apiStatus to aefId2 array with ApiStatusMonitoring active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with aefId2 in aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>One should be SERVICE_API_UPDATE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-16-published-api-without-aefs-available-updated-to-one-aef-available","title":"Test Case 16: Published API without aefs available updated to one aef available","text":"<p>Test ID: api_status-16</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_UNAVAILABLE in mockserver when api is published with apiStatus empty by a provider containing eventDetails, SERVICE_API_UPDATE and SERVICE_API_AVAILABLE after update apiStatus to aefId2 array with ApiStatusMonitoring active, and SERVICE_API_UNAVAILABLE when API is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty aefIds array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with aefId2 in aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with empty aefIds array.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with aefId2 in aefIds array.</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_UNAVAILABLE aefIds array inside apiStatus empty.</li> <li>One should be SERVICE_API_UPDATE aefIds array inside apiStatus contains apfId2.</li> <li>One should be SERVICE_API_AVAILABLE aefIds array inside apiStatus contains apfId2.</li> <li>One should be SERVICE_API_UNAVAILABLE aefIds array inside apiStatus contains apfId2.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-17-patch-published-apistatusmonitoring-active-api-with-apistatus-only-aefid2","title":"Test Case 17: Patch published (apiStatusMonitoring active) API with apiStatus only aefId2","text":"<p>Test ID: api_status-17</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE after patch with apfId2 in apiStatus array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-18-patch-published-apistatusmonitoring-active-api-with-apistatus-aef1-and-aef2","title":"Test Case 18: Patch published (apiStatusMonitoring active) API with apiStatus aef1 and aef2","text":"<p>Test ID: api_status-18</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE after patch with apfId1 and apfId2 in apiStatus array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId1 and aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-19-patch-published-apistatusmonitoring-inactive-api-with-apistatus-aefid1-and-aefid2","title":"Test Case 19: Patch published (apiStatusMonitoring inactive) API with apiStatus aefId1 and aefId2","text":"<p>Test ID: api_status-19</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring inactive), containing eventDetails, and NO SERVICE_API_UPDATE after patch with apfId1 and apfId2 in apiStatus array, because apiStatusMonitoring in publish is inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0000 0000 -> string 000)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>No Events have been received.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-20-patch-published-without-aefs-available-api-with-apistatus-only-aef2","title":"Test Case 20: Patch published without aefs available API with apiStatus only aef2","text":"<p>Test ID: api_status-20</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_UNAVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE and SERVICE_API_AVAILABLE after patch with apfId1 and apfId2 in apiStatus array, becasue change from unavailable to available and also serviceAPIDescription is updated.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus empty array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId1 and aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_UNAVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> <li>Last one should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/","title":"Common Operations","text":""},{"location":"testing/testplan/common_operations/#default-supported-features","title":"Default Supported Features","text":"<p>By default all required supported features on POST Request will be present and set to \"0\" unless test define it with other value. Also it can be set to NONE is we want to test supported features not present.</p>"},{"location":"testing/testplan/common_operations/#register-new-user","title":"Register new user","text":"<p>In order to use OpenCAPIF we must add a new user. This new user can onboard/register any Invokers or Providers.</p> <p>That new user must be created by administrator of Register Service and with the credentials shared by administrator, the new user can get the access_token by requesting it to Register service.</p> <p>The steps to register a new user at Register Service are:</p>"},{"location":"testing/testplan/common_operations/#admin-create-user","title":"Admin create User","text":"<p>1) Login as Admin to get access_token:</p> <ul> <li>Send POST to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/login<ul> <li>Include basic Auth Header with Admin credentials</li> </ul> </li> <li>Get access_token and refresh_token from response</li> </ul> <p></p> <p>2) Create User:</p> <ul> <li>Send POST to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/createUser<ul> <li>Include Admin access_token in Authorization Bearer Header</li> <li>Body user_registration_body</li> </ul> </li> </ul> <p></p>"},{"location":"testing/testplan/common_operations/#user-retrieve-access-token-and-other-information","title":"User Retrieve access token and other information","text":"<p>1) Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth<ul> <li>Include basic Auth Header with User credentials</li> </ul> </li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> <p></p>"},{"location":"testing/testplan/common_operations/#onboard-an-invoker","title":"Onboard an Invoker","text":""},{"location":"testing/testplan/common_operations/#steps-to-perform-operation","title":"Steps to perform operation","text":"<p>Preconditions: The administrator must have previously registered the User.</p> <ol> <li>Create public and private key at invoker</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Onboard Invoker: </p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-onboarding","title":"Checks to ensure onboarding","text":"<ol> <li> <p>Response to Get Auth:</p> <ol> <li>200 OK</li> <li>access_token returned.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#example-flow","title":"Example Flow","text":""},{"location":"testing/testplan/common_operations/#register-a-provider","title":"Register a Provider","text":""},{"location":"testing/testplan/common_operations/#steps-to-perform-operation_1","title":"Steps to Perform operation","text":"<ol> <li>Create public and private key at provider for provider itself and each function (apf, aef and amf)</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> <li>Store each cert in a file with according name.</li> </ul> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-provider-registration","title":"Checks to ensure provider registration","text":"<ol> <li> <p>Response to Register:</p> <ol> <li>201 Created</li> </ol> </li> <li> <p>Response to Get Auth:</p> <ol> <li>200 OK</li> <li>access_token returned.</li> </ol> </li> <li> <p>Register Provider at Provider Management:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#example-flow_1","title":"Example Flow","text":""},{"location":"testing/testplan/common_operations/#subscribe-to-events","title":"Subscribe to Events","text":"<p>Subscription to an Event by any entity (Invoker, Provider or other CCF), will ensure when subscription is matched one event will be sent to notification destination present on subscription creation.</p>"},{"location":"testing/testplan/common_operations/#how-to-create-a-subscription","title":"How to create a subscription","text":"<p>In order to create a subcription, customer must setup some different parameters.</p>"},{"location":"testing/testplan/common_operations/#basic-subscription","title":"Basic Subscription","text":"<p>Basic subcription will be used when Enhanced_event_report feature is not active at supportedFeatures attribute at event subscription request body, this means this kind of subcription:</p> <ul> <li>Won't be filtered by eventFilters.</li> <li>Reporting specific requierements won't be enable (eventReq).</li> <li>Response will only contains basic information without eventDetail.</li> </ul> <p>With this in mind, customer must select next parameters:</p>"},{"location":"testing/testplan/common_operations/#events-to-subscribe","title":"Events to subscribe","text":"<p>Select event or events to subscribe. Check from next list:</p> Event Description Status SERVICE_API_AVAILABLE Events related to the availability of service APIs after the service APIs are published. Implemented SERVICE_API_UNAVAILABLE Events related to the unavailability of service APIs after the service APIs are unpublished. Implemented SERVICE_API_UPDATE Events related to change in service API information. Implemented API_INVOKER_ONBOARDED Events related to API invoker onboarded to CAPIF. Implemented API_INVOKER_OFFBOARDED Events related to API invoker offboarded from CAPIF. Implemented SERVICE_API_INVOCATION_SUCCESS Events related to the successful invocation of service APIs. Implemented SERVICE_API_INVOCATION_FAILURE Events related to the failed invocation of service APIs. Implemented ACCESS_CONTROL_POLICY_UPDATE Events related to the update for the access control policy related to the service APIs. Implemented ACCESS_CONTROL_POLICY_UNAVAILABLE Events related to the unavailability of the access control policy related to the service APIs (NOTE). Implemented API_INVOKER_AUTHORIZATION_REVOKED Events related to the revocation of the authorization of API invokers to access the service APIs. (NOTE). Implemented API_INVOKER_UPDATED Events related to API invoker profile updated to CAPIF. Implemented API_TOPOLOGY_HIDING_CREATED Events related to the creation or update of the API topology hiding information of the service API after the service APIs are published. Not Implemented API_TOPOLOGY_HIDING_REVOKED Events related to the revocation of the API topology information of the service API after the service APIs are unpublished. Not Implemented <p>NOTE: 3GPP Common API Framework release 19 specs not specify further details (e.g event filters) for this event.</p>"},{"location":"testing/testplan/common_operations/#notification-destination","title":"Notification Destination","text":"<ul> <li>Set notification destination at event subscription request body with the endpoint to be reached by CCF when an event matches.</li> </ul>"},{"location":"testing/testplan/common_operations/#enhanced-subscription","title":"Enhanced Subscription","text":"<p>Enhanced will be the requiered subscription if customer needs one or more next functionality:</p> <ul> <li>Filter events. (eventFilters)</li> <li>Setup some reporting requirements. (eventReq)</li> <li>Get more detailed information when event notification is received (eventDetail on response)</li> </ul> <p>If that is the case, then event subscription request body must setup supported features with Enhanced_event_report feature active (feature 3)</p> <p>With this feature active, customer can send eventFilter and EventReq with required information.</p>"},{"location":"testing/testplan/common_operations/#event-filter","title":"Event Filter","text":"<p>We can include an array for each suscribed array with desired eventFilter to be applied, but we need to keep in mind not all events allows all filters, take a look to next table:</p> Event Event filter allowed SERVICE_API_AVAILABLE apiIds SERVICE_API_UNAVAILABLE apiIds SERVICE_API_UPDATE apiIds API_INVOKER_ONBOARDED apiInvokerIds API_INVOKER_OFFBOARDED apiInvokerIds SERVICE_API_INVOCATION_SUCCESS apiIds, apiInvokerIds, aefIds. SERVICE_API_INVOCATION_FAILURE apiIds, apiInvokerIds, aefIds. ACCESS_CONTROL_POLICY_UPDATE apiIds, apiInvokerIds. ACCESS_CONTROL_POLICY_UNAVAILABLE - API_INVOKER_AUTHORIZATION_REVOKED - API_INVOKER_UPDATED apiInvokerIds API_TOPOLOGY_HIDING_CREATED - API_TOPOLOGY_HIDING_REVOKED -"},{"location":"testing/testplan/common_operations/#event-req","title":"Event Req","text":"<p>Currently not implemented</p>"},{"location":"testing/testplan/common_operations/#steps-to-perform-operation_2","title":"Steps to Perform operation","text":"<ol> <li>Perform invoker onboarding or provider registration</li> <li>Event Subscription:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate or AMF Provider Certificate</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-provider-registration_1","title":"Checks to ensure provider registration","text":"<ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/","title":"Test Plan for Event Filter Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/event_filter/#test-case-1-invoker-subscribed-to-service_api_available-service_api_unavailable-and-service_api_update-events-filtered-by-apiids","title":"Test Case 1: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by apiIds","text":"<p>Test ID: event_filter-1 Additional Tags: mockserver</p> <p>Description:</p> <p>This test case will check an invoker can subscribe to SERVICE_API events and filter them by apiId.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> <li>Two providers registered and with APIs published.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Register Provider 1 and publish service_1 api:<ol> <li>Setup provider with Two AEFs.</li> <li>Publish service_1 with:<ol> <li>Two AEFs. (aef_id_1 and aef_id_2)</li> <li>apiStatus empty list.</li> <li>supportedFeatures 020.</li> </ol> </li> </ol> </li> <li>Register Provider 2 and publish service_2 api:<ol> <li>Publish service_2 with:<ol> <li>apiStatus with AEF Id (aef2_id_1)</li> <li>supportedFeatures 020</li> </ol> </li> </ol> </li> <li>Discover APIs by Invoker:<ol> <li>filter by aef_id_1</li> <li>Only one api will be obtained, store apiId at api_id.</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [apiId], [apiId], [apiId].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Update service_1 api:<ol> <li>apiStatus with aefIds present on Provider 1.</li> <li>SupportedFeatures set to 20</li> </ol> </li> <li>Remove Provider 1</li> <li>Remove Provider 2</li> </ol> <p>Expected Results:</p> <p>Mock Server received messages must accomplish:</p> <ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, with:<ol> <li>SERVICE_API_AVAILABLE:<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> <li>SERVICE_API_UPDATE:<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> <li>SERVICE_API_UNAVAILABLE<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-2-invoker-subscribed-to-service_api_available-service_api_unavailable-and-service_api_update-events-filtered-by-not-valid-filters","title":"Test Case 2: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by not valid filters","text":"<p>Test ID: event_filter-2 Additional Tags: smoke</p> <p>Description:</p> <p>This test case will check all error response related with wrong filtering options when invoker subscribes to SERVICE_API events.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> <li>Two providers registered and with APIs published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Register Provider 1 and publish service_1 api:<ol> <li>Setup provider with Two AEFs.</li> <li>Publish service_1 with:<ol> <li>Two AEFs. (aef_id_1 and aef_id_2)</li> <li>apiStatus empty list.</li> <li>supportedFeatures 020.</li> </ol> </li> </ol> </li> <li>Register Provider 2 and publish service_2 api:<ol> <li>Publish service_2 with:<ol> <li>apiStatus with AEF Id (aef2_id_1)</li> <li>supportedFeatures 020</li> </ol> </li> </ol> </li> <li>Discover APIs by Invoker:<ol> <li>filter by aef_id_1</li> <li>Only one api will be obtained, store apiId at api_id.</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [aefIds], [empty], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [aefIds], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [empty], [aefIds].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [empty], [apiInvokerIds].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <p>We will receive one error after each Event subscription:</p> <ol> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_AVAILABLE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_AVAILABLE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UNAVAILABLE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UNAVAILABLE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter api_invoker_ids for event SERVICE_API_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-3-provider-subscribed-to-api_invoker_onboarded-api_invoker_offboarded-and-api_invoker_updated-events-filtered-by-invokerids","title":"Test Case 3: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by invokerIds","text":"<p>Test ID: event_filter-3 Additional Tags: mockserver</p> <p>Description:</p> <p>This test case will check subcription to all API_INVOKER events by one provider.</p> <p>Pre-Conditions:</p> <ul> <li>Provider is previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Subscribe to events:<ol> <li>Events: API_INVOKER_ONBOARDED</li> <li>EventFilter: No filter.</li> <li>supportedFeatures: C</li> </ol> </li> <li>Register and onboard Invoker 1</li> <li>Register and onboard Invoker 2</li> <li>Subscribe provider to events:<ol> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [apiInvokerId1], [apiInvokerId2].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Update Invoker 1:<ol> <li>Setup new notificationDestination at invoker.</li> </ol> </li> <li>Update Invoker 2:<ol> <li>Setup new notificationDestination at invoker.</li> </ol> </li> <li>Remove Invoker 1.</li> <li>Remove Invoker 2.</li> </ol> <p>Expected Results:</p> <p>Mock Server received messages must accomplish:</p> <ol> <li>Four Events have been received.</li> <li>Validate received events follow EventNotification data structure, with:<ol> <li>API_INVOKER_ONBOARDED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 1</li> </ol> </li> <li>API_INVOKER_ONBOARDED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 2</li> </ol> </li> <li>API_INVOKER_UPDATED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 2</li> </ol> </li> <li>API_INVOKER_OFFBOARDED<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 1</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-4-provider-subscribed-to-api_invoker_onboarded-api_invoker_offboarded-and-api_invoker_updated-events-filtered-by-not-valid-filters","title":"Test Case 4: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by not valid filters","text":"<p>Test ID: event_filter-4 Additional Tags: </p> <p>Description:</p> <p>This test will check API_INVOKER events subscription by Provider with not valid filters.</p> <p>Pre-Conditions:</p> <ul> <li>Provider is previously registered.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Register and onboard Invoker 1</li> <li>Register and onboard Invoker 2</li> <li>Subscribe provider to events:<ol> <li>Subscription 1</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [aefIds], [empty], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 2</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [aefIds], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 3</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [empty], [aefIds].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 4</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [empty], [apiIds].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_ONBOARDED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_ONBOARDED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to second subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_OFFBOARDED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_OFFBOARDED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to third subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_UPDATED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_UPDATED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to fourth subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_UPDATED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter api_ids for event API_INVOKER_UPDATED are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-5-provider-subscribed-to-access_control_policy_update-event-filtered-by-only-apiid-only-invokerid-and-both","title":"Test Case 5: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by only apiId, only invokerId and both","text":"<p>Test ID: event_filter-5 Additional Tags: smoke, mockserver</p> <p>Description:</p> <p>This test case will check subcription to ACCESS_CONTROL_POLICY_UPDATE event by one provider.</p> <p>Pre-Conditions:</p> <ul> <li>Two Providers are previously registered and published APIs</li> <li>Two invoker are previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1 and publish service_1 api:<ul> <li>Store apiId1</li> </ul> </li> <li>Register Provider 2 and publish service_2 api:<ul> <li>Store apiId2</li> </ul> </li> <li>Register and onboard Invoker 1<ul> <li>apiInvokerId1</li> </ul> </li> <li>Register and onboard Invoker 2<ul> <li>apiInvokerId2</li> </ul> </li> <li>Subscribe to events:<ol> <li>Subscription1</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Subscription2</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiInvokerId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Subscription3</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiInvokerId2] and [apiId2].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Create Security Context Between Invoker 1 and provider 1 exposed API.<ol> <li>Store acl_provider_1</li> </ol> </li> <li>Create Security Context Between Invoker 2 and provider 1 exposed API.<ol> <li>Store acl_provider_1 (array will contain 2 values)</li> </ol> </li> <li>Create Security Context Between Invoker 1 and provider 2 exposed API.<ol> <li>Store acl_provider_2 (array will contain 2 values)</li> </ol> </li> <li>Create Security Context Between Invoker 2 and provider 2 exposed API.<ol> <li>Store acl_provider_2 (array will contain 2 values)</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Eight Events have been received for 3 different subscriptions.</li> <li>Validate received events follow EventNotification data structure</li> <li>Subcription 1:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 1 (acl_provider_1[1])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])</li> </ol> </li> </ol> </li> <li>Subcription 2:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])</li> </ol> </li> </ol> </li> <li>Subcription 3:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-6-provider-subscribed-to-access_control_policy_update-event-filtered-by-aefid","title":"Test Case 6: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by aefId","text":"<p>Test ID: event_filter-6 Additional Tags:</p> <p>Description:</p> <p>This test will check ACCESS_CONTROL_POLICY_UPDATE event subscription by Provider with not valid filters.</p> <p>Pre-Conditions:</p> <ul> <li>One Provider is previously registered.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Subscribe to events:<ol> <li>Subscription1</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [aef_ids].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event ACCESS_CONTROL_POLICY_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event ACCESS_CONTROL_POLICY_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-7-provider-subscribed-to-service_api_invocation_success-and-service_api_invocation_failure-filtered-by-apiid-invokerid-aefid-and-all-of-them","title":"Test Case 7: Provider subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE filtered by apiId, invokerId, aefId and all of them","text":"<p>Test ID: event_filter-7 Additional Tags: smoke, mockserver</p> <p>Description:</p> <p>This test will check all possible filters options allowed for SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE.</p> <p>Pre-Conditions:</p> <ul> <li>Two Providers are previously registered and published APIs</li> <li>Two invoker are previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1 and publish service_1 api:<ul> <li>Store apiId1</li> <li>Store aefId1</li> </ul> </li> <li>Register Provider 2 and publish service_2 api:<ul> <li>Store apiId2</li> <li>Store aefId2</li> </ul> </li> <li>Register and onboard Invoker 1<ul> <li>apiInvokerId1</li> </ul> </li> <li>Register and onboard Invoker 2<ul> <li>apiInvokerId2</li> </ul> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 1</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 2</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 3</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 4</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 5</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 6</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 7</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Send Log entry by provider1:<ol> <li>apiNames: [service_1]</li> <li>apiIds: [apiId1]</li> <li>aefId: aefId1</li> <li>apiInvokerId: apiInvokerId1</li> <li>results: [200, 400]</li> <li>Store body to request_body_log_1</li> </ol> </li> <li>Send Log entry by provider2:<ol> <li>apiNames: [service_2]</li> <li>apiIds: [apiId2]</li> <li>aefId: aefId2</li> <li>apiInvokerId: apiInvokerId1</li> <li>results: [200]</li> <li>Store body to request_body_log_2</li> </ol> </li> <li>Send Log entry by provider2:<ol> <li>apiNames: [service_2]</li> <li>apiIds: [apiId2]</li> <li>aefId: aefId2</li> <li>apiInvokerId: apiInvokerId2</li> <li>results: [200]</li> <li>Store body to request_body_log_3</li> </ol> </li> <li>Send Log entry by provider1:<ol> <li>apiNames: [service_1]</li> <li>apiIds: [apiId1]</li> <li>aefId: aefId1</li> <li>apiInvokerId: apiInvokerId2</li> <li>results: [400]</li> <li>Store body to request_body_log_4</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Thirteen Events have been received for 7 different subscriptions.</li> <li>Validate received events follow EventNotification data structure</li> <li>Subcription 1:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_4</li> </ol> </li> </ol> </li> <li>Subcription 2:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 3:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> </ol> </li> <li>Subcription 4:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 5:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 6:<ol> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_4</li> </ol> </li> </ol> </li> <li>Subcription 7:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-8-event-filter-present-with-enhanced_event_report-feature-not-active","title":"Test Case 8: Event Filter present with Enhanced_event_report feature not active.","text":"<p>Test ID: event_filter-8 Additional Tags: smoke</p> <p>Description:</p> <p>This test will check event subscription by Invoker with eventFilter attribute but without Enhanced_event_report feature active.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE</li> <li>EventFilter: [empty], [empty], [empty].</li> <li>supportedFeatures: 0</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Event filters provided but EnhancedEventReport is not enabled</li> <li>invalidParams: [{ param:eventFilter, reason: EnhancedEventReport is not enabled }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/","title":"Test Plan for Vendor Extensibility Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/vendor_extensibility/#test-case-1-published-api-with-vendor-extensibility","title":"Test Case 1: Published API with vendor extensibility","text":"<p>Test ID: vendor_extensibility-1</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag active and vendorSpecific, can be discovered by invoker with all vendorSpecific fields.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>includes supported-features with VendSpecQueryParams active (binary 010 -> string 2)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-2-published-api-with-vendor-extensibility-and-discover-with-vendspecqueryparams-disabled","title":"Test Case 2: Published API with vendor extensibility and discover with VendSpecQueryParams disabled","text":"<p>Test ID: vendor_extensibility-2</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag active and vendorSpecific, but discovered filter only APIs without vendorSpecific parameter</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-3-publish-api-with-vendorext-active-and-discover-without-supported-features-filter","title":"Test Case 3: Publish API with vendorExt active and discover without supported features filter","text":"<p>Test ID: vendor_extensibility-3</p> <p>Description:</p> <p>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</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check NOT contains the vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-4-publish-api-with-vendorext-active-but-without-vendorspecifics","title":"Test Case 4: Publish API with vendorExt active but without vendorSpecifics","text":"<p>Test ID: vendor_extensibility-4</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API NOT includes any \"Vendor Specific\" information.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDED vendor specific service in root of service api description.</li> <li>NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"If and only if VendorExt feature is enabled, then vendor-specific fields should be defined\".</li> <li>cause with message \"Vendor extensibility misconfiguration\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-5-publish-api-with-vendorext-inactive-but-with-vendorspecifics","title":"Test Case 5: Publish API with vendorExt inactive but with vendorSpecifics","text":"<p>Test ID: vendor_extensibility-5</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API includes any \"Vendor Specific\" information.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 000</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"If and only if VendorExt feature is enabled, then vendor-specific fields should be defined\".</li> <li>cause with message \"Vendor extensibility misconfiguration\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-6-published-api-without-vendor-extensibility-discover-with-vendspecqueryparams-enabled","title":"Test Case 6: Published API without vendor extensibility discover with VendSpecQueryParams enabled","text":"<p>Test ID: vendor_extensibility-6</p> <p>Description:</p> <p>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</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API NOT includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>Supported-features: binary 010 -> string 2</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDED vendor specific service in root of service api description.</li> <li>NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 00</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include any \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-7-published-api-without-vendor-extensibility-and-discover-with-vendspecqueryparams-disabled","title":"Test Case 7: Published API without vendor extensibility and discover with vendSpecQueryParams disabled","text":"<p>Test ID: vendor_extensibility-7</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker filtering by vendSpecQueryParams.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 0)</li> <li>This API NOT includes any \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>includes supported-features with VendSpecQueryParams active (binary 000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDE vendor specific service in root of service api description.</li> <li>NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 0</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains any vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-8-published-api-without-vendor-extensibility-and-discover-without-supported-features-query-parameter","title":"Test Case 8: Published API without vendor extensibility and discover without supported-features query parameter","text":"<p>Test ID: vendor_extensibility-8</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API NOT includes any \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>NOT includes supported-features</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDE vendor specific service in root of service api description.</li> <li>NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 000</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains any vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-9-publish-api-without-supportedfeatures","title":"Test Case 9: Publish API without supportedFeatures","text":"<p>Test ID: vendor_extensibility-9</p> <p>Description:</p> <p>This test case will check if a published API without supportedFeatures receives the 400 Bad Request, because is not allowed by definition.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>without supportedFeatures parameter.</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"supportedFeatures not present in request\".</li> <li>cause with message \"supportedFeatures not present\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"vendor-ext/vendor-ext/","title":"Vendor Extensibility","text":"<p>Mechanism for the APIs to re-use, extend their functionalities and data models and engage with third-party API frameworks (e.g. ETSI MEC)</p> <p>Vendor specific extensions are defined on 3GPP TS 29.122 (section 5.2.13) and 29.500 (section 6.6.3) and is tightly connected with \"supported-features\u201d and \"feature negotiation\" procedures.</p>"},{"location":"vendor-ext/vendor-ext/#vendor-extensibility-in-capif","title":"Vendor Extensibility in CAPIF:","text":"<p>Vendor Extensibility is a feature focused on the APIs that are published and exposed via CAPIF. As a result, the feature is supported by the ServiceAPIDescription object (and any other objects embeded on it e.g. AefProfile). In the figure below, depicting all supported features of ServiceAPIDescription, VendExt feature is noted, which enables vendor-specific extension in the body of the specific object.</p> <p></p> <p>Vendor extensibility feature can be enabled and leveraged in 2 CAPIF APIs, Publish and Discover.</p>"},{"location":"vendor-ext/vendor-ext/#vendor-extensibility-in-capif-apis","title":"Vendor Extensibility in CAPIF APIs","text":""},{"location":"vendor-ext/vendor-ext/#publish-api","title":"Publish API","text":"<p>A vendor can extend the ServiceAPIDescription object by adding additional member elements. However, in order to avoid duplication of member names inside a same object it is necessary to comply with a naming scheme for vendor-specific data elements, to avoid clashing names between vendors. Vendor-specific member names in JSON objects shall be named in the following manner:</p> <pre><code> \"vendorSpecific-nnnnnnnnn\": {\n ...\n }\n</code></pre> <p>where the value \"nnnnnn\" can be:</p> <ol> <li>6-digit IANA-assigned enterprise code:</li> </ol> <pre><code> \"vendorSpecific-010415\": {\n ...\n }\n</code></pre> <ol> <li>domain name:</li> </ol> <pre><code>\"vendorSpecific-3gpp.org\": {\n ...\n }\n</code></pre> <ol> <li>URN:</li> </ol> <pre><code>\"vendorSpecific-urn:3gpp:example\": {\n ...\n }\n</code></pre> <p>A concrete example of vendor-specific extensibility exists on section 9 of ETSI GS MEC 011 V3.2.1, where ETSI MEC extends the ServiceAPIDescription as depicted on the following two figures.</p> <p></p> <p></p> <p>Example:</p> <p>ServiceAPIDescription vendorSpecific looks like:</p> <pre><code>\"vendorSpecific-urn:etsi:mec:capifext:service-info\": {\n \"serializer\": \"JSON\",\n \"state\": \"ACTIVE\",\n \"scopeOfLocality\": \"MEC_SYSTEM\",\n \"consumedLocalOnly\": \"True\",\n \"isLocal\": \"True\",\n \"category\": {\n \"href\": \"https://www.location.com\",\n \"id\": \"location_1\",\n \"name\": \"Location\",\n \"version\": \"1.0\"\n }\n}\n</code></pre> <p>AEFProfile vendorSpecific looks like:</p> <pre><code>\"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n}\n</code></pre> <p>Complete ETSI MEC ServiceAPIDescription with vendor extensibility would be like this:</p> <pre><code>{\n \"apiName\": \"service_1\",\n \"vendorSpecific-urn:etsi:mec:capifext:service-info\": {\n \"serializer\": \"JSON\",\n \"state\": \"ACTIVE\",\n \"scopeOfLocality\": \"MEC_SYSTEM\",\n \"consumedLocalOnly\": \"True\",\n \"isLocal\": \"True\",\n \"category\": {\n \"href\": \"https://www.location.com\",\n \"id\": \"location_1\",\n \"name\": \"Location\",\n \"version\": \"1.0\"\n }\n },\n \"aefProfiles\": [\n {\n \"aefId\": \"string\",\n \"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n },\n \"versions\": [\n {}\n ],\n \"protocol\": \"HTTP_1_1\",\n \"dataFormat\": \"JSON\",\n \"securityMethods\": [\"PSK\"],\n \"interfaceDescriptions\": [\n {\n \"ipv4Addr\": \"string\",\n \"port\": 65535,\n \"securityMethods\": [\"PSK\"]\n }\n ]\n }\n ],\n \"description\": \"string\",\n \"supportedFeatures\": \"0\",\n \"shareableInfo\": {\n \"isShareable\": true,\n \"capifProvDoms\": [\n \"string\"\n ]\n },\n \"serviceAPICategory\": \"string\",\n \"apiSuppFeats\": \"fffff\",\n \"pubApiPath\": {\n \"ccfIds\": [\n \"string\"\n ]\n },\n \"ccfId\": \"string\"\n}\n</code></pre>"},{"location":"vendor-ext/vendor-ext/#discover-api","title":"Discover API","text":"<p>In order to use vendor-specific fields as filters in Discover API, vendor-specific query parameter shall be encoded as follows:</p> <pre><code>https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-<query parameter name>={\n \"target\": <string that contains the JSON pointer to the attribute in the resource representation>, \n \"value\": <query parameter value>\n}\n</code></pre> <p>Example:</p> <pre><code> https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-type={\n \"target\": \"/vendorSpecific-urn:etsi:mec:capifext:transport-info\", \n \"value\": \"REST_HTTP\"\n }\n</code></pre>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Introduction","text":""},{"location":"#what-is-opencapif","title":"What is OpenCAPIF?","text":"<p>OpenCAPIF is an open source implementation of the CAPIF Core Function APIs plus the logic and additional services required to fulfill the 3GPP requirements and deliver the expected functionality.</p> <p>CAPIF is the \u201cCommon API Framework\u201d defined by 3GPP to manage the APIs exposed by 3GPP networks in their northbound interfaces.</p> <p>3GPP specifications for CAPIF defines three types of entities:</p> <ul> <li>API Providers, which are the entities exposing APIs (e.g., NEF)</li> <li>API Invokers, which are the entities that consume APIs (e.g., Applications), and</li> <li>the CAPIF Core Function, which manages the relationships between the other two.</li> </ul> <p></p> <p>The CAPIF Core Function is the cornerstone of the Common API Framework and provides the following capabilities:</p> <ul> <li>Authenticating the API Invoker based on its identity and other information;</li> <li>Supporting mutual authentication with the API Invoker;</li> <li>Providing authorization for the API Invoker prior to accessing the exposed APIs;</li> <li>Publishing, storing, and supporting the discovery of service APIs information;</li> <li>Controlling the service API access based on PLMN operator configured policies;</li> <li>Storing the logs for the service API invocations and providing the service API invocation logs to authorized entities;</li> <li>Charging based on the logs of the service API invocations;</li> <li>Monitoring the service API invocations;</li> <li>Onboarding a new API Invoker and offboarding an API Invoker;</li> <li>Storing policy configurations related to CAPIF and service APIs;</li> <li>Support for accessing the logs for auditing (e.g., detecting abuse); and</li> <li>Support for publishing and discovery of service APIs information among CAPIF Core Function (CAPIF interconnection).</li> </ul> <p>The following diagram shows how API Invokers and API Providers interact with the CAPIF Core Function to Register in CAPIF, Publish APIs, Discover APIs and Consume APIs. It is important to highlight that the CAPIF Core Function is not a classical API Gateway. The API consumption takes place directly between the API Invoker and the API Provider. Therefore, CAPIF does not impact API performance in API consumption between API Invokers and API Providers.</p> <p></p> <p>If you want to know more about OpenCAPIF check The story behind openCAPIF</p>"},{"location":"#repository-structure","title":"Repository structure","text":"<p>You can check the code at OpenCAPIF Repository</p> <pre><code>CAPIF_API_Services\n\u2514\u2500\u2500\u2500helm\n\u2514\u2500\u2500\u2500monitoring\n\u2514\u2500\u2500\u2500services\n\u2514\u2500\u2500\u2500tests\n\u2514\u2500\u2500\u2500tools\n \u2514\u2500\u2500\u2500robot\n \u2514\u2500\u2500\u2500open_api_script\n</code></pre> <ul> <li>helm: This folder contains helm files to deploy capif under k8s environment.</li> <li>monitoring: This folder contains grafana helm files to deploy capif under k8s environment.</li> <li>services: Services developed following CAPIF API specifications. Also, other complementary services (e.g., NGINX and JWTauth services for the authentication of API consuming entities).</li> <li>tools: Auxiliary tools. Robot Framework related code and OpenAPI scripts.</li> <li>test: Tests developed using Robot Framework.</li> </ul>"},{"location":"#capif_api_services","title":"CAPIF_API_Services","text":"<p>This repository has the python-flask Mockup servers created with openapi-generator related with CAPIF APIS defined here: Open API Descriptions of 3GPP 5G APIs</p>"},{"location":"#how-to-test-capif-apis","title":"How to test CAPIF APIs","text":"<p>The above APIs can be tested either with POSTMAN tool or running the developed tests with Robot Framework.</p>"},{"location":"#test-plan-documentation","title":"Test Plan Documentation","text":"<p>Complete documentation of tests is available here: Test Plan Directory</p>"},{"location":"#robot-framework","title":"Robot Framework","text":"<p>In order to ensure that modifications over CAPIF services still fulfills the required functionality, the Robot Framework Test Suite must be successfully run.</p> <p>The Robot Test Suite covers the requirements described in the test plan at Test Plan Directory folder.</p> <p>Please check the Testing with Robot Framework Section</p>"},{"location":"#using-postman","title":"Using PostMan","text":"<p>You can also test the CAPIF flow using the Postman tool. To do this, we have created a collection with some examples of CAPIF requests with everything necessary to carry them out.</p> <p>For more information on how to test the APIs with POSTMAN, go to this POSTMAN Section.</p>"},{"location":"#important-urls","title":"Important urls:","text":""},{"location":"#mongo-capifs-db-dashboard","title":"Mongo CAPIF's DB Dashboard","text":"<pre><code>http://localhost:8082/ (if accessed from localhost) \n\nor\n\nhttp://<Mongo CAPIF Express Host IP>:8082/ (if accessed from another host)\n</code></pre>"},{"location":"#mongo-registers-db-dashboard","title":"Mongo Register's DB Dashboard","text":"<pre><code>http://localhost:8083/ (if accessed from localhost) \n\nor\n\nhttp://<Mongo Register Express Host IP>:8083/ (if accessed from another host)\n</code></pre>"},{"location":"#faq-documentation","title":"FAQ Documentation","text":"<p>Frequently asked questions can be found here: FAQ Section</p>"},{"location":"FAQ/","title":"Frequently Asked Questions (FAQ)","text":""},{"location":"FAQ/#does-the-user-have-to-develop-the-3-elements-of-the-provider-aef-amf-and-apf","title":"Does the user have to develop the 3 elements of the provider (AEF, AMF and APF)?","text":"<p>No, you only have to make the request to the \"/onboarding\" endpoint. In it you must specify a CSR for the AEF, APF and AMF and you will receive the certificates for each of them in the response.</p>"},{"location":"FAQ/#there-is-one-party-that-publishes-the-api-and-another-that-exposes-it-what-is-the-difference","title":"There is one party that publishes the API and another that exposes it, what is the difference?","text":"<p>There are different services, the APF, intended for publishing the APIs, and the AEF, intended so that the invoker can call it. The APF is what connects to the Capif Core Function to publish the service and when the service is up, you need the AEF service so that invokers can connect to it.</p>"},{"location":"FAQ/#before-publishing-an-api-do-you-have-to-be-registered-in-capif","title":"Before publishing an API, do you have to be registered in CAPIF?","text":"<p>Yes, before publishing an API you must register using the POST /register endpoint.</p>"},{"location":"FAQ/#where-is-the-registration-done","title":"Where is the registration done?","text":"<p>Registration is done in a REST API outside of the CAPIF specification taht we have implemented.</p>"},{"location":"FAQ/#is-the-username-and-password-chosen-by-the-user-when-registering-or-is-it-assigned-when-requesting-registration-to-capif-public-instance","title":"Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?","text":"<p>When you make the request to the \"/endpoint\" of register, you will be returned a username and a password determined by CAPIF.</p>"},{"location":"FAQ/#what-is-a-csr","title":"What is a CSR?","text":"<p>A CSR is a Certificate Signing Request. It is a generated data block where the certificate is planned to be installed and contains key information such as public key, organization, and location, and is used to request a certificate from a certificate authority (CA). In CAPIF, 3 CSRs are necessary to register a provider, for AEF, APF and AMF.</p>"},{"location":"FAQ/#when-doing-the-register_provider-where-can-i-find-the-csrs-that-are-generated","title":"When doing the register_provider where can I find the CSRs that are generated?","text":"<p>When using the \"register_provider\" command, if you add the \"debug\" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.</p>"},{"location":"FAQ/#how-to-use-the-example-client-capif_invoker_gui","title":"How to use the example client (CAPIF_INVOKER_GUI)?","text":"<p>First you have to make a \"./run.sh host:port\" indicating the address of the public CAPIF. Once the Docker containers are up, you have to do a \"./terminal_to_py_netapp.sh\" and then a \"python main.py\". At this point we will find ourselves in a console with some predefined commands to use the Client. If we press tab twice it will bring up the list of available commands.</p>"},{"location":"FAQ/#where-is-the-capif-public-instance-located","title":"Where is the CAPIF public instance located?","text":"<p>The CAPIF public instance can be found at the following URLs: - capif.mobilesandbox.cloud:37211 (HTTPS) - capif.mobilesandbox.cloud:37212 (HTTP)</p>"},{"location":"FAQ/#do-you-have-to-publish-3-apis-one-for-each-instance","title":"Do you have to publish 3 APIs? one for each instance?","text":"<p>No, you only have to publish a single API but each component is responsible for a specific service, whether publishing or exposing.</p>"},{"location":"FAQ/#once-the-api-is-published-is-it-always-active-or-do-you-have-to-republish-it-every-time-you-want-to-use-it","title":"Once the API is published, is it always active? Or do you have to republish it every time you want to use it?","text":"<p>It is better to unsubscribe the API every time you exit the application since otherwise it could be republished and it would be double.</p>"},{"location":"FAQ/#would-the-same-username-and-password-be-valid-for-different-invokers","title":"Would the same username and password be valid for different invokers?","text":"<p>Yes, a user can have multiple invokers at the same time, and as such, the username and password would be the same.</p>"},{"location":"FAQ/#what-is-the-notfication-destination-field-in-the-register_invoker-request","title":"What is the notfication destination field in the register_invoker request?","text":"<p>This is the callback URL used to notify events. CAPIF has an Event service to subscribe to that notifies actions such as a subscription to an API, a change in the state of an API...</p>"},{"location":"FAQ/#is-the-notification_destination-a-required-field-in-the-register_invoker","title":"Is the notification_destination a required field in the register_invoker","text":"<p>No, it is not mandatory, but if you do not enter it you will not receive any CAPIF events. For example, the APF may delete the API, you will not be notified that the API is no longer available.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-discover_service-function-in-the-invoker-client","title":"What is the purpose of the \"discover_service\" function in the invoker client?","text":"<p>The discover_service returns a json with all the services that exist exposed in CAPIF at that moment.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-get_security_auth-function-in-the-invoker-client","title":"What is the purpose of the \"get_security_auth\" function in the invoker client?","text":"<p>Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.</p>"},{"location":"FAQ/#what-is-the-purpose-of-the-register_security_context-function-in-the-invoker-client","title":"What is the purpose of the \"register_security_context\" function in the invoker client?","text":"<p>To consume the API it is necessary to have a Security Context registered with the data and the authentication method.</p>"},{"location":"FAQ/#is-a-user-the-same-as-an-exposer","title":"Is a user the same as an exposer?","text":"<p>No, a user registers in CAPIF and once done can have the role of invoker, provider or both.</p>"},{"location":"FAQ/#where-can-i-put-my-endpoint","title":"Where can I put my endpoint?","text":"<p>You have to set your endpoint when doing the \"publish_service\" functionality: <code>publish_service capif_ops/config_files/service_api_description_hello.json</code></p> <p>In the file \"service_api_description_hello.json\" you configure the service that is going to be exposed and by developing one to suit you, you expose your API.</p>"},{"location":"architecture/","title":"Introduction","text":""},{"location":"architecture/#architecture","title":"Architecture","text":"<p>The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:</p> <p></p> <p>Each component is separated into different namespaces and all communications between them use Rest APIs.</p> <p>Apart from the communication between components, there are 2 other entities that can use them:</p> <ul> <li>Admin/superadmin: Responsible for managing users with the Register or carrying out special operations in the CCF.</li> <li>Users: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the CCF.</li> </ul>"},{"location":"architecture/#register-ns","title":"Register NS","text":"<p>This namespace belongs to the Register service, and we find 2 components:</p> <ul> <li>Register Service: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.</li> <li>Register MONGO DATABASE: It is the Register database, in it we store all the information about registered users.</li> </ul>"},{"location":"architecture/#vault-ns","title":"Vault NS","text":"<p>This namespace belongs to Vault. </p> <p>This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.</p>"},{"location":"architecture/#mon-ns","title":"Mon NS","text":"<p>This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:</p> <ul> <li>NGINX: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.</li> <li>REDIS: Used for internal communication of services.</li> <li>CAPIF MONGO DATABASE: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.</li> <li>HELPER: Service that simplifies integration with third parties such as external management portals.</li> </ul>"},{"location":"architecture/#new-architecture","title":"New Architecture","text":"<p>You can check the details of all these changes in the conversation on the OCF wiki.</p>"},{"location":"releasenotes/","title":"Release Notes","text":""},{"location":"releasenotes/#release-3xx","title":"Release 3.x.x","text":""},{"location":"releasenotes/#new-features","title":"New Features","text":""},{"location":"releasenotes/#added-event-filters","title":"Added Event Filters","text":"<ul> <li>Check Event Filter section</li> <li>New filters for Event service subscriptions.<ul> <li>You can now specify from which API, AEF, or Invoker you want to receive the event notifications.</li> <li>These filters are specified in the eventFilters of the subscription if the Enhanced Event Report feature of the Supported Features is activated.</li> </ul> </li> <li>More detailed information about event filters can be found in [Event Filter].</li> </ul>"},{"location":"releasenotes/#testing","title":"Testing","text":"<ul> <li>New Event Filter test suite with 8 tests. Event Filter test suite</li> </ul>"},{"location":"releasenotes/#technical-debt-solved","title":"Technical Debt Solved","text":"<ul> <li>Implemented in the API Provider Management the supported features negotiation for the suppFeat field during provider registration. The server now decodes the negotiated feature set based on client capabilities and system support.</li> </ul>"},{"location":"releasenotes/#hardening-on-startup-scripts-for-services-interacting-with-vault","title":"Hardening on startup scripts for services interacting with Vault","text":"<p>The startup scripts of the Invoker Management Service, Provider Management Service, and Security Service have been improved to ensure reliability when the Vault service takes longer to become ready. These new scripts check responses from the Vault to ensure the returned information is valid before starting each service.</p> <p>This will also helps on the restart issue on k8s deployed OpenCAPIF.</p>"},{"location":"releasenotes/#dynamic-configurations","title":"Dynamic configurations","text":"<ul> <li>Add new collection in CAPIF mongo with the init configuration.</li> <li>New endpoints in Helper to manage the CAPIF configuration.</li> <li>Add new collection in Register mongo with the init configuration.</li> <li>New endpoints in Register to manage the Register configuration.</li> <li>Documentation about Dynamic Configuration.</li> <li>Documentation about Helper and Register swaggers.</li> </ul>"},{"location":"releasenotes/#documentation","title":"Documentation","text":""},{"location":"releasenotes/#improvements-over-documentation","title":"Improvements over documentation","text":"<ul> <li>New Event Filter section</li> <li>New Vendor Extensibility section</li> <li>New API Status section</li> <li>New Dynamic Configuration section</li> </ul>"},{"location":"releasenotes/#testplan","title":"Testplan","text":"<ul> <li>New tests related with Api Status Feature.</li> <li>New tests related with Event Filter Feature.</li> <li>New tests related with Vendor Extensibility</li> <li>Security Service Testplan updated according to new features and Technical debts.</li> </ul>"},{"location":"releasenotes/#release-200","title":"Release 2.0.0","text":""},{"location":"releasenotes/#new-features_1","title":"New Features","text":""},{"location":"releasenotes/#upgrade-code-to-3gpp-capif-release-18","title":"Upgrade code to 3GPP CAPIF release 18","text":"<ul> <li>New endpoints included in new release 18 with new logic.</li> <li>Supported Features now are mandatory for all POST and PUT Requests as is described on TS 29.222. To keep in mind:<ul> <li>All POST/PUT request now must include Supported Features attribute, default can me set to <code>0</code> to keep all features inactive.</li> <li>On subscription to Event, if you need eventDetails information on notification you must activate Enhanced Event Report feature by setting properly the Supported Features flag.</li> </ul> </li> <li>Detailed information about models and endpoints upgrade on Upgrade Release 17 to 18 Wiki</li> </ul>"},{"location":"releasenotes/#vendor-extensibility","title":"Vendor Extensibility","text":"<ul> <li>Check Vendor Extensibility section</li> <li>Publish API:<ul> <li>On publishing a service API, SupportedFeatures is read and checked whether VendExt feature is enabled.</li> <li>When VendExt is enabled, vendor-specific fields are searched and stored in the db inside the ServiceAPIDescription object</li> <li>Vendor-specific fields are added according to the specific format:</li> </ul> </li> </ul> <pre><code>\n \"vendorSpecific-urn:<organization>:<field name>\": {\n \"key1\": \"value1\",\n ...\n \"keyN\": \"valueN\",\n }\n\n e.g. \n \"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n }\n\n where organization is \"etsi:mec\" and field name \"capifext:transport-info\"\n\n</code></pre> <ul> <li>Discover API:<ul> <li>On Discover request SupportedFeatures is read and checked whether VendSpecQueryParams feature is enabled.</li> <li>When VendSpecQueryParams is enabled, vendor-specific query parameters are parsed</li> <li>Vendor specific query parameters are added on the GET request according to the following format:</li> </ul> </li> </ul> <pre><code> https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-<query parameter name>={\n \"target\": <string that contains the JSON pointer to the attribute in the resource representation>, \n \"value\": <query parameter value>\n }\n\n e.g. \n https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-type={\n \"target\": \"/vendorSpecific-urn:etsi:mec:capifext:transport-info\", \n \"value\": \"REST_HTTP\"\n }\n</code></pre>"},{"location":"releasenotes/#api-status-feature","title":"Api Status feature","text":"<ul> <li>Check API Status section</li> <li>New logic to support API Status feature on Publish and Events Services.</li> <li>Events API:<ul> <li>Event internal notifications between services improved to accomplish specification.</li> <li>On event subscription SupportedFeatures is read and stored in db to accomplish specification.</li> <li>Also SupportedFeatures is checked before send event notification, in order to accomplish specification, sending eventDetails and related information according to enhanced_event_report and apiStatusMonitoring supported features activated.</li> </ul> </li> </ul>"},{"location":"releasenotes/#remote-scripts","title":"Remote Scripts","text":"<p>New scripts developed to help on remote deployment, configuration and testing. All this script are stored under helm/scripts in capif repository.</p> <p>variables.sh contains all configuration that will be used on remote operation. This file must be filled carefully before run remote scripts.</p> <ul> <li> <p>Deployment Scripts:</p> <ul> <li>install_vault.sh: Deploy Vault component from k8s cluster, only needed if vault is not previously deployed. If it\u2019s deployed you can setup vault token on variables.sh.</li> <li>install_monitoring.sh: Deploy monitoring on k8s cluster.</li> <li>install_capif.sh: Deploy OpenCAPIF on k8s cluster. It will be deployed on configured namespace with domain and hostnames configured under variables.sh.</li> <li>uninstall_vault.sh: Rollback Vault component from k8s cluster.</li> <li>uninstall_monitoring.sh: Rollback monitoring components from k8s cluster.</li> <li>uninstall_capif.sh: Rollback OpenCAPIF from k8s cluster.</li> </ul> </li> <li> <p>Manage remote users:</p> <ul> <li>create_remote_users.sh: This script create users setup by parameters on deployed OpenCAPIF. Those users are created by administrator.</li> <li>remove_remote_users.sh: This script removes user from deployed OpenCAPIF.</li> <li>remove_remote_users_by_prefix.sh:: This script removes users by prefix.</li> </ul> </li> <li> <p>Configuration of bastion machine, this simplify DNS fixed resolution:</p> <ul> <li>get_ingress.sh: This create a configuration for dns fixed resolution for ingress configured in namespace passed by parameters.</li> <li>set_ingress.sh: This scripts adds to /etc/hosts the fixed DNS resolution for ingress setup for namespace passed by parameters.</li> </ul> </li> <li> <p>Execute robot tests over remote deployment.</p> <ul> <li>run_remote_capif_tests.sh: This scripts launch Robot Test docker image on current machine to reach deployed OpenCAPIF. Is useful to launch with \u201c--include smoke\u201d in order to ensure all is deployed properly.</li> </ul> </li> <li> <p>Just for testing, next scripts upload dummy information to deployed OpenCAPIF:</p> <ul> <li>populate_create_remote_dummy_users.sh: : Create Dummy providers and invokers, publish service APIs and creates security context for invokers.</li> <li>populate_remove_remote_dummy_users.sh: Remove dummy information created.</li> </ul> </li> </ul>"},{"location":"releasenotes/#new-tools-and-components","title":"New Tools and Components","text":""},{"location":"releasenotes/#sdk","title":"SDK","text":"<p>New Python SDK is developed in order to simplify the creation and operation of providers and invokers. Please check the SDK repository for more information, there you can get more information about how to use it and also how to contibute to it.</p>"},{"location":"releasenotes/#provider-and-invoker-example-clients","title":"Provider and Invoker example Clients","text":"<p>In order to help developers to create their own invokers/providers entities and try the behavior of the OpenCAPIF, we also add to the OCF respository two example with console interaction at example clients repository:</p> <ul> <li>invoker-cli</li> <li>provider-cli</li> </ul> <p>More information on README of each component.</p>"},{"location":"releasenotes/#testing_1","title":"Testing","text":"<ul> <li>New Vendor Extensibility test suite with 9 tests. Api Events Service</li> <li>New API Status feature test suite with 20 tests.</li> <li>Improved Events test suite with 8 new tests.</li> <li>Test plan updated with default supported features for all request set to \"0\" (all inactive by default) See common operations.</li> </ul>"},{"location":"releasenotes/#technical-debt-solved_1","title":"Technical Debt Solved","text":""},{"location":"releasenotes/#local-scripts","title":"Local Scripts","text":"<ul> <li>All scripts were reviewed and improved.</li> <li>New scripts to manage users on local deployment added:<ul> <li>create_users.sh: This script create users setup by parameters in local deployment.. Those users are created by administrator.</li> <li>remove_users.sh: This script removes user in local deployment.</li> </ul> </li> </ul>"},{"location":"releasenotes/#issues","title":"Issues","text":"<ul> <li>Solved issue to get ready REDIS on deployment: REDIS scheduled on start to allow receive notification since service is deployed.</li> <li>Solved problem removing service APIs published is provider register more than one APF.</li> <li>Solved Superadmin problem deleting service API published through helper service if provider is not present.</li> <li>Increased the overall stability, fixing some corner cases.</li> <li>Location headers now are filled in same way at all services that needs it.</li> <li>Security issues solved.</li> <li>Base docker images present on ETSI registry.</li> <li>Robot image uploaded to ETSI Registry.</li> </ul>"},{"location":"releasenotes/#documentation_1","title":"Documentation","text":"<ul> <li>Postman examples are updated, including flows.</li> <li>New tests are detailed descripted on Test plan section</li> <li>New Contribute section.</li> <li>New SDK Section</li> </ul>"},{"location":"releasenotes/#release-100","title":"Release 1.0.0","text":""},{"location":"releasenotes/#new-features_2","title":"New Features","text":""},{"location":"releasenotes/#registration-flow-improved","title":"Registration Flow improved","text":"<ul> <li>Eliminated access from CAPIF to the Register user database when onboarding is performed.</li> <li>Isolation between CCF and Register services, interaction now is only by HTTPS requested between Register, CCF and Vault.</li> <li>Eliminated the \"role\" in user creation.<ul> <li>Now a user can be an invoker or a provider at the same time</li> </ul> </li> <li>Administrator User:<ul> <li>New entity in charge of registering and managing users of the register service.</li> </ul> </li> <li>UUID to identify users.<ul> <li>When you create a user, a uuid is associated with it</li> <li>The uuid will be contained in the token requested by the user and will be used to relate invokers and providers with users.</li> </ul> </li> <li>Endpoints changed and created:<ul> <li>Administrator endpoints:<ul> <li>/createUser: /register endpoint changed to createUser. Used to register new users.</li> <li>/deleteUser: /remove endpoint changed to this. Used to delete users and all the entities they had created.</li> <li>/login: Allows administrator to log in to obtain the necessary tokens for their requests.</li> <li>/refresh: Retrieve new access token token.</li> <li>/getUsers: Returns the list with all registered users.</li> </ul> </li> <li>Customer User:<ul> <li>/getauth now also returns the urls needed to use CAPIF, used by customer.</li> </ul> </li> </ul> </li> <li> <p>Security improvements:</p> <ul> <li>/login uses basic auth with administrator credentials.</li> <li>/getauth uses basic auth with customer user credentials.</li> <li>Other requests use the administrator access token obtained from login.</li> </ul> </li> <li> <p>Current fields on user creation by administrator:</p> </li> </ul> <pre><code>required_fields = {\n \"username\": str,\n \"password\": str,\n \"enterprise\": str,\n \"country\": str,\n \"email\": str,\n \"purpose\": str\n}\n\noptional_fields = {\n \"phone_number\": str,\n \"company_web\": str,\n \"description\": str\n}\n</code></pre> <ul> <li>Test plan has been updated with the new register flow. Please check OCF Registration Flow</li> <li>Video with explanation and demonstration of new register flow New Registration Demo</li> </ul>"},{"location":"releasenotes/#new-opencapif-architecture","title":"New OpenCAPIF architecture","text":"<ul> <li>New arquitecture with separated namespaces for Vault, CCF and Register components. Communication between them now are only allowed by using REST APIs.</li> <li> <p>New helper service inside CCF, it will simplify integration with third parties like external management portals.</p> </li> <li> <p>Helper endpoints:</p> <ul> <li>/getInvokers : Get the list of invokers from CAPIF</li> <li>/getProviders: Get the list of providers from CAPIF</li> <li>/getServices : Get the list of services published in CAPIF</li> <li>/getSecurityContext : Get the list of security contexts from CAPIF</li> <li>/getEvents : Get the list of events subscriptions from CAPIF</li> <li>/deleteEntities: Removes all entities registered by a user from the register</li> </ul> </li> <li> <p>Security in the helper</p> <ul> <li>To make requests to the helper you will need a superadmin certificate and password.</li> </ul> </li> </ul>"},{"location":"releasenotes/#events-api-upgrade","title":"Events API Upgrade","text":"<ul> <li>The event management at CCF is improved, EventNotification include Event Details with required information.</li> <li>Events updated:<ul> <li>SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE with apiIds</li> <li>SERVICE_API_UPDATE with serviceAPIDescriptions</li> <li>API_INVOKER_ONBOARDED, API_INVOKER_UPDATED, API_INVOKER_OFFBOARDED with apiInvokerIds.</li> </ul> </li> <li>Events Included:<ul> <li>SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE with invocationLogs</li> </ul> </li> <li>Test plan include 7 new tests in order to check new events implemented and scenarios of each notification implemented, with a complete check of Event Notification.</li> <li>Test plan documentation includes the new event tests OCF Event test plan documentation.</li> </ul>"},{"location":"releasenotes/#inital-implementation-of-cicd","title":"Inital implementation of CI/CD","text":"<ul> <li>The inital implementation of CI/CD on gitlab was performed.</li> <li>Detailed information in the CICD Wiki.</li> <li>Implement initial CI/CD:<ul> <li>Description of the CI process.<ul> <li>In CI phase, created design, jobs and security checks when a branch is pushed.</li> <li>The CI has jobs as:<ul> <li>Linting code, unit test (if needed),</li> <li>Build and push artifacts (images) in Git OCI register</li> <li>Security checks,</li> <li>SCA, CVS, SAST</li> <li>The vulnerabilities are exposed in Merge Request panel to be solved.</li> </ul> </li> </ul> </li> <li>Description of the CD process:<ul> <li>Defined the environments to OCF.<ul> <li>Production env.</li> <li>Pre-production env.</li> <li>Validation env.</li> <li>Dev-1, dev-2\u2026 envs (ephemeral)</li> </ul> </li> <li>Defined the naming convention to OCF releases<ul> <li>Tag in prod: v0.0.1-release</li> <li>Tag non-prod: v0.0.1-rc</li> <li>Other tags: v0.0.1-test, v0.0.1-smt</li> </ul> </li> <li>Defined the jobs of CD<ul> <li>CD ensures the deployment in multiple envs. Therefore, the CD pipeline has deploy-ocf, delete-ocf (if needed) jobs</li> </ul> </li> </ul> </li> <li>ETSI HIVE Labs:<ul> <li>Designed, created and the Kuberntes OCF cluster is running to support OCFs deployments.</li> <li>Iterating with ETSI HIVE\u2019s support to solve computing issues.<ul> <li>CPU compatibilities with OCF services (MongoDB): Fixed</li> </ul> </li> </ul> </li> </ul> </li> </ul>"},{"location":"releasenotes/#documentation_2","title":"Documentation","text":""},{"location":"releasenotes/#improvements-on-documentation","title":"Improvements on documentation","text":"<ul> <li>Documentation stored in OCF Documentation Repository</li> <li>Continuous Integration included at repository for web documentation:<ul> <li>Develop version of documentation is automatically generated on each merge to develop branch.</li> <li>Tagged version from main create documentation with related tag as version.</li> </ul> </li> </ul>"},{"location":"releasenotes/#technical-debt-solved_2","title":"Technical Debt Solved","text":""},{"location":"releasenotes/#improved-testing-with-robot-in-order-to-cover","title":"Improved Testing with Robot in order to cover","text":"<ul> <li>Support of new Register flows.</li> <li>Allow different URLs for register, ccf and vault services.</li> <li>New Variables included to manage new architecture under test.</li> <li>Mock server developed to add the functionality of write tests involving notification from Service Under Test.</li> <li>Docker image improved generation and libraries upgraded to Robot Framework 7.</li> </ul>"},{"location":"releasenotes/#improved-security-on-db","title":"Improved security on DB","text":"<ul> <li>Credentials requested to access mongo databases.</li> <li>Credentials requested also by mongo-express.</li> </ul>"},{"location":"releasenotes/#scripts-upgraded","title":"Scripts upgraded","text":"<ul> <li>Docker compose version 2 used on them.</li> <li>New cleaning script developed.</li> <li>Scripts upgraded:<ul> <li>check_services_are_running.sh: Checks if all essential services (Vault, CCF and Register) are running.</li> <li>clean_capif_docker_services.sh: Shutdowns and removes all services essential services.</li> <li>clean_capif_temporary_files.sh: Removes temporaly files from local repository. </li> <li>run.sh: Launch Essential services locally using docker compose, also monitoring can be launched.</li> <li>run_capif_tests.sh: Launch Robot Framwork Tests.</li> <li>show_logs.sh: Show locally logs of Services running.</li> <li>run_mock_server.sh: Launch mock server locally on all interfaces. This axiliary server is only used by tagged mockserver tests on Robot Framework.</li> <li>clean_mock_server.sh: Remove mock server local deployment.</li> <li>deploy.sh: This script simplify the way to download capif repository.</li> </ul> </li> </ul>"},{"location":"releasenotes/#codebase-improvements","title":"Codebase Improvements","text":"<ul> <li>Documentation is now on splitted repository OCF Documentation Repository</li> <li>Test plan was moved to OCF Documentation Repository</li> <li>Obsolote data is removed.</li> <li>Repository Reorganization: Enhanced structure and maintainability with a better directory layout and clearer module separation.</li> <li>Code Quality Enhancements: Refactored code and fixed known issues</li> </ul>"},{"location":"releasenotes/#migration-to-gunicorn","title":"Migration to GUNICORN","text":"<ul> <li>Include production server on each microservice: Release 0 use Flask developer server, now we use GUNICORN.</li> </ul>"},{"location":"releasenotes/#release-00","title":"Release 0.0","text":"<p>The APIs included in Release 0.0 are:</p> <ul> <li>JWT Authentication APIs</li> <li>CAPIF Invoker Management API</li> <li>CAPIF Publish API</li> <li>CAPIF Discover API</li> <li>CAPIF Security API</li> <li>CAPIF Events API</li> <li>CAPIF Provider Management API</li> </ul> <p>This Release also includes a Robot Test Suite for all those services and a Postman Test Suite for simple testing.</p>"},{"location":"api-status/api-status/","title":"API Status Feature","text":"<p>The API Status feature, introduced in the 3GPP Common API Framework (CAPIF) technical specifications starting from Release 17, offers significant enhancements for operators and developers.</p> <p>This feature in OpenCAPIF provides real-time insights into the operational status of APIs, enabling stakeholders to quickly determine whether an API is functioning as expected. By improving API availability tracking, it helps users make more informed decisions about integration and usage.</p>"},{"location":"api-status/api-status/#how-it-works","title":"How it works","text":"<p>This new functionality is found in two CAPIF services, the publish service and the events service.</p>"},{"location":"api-status/api-status/#publish-service","title":"Publish service","text":"<p>The API Status in the publish service allows providers to show in which AEFs the published API is available.</p> <p>In order to use the API Status, it is necessary to have apiStatusMonitoring enabled in supportedFeatures when publishing an API. With this enabled, we can use the publication's apiStatus, which is composed of a list of AEF identifiers in which the API is available.</p> <p>This gives us 4 options for displaying the status of an API:</p> <ul> <li>If the apiStatus contains a list of aefIds, the api will be available on all aefs in the list.</li> <li>If the apiStatus contains an empty list of aefIds it means that the API is NOT available in any AEF.</li> <li>If the apiStatus is not used, it is understood that the api is available in all AEFs of the aefProfiles.</li> <li>If the apiStatusMonitoring was not supported, the api would be available in all AEFs in the aefProfiles.</li> </ul> <p>If apiStatusMonitoring is not supported and apiStatus is used to show API availability, a 400 error will be returned.</p>"},{"location":"api-status/api-status/#events-service","title":"Events service","text":"<p>The API Status within the Events service provides critical insights into the availability of subscribed services.</p> <p>Both API Invokers and Providers can subscribe to the SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE events to receive timely notifications about the operational status of an API, whether it becomes available or unavailable.</p> <p>Additionally, if the enhanced_event_report function is supported, the API description could be received as event details in the eventDetails field if apiStatusMonitoring is also enabled. This will make it easier for event subscribers to know if any changes have been made to the API, such as a change in API availability to other AEFs.</p>"},{"location":"configuration/configuration/","title":"CAPIF Dynamic Configuration","text":""},{"location":"configuration/configuration/#overview","title":"Overview","text":"<p>CAPIF supports dynamic configuration management, enabling modifications without requiring redeployment. This is achieved by storing configurations in MongoDB collections for both CAPIF and Register services, allowing CAPIF to retrieve and apply configuration changes dynamically.</p> <p>This new approach provides:</p> <ul> <li>Real-time configuration updates: Modify parameters on the fly.</li> <li>Extensibility: Add new parameters or sections dynamically.</li> <li>Improved flexibility: Reduce static configuration dependencies.</li> </ul>"},{"location":"configuration/configuration/#capif-configuration","title":"CAPIF Configuration","text":"<p>In the CAPIF MongoDB instance, it is included a collection of the configuration.</p> <pre><code>capif_configuration: {\n \"config_name\": \"default\",\n \"version\": \"1.0\",\n \"description\": \"Default CAPIF Configuration\",\n \"settings\": {\n \"certificates_expiry\": {\n ttl_superadmin_cert: \"4300h\",\n ttl_invoker_cert: \"4300h\",\n ttl_provider_cert: \"4300h\",\n },\n \"security_method_priority\": {\n oauth: 1,\n pki: 2,\n psk: 3\n },\n \"acl_policy_settings\": {\n allowed_total_invocations: 5,\n allowed_invocations_per_second: 10,\n allowed_invocation_time_range_days: 365\n }\n }\n}\n</code></pre>"},{"location":"configuration/configuration/#register-configuration","title":"Register Configuration","text":"<p>Similarly, the Register service includes a dynamic configuration stored in its MongoDB instance:</p> <pre><code>capif_configuration: {\n \"config_name\": \"default\",\n \"version\": \"1.0\",\n \"description\": \"Default Register Configuration\",\n \"settings\": {\n \"certificates_expiry\": {\n ttl_superadmin_cert: \"4300h\",\n }\n }\n}\n</code></pre>"},{"location":"configuration/configuration/#configuration-management-endpoints","title":"Configuration Management Endpoints","text":"<p>Both CAPIF and the register configuration are managed via API, the general configuration of CAPIF from the Helper service and the register configuration from the register. In both services these endpoints enable:</p> <ol> <li> <p>Retrieving the current configuration \u2013 View the existing settings stored in MongoDB.</p> </li> <li> <p>Modifying configuration parameters \u2013 Update specific values dynamically.</p> </li> <li> <p>Adding new configuration settings \u2013 Introduce additional parameters within existing sections or create entirely new sections in the configuration.</p> </li> </ol> <p>For more details, you can check the API documentation of the Helper and Register services:</p> <ul> <li>Helper Service API Documentation</li> <li>Register Service API Documentation</li> </ul>"},{"location":"contribute/documenting/","title":"Documenting","text":"<p>OpenCAPIF's documentation runs on MkDocs.</p>"},{"location":"contribute/documenting/#eligibility","title":"Eligibility","text":"<p>Documenting OpenCAPIF is limited to active contributors. So, if you:</p> <ol> <li>are an active member or participant;</li> <li>wish to contribute to it;</li> <li>you're ready!</li> </ol>"},{"location":"contribute/documenting/#system-and-structure","title":"System and Structure","text":"<p>MkDocs is a fast and simple static site generator that's geared towards building project documentation. Documentation source files are written in <code>Markdown</code>, and configured with a single <code>YAML</code> configuration file. Start by reading the introductory tutorial, then check the User Guide for more information.</p>"},{"location":"contribute/documenting/#how-does-it-work","title":"How does it work?","text":"<p>There are 2 ways to upgrade documentation published on the OCF Documentation website:</p> <ul> <li>Push any change on develop branch will force update of the develop version on the OCF Documentation website;</li> <li>Create a tag, this will create a version with the tag name on the OCF Documentation website.</li> </ul>"},{"location":"contribute/documenting/#branches","title":"Branches","text":"<p>This documentation repository has 2 protected branches:</p> <ul> <li>main: stable timeline on which tags are made;</li> <li>develop: edge timeline, also published on the OCF Documentation website.</li> </ul>"},{"location":"contribute/documenting/#structure","title":"Structure","text":"<p>In the <code>mkdocs.yml</code> file you will find the navigation structure of the documentation, there you can sections with sub-sections.</p> <p>For example:</p> <pre><code>nav:\n - Overview:\n - Introduction: index.md\n - Getting Started:\n - How to Run: ./gettingstarted/howtorun.md\n - Testing:\n - Test Plan: ./testing/testplan/README.md\n - Robot Framework: ./testing/robotframework/README.md\n - Postman: ./testing/postman/README.md\n - FAQ: ./FAQ.md\n</code></pre> <p>As you can see here, we have at the time of writing this page, 5 main sections:</p> <ul> <li>Overview: here we placed high-level information like version changelog, some initial scripts, ...;</li> <li>Getting Started: this section contains a simple way to start working with the project;</li> <li>Testing: detailed information of how to test OpenCAPIF, and test plan developed to ensure the code has all implemented functionality checked;</li> <li>Contribute: details about how to contribute code and docs;</li> <li>FAQ.</li> </ul> <p>Please take a moment to understand the current structure of the documentations and think to update after contributing if necessary.</p>"},{"location":"contribute/documenting/#main-page","title":"Main Page","text":"<p>The page shown first is at doc/index.md. That page should be updated with the latest changes of OpenCAPIF and should reference the version (useful shortcut is <code>{{{ documentation_version }}}</code>).</p>"},{"location":"contribute/documenting/#getting-started","title":"Getting Started","text":"<p>To contribute to OpenCAPIF's documentation, you need to follow these easy steps:</p> <p>1) Clone the Documentation repository with:</p> <pre><code>git clone https://labs.etsi.org/rep/ocf/documentation.git\n</code></pre> <p>2) Checkout the develop branch (incoming contributions are only accepted to the develop branch):</p> <pre><code>cd ./documentation\ngit checkout develop\n</code></pre> <p>3) Setup a virtual environment:</p> <ul> <li>On Linux/macOS:</li> </ul> <pre><code>python3 -m venv venv # Linux/macOS\nsource venv/bin/activate #Linux/macOS\n</code></pre> <ul> <li>On Windows:</li> </ul> <pre><code>python -m venv venv # Windows\nvenv\\Scripts\\activate # Windows\n</code></pre> <p>4) Setup a local <code>mkdocs</code> server by installing requirements:</p> <pre><code>python -m pip install -r requirements.txt\n</code></pre> <p>4) Wait for all downloads to finish and start the local <code>mkdocs</code> server:</p> <pre><code>mkdocs serve\n</code></pre> <p>5) Document! \ud83d\ude0a</p> <p>You should always make sure that the local MkDocs server terminal is not producing any <code>INFO</code>/<code>WARNING</code> messages regarding your contributions.</p>"},{"location":"contribute/documenting/#add-documentation-during-development","title":"Add Documentation During Development","text":"<p>To update the documentation properly during development, follow those additional steps:</p> <ol> <li>Create an issue on the documentation GitLab repository;</li> <li>Create a new branch with the develop branch as a source;</li> <li>Update the documentation and any relevant parts (ie: the <code>index.md</code> with new functionalities for the latest version or if a new test plan has been defined, remember to update the test plan documentation);</li> <li>Check if errors are not being produced by <code>mkdocs</code> locally;</li> <li>Commit and push changes to the new branch;</li> <li>Create a merge/pull request towards develop;</li> <li>Send the request for review and approval to at least one TSC Member.</li> </ol> <p>The documentation website supports branches, so your accepted changes will be reflected to the develop branch which then becomes the release branch after each corresponding cycle.</p>"},{"location":"contribute/documenting/#release-a-new-version-of-the-documentation","title":"Release a New Version of the Documentation","text":"<p>When OpenCAPIF code repository is ready for a new release, we need to follow these steps (made by a TSC Member):</p> <ol> <li>Create a PR from develop towards main;</li> <li>When develop is merged to main... then create a tag with the released version scheme... and you're done!</li> </ol>"},{"location":"event-filter/event-filter/","title":"Event Filter","text":"<p>The Event Filter is a feature of the CAPIF Events service that allows you to receive specific notifications about the events you are subscribed to. This tool is essential for efficiently managing and monitoring relevant events, ensuring that users receive only the information they need.</p>"},{"location":"event-filter/event-filter/#how-it-works","title":"How it works","text":"<p>To specify the desired filter during subscription, you can use the eventFilters field, provided that the Enhanced Event Report flag is enabled in the Supported Features characteristics.</p> <p>The eventFilters field consists of a list of filters that correspond one-to-one with the list of events in the events field. Thus, the first element of the filter list corresponds to the first element of the events list, the second filter element to the second event element, and so on.</p> <p>Each filter contains three lists:</p> <ul> <li>apiIds: Identifiers of the APIs from which you want to receive notifications.</li> <li>apiInvokerIds: Identifiers of the invokers from which you want to receive notifications.</li> <li>aefIds: Identifiers of the AEFs from which you want to receive notifications.</li> </ul> <p>Depending on the event you subscribe to, you can use one or more of these lists. The following table shows the filtering options available for each event:</p> Event apiIds aefIds apiInvokerIds SERVICE_API_AVAILABLE X SERVICE_API_UNAVAILABLE X SERVICE_API_UPDATE X API_INVOKER_ONBOARDED X API_INVOKER_OFFBOARDED X API_INVOKER_UPDATED X ACCESS_CONTROL_POLICY_UPDATE X X SERVICE_API_INVOCATION_SUCCESS X X X SERVICE_API_INVOCATION_FAILURE X X X API_TOPOLOGY_HIDING_CREATED API_TOPOLOGY_HIDING_REVOKED <p>In cases where 2 or 3 lists are specified simultaneously for an event, notifications will only be sent when there is at least one matching element in each of the subscription lists. For example, if you subscribe to the ACCESS_CONTROL_POLICY_UPDATE event using the apiIds and apiInvokerIds filter lists, you will only be notified when the access control policy update corresponds to an API in the apiIds list and an invoker in the apiInvokerIds list at the same time.</p>"},{"location":"example-clients/example-clients/","title":"Invoker and Provider CLIs","text":"<p>The Invoker and Provider CLIs serve as examples for developers and integrators looking to connect their Network Applications (NetApps) to CAPIF. </p> <p>They demonstrate, using Python, how to develop the necessary code for seamless communication with CAPIF, offering a practical guide to implementing the required API calls and interactions.</p>"},{"location":"example-clients/example-clients/#provider-cli","title":"Provider CLI","text":"<p>When using the Provider Console, users can create a provider entity that registers and publishes APIs to make them available within the CAPIF ecosystem. </p>"},{"location":"example-clients/example-clients/#commands","title":"Commands","text":"<p>With the provider console you can make the following requests to CAPIF:</p>"},{"location":"example-clients/example-clients/#provider_get_auth","title":"provider_get_auth","text":"<p>It is used to request the token and the ca_root certificate in order to perform the provider onboarding.</p> <pre><code>provider_get_auth <username> <password>\n</code></pre> <p>The token has an expiration time of 10 minutes, so if it expires you will have to request a new one.</p>"},{"location":"example-clients/example-clients/#register_provider","title":"register_provider","text":"<p>It is used to perform the onboarding of a provider.</p> <pre><code>register_provider <name>\n</code></pre> <p>This request uses the api_provider_domain.json file as a template and creates the certificates and keys for each of the entities that make up the Provider.</p>"},{"location":"example-clients/example-clients/#publish_service","title":"publish_service","text":"<p>It is used to publish an api as a provider.</p> <pre><code>publish_service <service file route>\n</code></pre> <p>For this request the demo_api_one.json file is used as a template.</p>"},{"location":"example-clients/example-clients/#get_services","title":"get_services","text":"<p>It is used to see what services the provider has published.</p> <pre><code>get_service \n</code></pre> <p>Returns a list of API names.</p>"},{"location":"example-clients/example-clients/#remove_service","title":"remove_service","text":"<p>It is used to unpublish an API.</p> <pre><code>remove_service <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#remove_provider","title":"remove_provider","text":"<p>It is used to remove the provider.</p> <pre><code>remove_provider\n</code></pre> <p>Once the provider is deleted, you will not be able to publish or perform other operations that require certificates.</p>"},{"location":"example-clients/example-clients/#additionally","title":"Additionally","text":"<p>In addition, an API example is provided with which you can see how the token used by invokers to use the API published by the provider is decrypted and used.</p> <p>Once the API is published, the file can be executed with the next command:</p> <pre><code>python3 service_oauth.py\n</code></pre> <p>With this, the API will be raised to be able to make the calls.</p>"},{"location":"example-clients/example-clients/#invoker-cli","title":"Invoker CLI","text":"<p>When using the Invoker Console, users can create an Invoker entity that discover APIs to consume them with the CAPIF ecosystem. </p>"},{"location":"example-clients/example-clients/#commands_1","title":"Commands","text":"<p>With the Invoker console you can make the following requests to CAPIF:</p>"},{"location":"example-clients/example-clients/#get_auth","title":"get_auth","text":"<p>It is used to request the token and CA cert to be able to perform the onboarding.</p> <pre><code>get_auth <username> <password>\n</code></pre> <p>The token has an expiration time of 10 minutes, so if it expires you will have to request a new one.</p>"},{"location":"example-clients/example-clients/#register_invoker","title":"register_invoker","text":"<p>It is usedd to perform the onboarding of an Invoker,</p> <pre><code>register_invoker <name>\n</code></pre> <p>This request uses the invoker_details.json file as a template and creates the certificate and keys of the Invoker.</p>"},{"location":"example-clients/example-clients/#discover_service","title":"discover_service","text":"<p>It is used to discover the APIs published in CAPIF.</p> <pre><code>discover_service\n</code></pre> <p>Returns a list with the names of the services published in CAPIF.</p>"},{"location":"example-clients/example-clients/#register_security_context","title":"register_security_context","text":"<p>It is used to make the request to create a security context.</p> <pre><code>register_security_context <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#get_security_auth","title":"get_security_auth","text":"<p>It is used to request the token necessary for the cunsumption of an API.</p> <pre><code>get_security_auth <api name>\n</code></pre>"},{"location":"example-clients/example-clients/#call_service","title":"call_service","text":"<p>It is used to consume the API</p> <pre><code>call_service <api name> <method> <endpoint> <body route>\n</code></pre> <p>For the request you must specify the name of the API you want to use, the method and endpoint you want to consume, and the path of the body to use.</p>"},{"location":"example-clients/example-clients/#remove_security_context","title":"remove_security_context","text":"<p>It is used to delete the created security context.</p> <pre><code>remove_security_context\n</code></pre>"},{"location":"example-clients/example-clients/#remove_invoker","title":"remove_invoker","text":"<p>It is used to delete the Invoker</p> <pre><code>remove_invoker\n</code></pre> <p>Once the invoker is deleted, you will not be able to discover or perform other operations that require the Invoker certificate.</p>"},{"location":"example-clients/example-clients/#other-commands","title":"Other commands","text":"<p>Apart from these operations, with the Invoker and Provider console you can also perform operations as administrator if you have a CAPIF instance locally.</p>"},{"location":"example-clients/example-clients/#admin-commands","title":"Admin commands","text":"<p>As an administrator, you can manage which users can use CAPIF with the following commands.</p>"},{"location":"example-clients/example-clients/#login_admin","title":"login_admin","text":"<p>It is used to login as an administrator and obtain the tokenes needed to perform admin operations</p> <pre><code>login_admin <admin username> <admin password>\n</code></pre>"},{"location":"example-clients/example-clients/#refresh_admin","title":"refresh_admin","text":"<p>It is used to refresh the tokenes of the admin user</p> <pre><code>refresh_admin\n</code></pre>"},{"location":"example-clients/example-clients/#register_user","title":"register_user","text":"<p>It is used to register a new user</p> <pre><code>register_user\n</code></pre> <p>uses the data in the credentials.properties file as the data to record.</p>"},{"location":"example-clients/example-clients/#remove_user","title":"remove_user","text":"<p>It is used to remove the created user.</p> <pre><code>remove_user\n</code></pre>"},{"location":"example-clients/example-clients/#tips","title":"Tips","text":"<p>This section explains some tips that may be useful for developers who are using consoles.</p>"},{"location":"example-clients/example-clients/#help-command","title":"help command","text":"<p>In both consoles you can use the help command to display a list of available commands.</p> <pre><code>help\n</code></pre>"},{"location":"example-clients/example-clients/#exit-command","title":"exit command","text":"<p>In both consoles you can use the exit command to exit the console.</p> <pre><code>exit\n</code></pre>"},{"location":"example-clients/example-clients/#delete-the-entities","title":"Delete the entities","text":"<p>It is recommended to delete all providers, Invokers and users created by the consoles if they are not going to be used anymore.</p>"},{"location":"example-clients/example-clients/#debug-mode","title":"debug mode","text":"<p>You can add the debug flag at the end of each command to show the complete inputs and outputs of each request and thus better understand what is being done.</p> <pre><code>register_invoker ocf debug\n</code></pre>"},{"location":"gettingstarted/howtorun/","title":"How to Run","text":"<p>Capif services are developed under services folder.</p>"},{"location":"gettingstarted/howtorun/#downloading-the-project","title":"Downloading the project","text":"<p>You can easily download CAPIF to run in local environment following next steps:</p>"},{"location":"gettingstarted/howtorun/#1-create-a-folder-to-download-the-project","title":"1. Create a folder to download the project","text":"<pre><code>mkdir OpenCAPIF\n\ncd OpenCAPIF\n</code></pre>"},{"location":"gettingstarted/howtorun/#2-download-the-deployment-script","title":"2. Download the deployment script","text":"<p>Download the deployment / environment preparation script (press here to directly download script):</p> <pre><code>wget https://labs.etsi.org/rep/ocf/capif/-/raw/staging/deploy.sh\n</code></pre> <p>Make it executable:</p> <pre><code>chmod +x deploy.sh\n</code></pre>"},{"location":"gettingstarted/howtorun/#3-run-the-deployment-script","title":"3. Run the deployment script","text":"<p>This script selects the branch for capif repository project to pull from.</p> <p>If you run the script without selecting a branch the the main branch is going to be selected.</p> <p>We recommend:</p> <ul> <li>main branch for the most stable experience and staging branch for an experience with the latest features (for staging branch installation, it is strongly advisable that you may as well follow the staging documentation)</li> </ul> <pre><code># ./deploy.sh [branch to fetch] [true or false (default) to install monitoring stack or not]\n\nsudo ./deploy.sh staging\n</code></pre> <p>We recommend running the deploy.sh script with root permissions! In other case, some directories may not be accessible by the project building tools and hinder the smooth installation.</p>"},{"location":"gettingstarted/howtorun/#run-all-capif-services-locally-with-docker-images","title":"Run All CAPIF Services locally with Docker images","text":"<p>To run using docker and docker compose, version 2.10 or higher, you must ensure you have those tools installed in your machine. Also to simplify the process, we have 3 scripts allowing docker images to deploy, check and cleanup.</p> <p>All these scripts are available under services directory.</p> <p>To run CAPIF APIs locally using docker and docker-compose you can use run.sh script:</p> <pre><code>./run.sh -h\n\nUsage: ./run.sh <options>\n -c : Setup different hostname for capif\n -m : Launch monitoring service\n -h : show this help\n</code></pre> <p>This script builds and runs all services using docker images, including mongodb and nginx locally and in the background, and imports ca.crt to nginx. By default monitoring is not activated and Nginx is deployed use capifcore as a hostname.</p> <p>Some examples of use:</p> <pre><code># Default values, No monitoring and capifcore as CAPIF_HOSTNAME\n./run.sh\n\n# opencapif.etsi.org as CAPIF_HOSTNAME\n./run.sh -c opencapif.etsi.org\n\n# opencapif.etsi.org as CAPIF_HOSTNAME and monitoring activated\n./run.sh -c opencapif.etsi.org -m \n\n</code></pre> <p>IMPORTANT NOTE: In some versions change of hostname in local deployment (setting some value different than capifcore) creates wrong certificates on vault component. This prevents successful requests using the certificates. if this is your case, here is a little workaround to solve this issue meanwhile SDG is solving it:</p> <ul> <li>Modify the hostname in the file capif/services/vault/vault_prepare_certs.sh on lines 43, 68, and 95.</li> <li>Update the url parameter of the CCF from capifcore to the desired hostname in the file capif/services/register/config.yaml.</li> </ul> <p>If you want to check if all CAPIF services are running properly in a local machine after executing run.sh, you can use:</p> <pre><code>./check_services_are_running.sh\n</code></pre> <p>This shell script will return 0 if all services are running properly.</p> <p>When we need to stop all CAPIF services, we can use next bash script:</p> <pre><code>./clean_capif_docker_services.sh -a\n</code></pre> <p>NOTE: You can use different flags if you only want to stop some of them, please check the help using:</p> <pre><code>./clean_capif_docker_services.sh -h\n\nUsage: clean_capif_docker_services.sh <options>\n -c : clean capif services\n -v : clean vault service\n -r : clean register service\n -m : clean monitoring service\n -a : clean all services\n -h : show this help\n</code></pre> <p>This shell script will remove and clean all CAPIF services started previously with run.sh</p> <p>On the other hand you can check logs using show_logs.sh script, please check options:</p> <pre><code>./show_logs.sh\nYou must specify an option when running the script.\nUsage: ./show_logs.sh <options>\n -c : Show capif services\n -v : Show vault service\n -r : Show register service\n -m : Show monitoring service\n -a : Show all services\n -f : Follow log output\n -h : Show this help\n</code></pre> <p>You can also use option -f in order to follow log output in real time</p>"},{"location":"gettingstarted/howtorun/#run-all-capif-services-locally-with-docker-images-and-deploy-monitoring-stack","title":"Run All CAPIF Services locally with Docker images and deploy monitoring stack","text":"<p>It is now possible to deploy a monitoring stack for CAPIF with Grafana, Prometheus, FluentBit, Loki, Cadvisor, Tempo and Opentelemetry.</p> <p>To deploy CAPIF together with the monitoring stack, it is only necessary to execute the following.</p> <pre><code>./run.sh -m true\n</code></pre> <p>After they have been built, the different panels can be consulted in Grafana at the url</p> <pre><code>http://localhost:3000\n</code></pre> <p>By default, the monitoring option is set to false. Once up, all data sources and dashboards are automatically provisioned.</p>"},{"location":"gettingstarted/howtorun/#run-each-service-using-docker","title":"Run each service using Docker","text":"<p>Also you can run OpenCAPIF service by service using docker:</p> <pre><code>cd <Service>\ndocker build -t capif_security .\ndocker run -p 8080:8080 capif_security\n</code></pre>"},{"location":"gettingstarted/howtorun/#run-each-service-using-python","title":"Run each service using Python","text":"<p>Run using python</p> <pre><code>cd <Service>\npip3 install -r requirements.txt\npython3 -m <service>\n</code></pre>"},{"location":"gettingstarted/howtorun/#start-your-testing-with-opencapif","title":"Start Your Testing with OpenCAPIF","text":"<p>Related with OpenCAPIF Testing, the following sections help you to understand testing implemented and how to run it by yourself:</p> <ul> <li>Test Plan Directory: Here you can find the complete test plan definition that are accomplish by all versions released of OpenCAPIF.</li> <li>Testing with Robot Framework: At this section you can find all information about how to run the test suite implemented using Robot Framework.</li> <li>Testing with Postman: Easy way to understand the complete basic OpenCAPIF flow, acting as invoker and provider.</li> </ul>"},{"location":"helper/helper/","title":"Introduction to the Helper Service","text":""},{"location":"helper/helper/#overview","title":"Overview","text":"<p>CAPIF does not include any built-in mechanism to expose data via API. This makes it difficult to retrieve essential information such as the number of registered API Invokers, a list of available API Invokers, etc.</p> <p>Without a dedicated tool, accessing this data requires direct database queries, making it inefficient and impractical.</p>"},{"location":"helper/helper/#helper-service","title":"Helper Service","text":"<p>The Helper Service addresses this limitation by acting as an intermediary that exposes CAPIF\u2019s stored data in a structured and accessible manner. This service provides APIs that allow users to query the CAPIF database and obtain valuable insights, such as:</p> <ul> <li>The total count and details of registered API Invokers and API Providers.</li> <li>A structured and API-driven way to retrieve CAPIF-related information.</li> <li>Simplified access to important data without the need for direct database interactions.</li> <li>Access to security contexts, helping manage authentication and authorization processes.</li> <li>Retrieval of event records, providing insight into CAPIF system activities.</li> <li>The ability to delete different CAPIF entities, facilitating resource management.</li> <li>Full control over CAPIF dynamic configuration, including:<ul> <li>Retrieving the current configuration.</li> <li>Modifying specific parameters.</li> <li>Adding or updating configuration settings dynamically.</li> </ul> </li> </ul> <p>By this Helper Service, CAPIF users can effortlessly retrieve and manage critical system information, improving overall visibility and efficiency.</p>"},{"location":"helper/helper/#api-documentation","title":"API Documentation","text":"<p>For a detailed API reference, please check the Helper Service Swagger Documentation:</p> <p>\u27a1\ufe0f Helper Service API Documentation</p>"},{"location":"helper/swagger/","title":"Swagger","text":""},{"location":"helper/swagger/#helper-api-documentation","title":"Helper API Documentation","text":""},{"location":"register/register/","title":"Register Service","text":""},{"location":"register/register/#overview","title":"Overview","text":"<p>The Register Service is responsible for user management within the CAPIF ecosystem. It provides a structured way to register, authenticate, and manage user that interact with CAPIF, ensuring a secure and efficient process.</p>"},{"location":"register/register/#api-documentation","title":"API Documentation","text":"<p>For more details, refer to the API documentation:</p> <ul> <li>Register Service API Documentation</li> </ul>"},{"location":"register/swagger/","title":"Swagger","text":""},{"location":"register/swagger/#register-api-documentation","title":"Register API Documentation","text":""},{"location":"sandbox/relevantinfo/","title":"Relevant Information","text":"<p>This section provides users with essential details to interact with the OpenCAPIF Sandbox, including endpoint URLs, example requests, and client implementation references.</p>"},{"location":"sandbox/relevantinfo/#public-sandbox-urls","title":"Public Sandbox URLs","text":"<p>Below are the key endpoints required for API interactions within the sandbox environment:</p> <ul> <li>Registration Service: <code>https://register-opencapif.etsi.org</code></li> <li>OpenCAPIF Service: <code>https://opencapif.etsi.org</code></li> </ul>"},{"location":"sandbox/relevantinfo/#postman-collection-and-flows","title":"Postman collection and flows","text":"<p>To facilitate API testing and integration, we provide example requests that can be used in Postman:</p> <ul> <li>Postman Collection for OpenCAPIF: A ready-to-use collection with predefined requests to interact with the sandbox APIs including flows.</li> </ul>"},{"location":"sandbox/relevantinfo/#example-client-implementations","title":"Example Client Implementations","text":"<p>For users who wish to integrate OpenCAPIF into their applications, we provide invoker and provider example clients:</p> <ul> <li>Invoker Client: invoker-cli Repository</li> <li>Provider Client: provider-cli Repository</li> </ul> <p>These resources are continuously updated to align with the latest OpenCAPIF developments, ensuring users have access to functional and relevant examples.</p>"},{"location":"sandbox/relevantinfo/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sandbox/requestaccess/","title":"How to Request Access","text":"<p>To request access to the OpenCAPIF Sandbox, users can choose one of the following methods:</p> <ul> <li>Email Request: Send an email to OCF_TECH with the required information.</li> <li>Slack Channel: Contact us through the OpenCAPIF User an Developer Communities Slack channel #sandbox-access and provide the necessary details.</li> </ul>"},{"location":"sandbox/requestaccess/#required-information","title":"Required Information","text":"<p>Regardless of the method chosen, users must include the following details in their request:</p> <ul> <li>Company Name: The name of the organization requesting access.</li> <li>Purpose of Access: A brief description of why access is needed.</li> <li>Contact Information: Email address (mandatory), telephone number (optional).</li> <li>Preferred Username: A desired username for the account (subject to availability; may require modification if already in use).</li> </ul> <p>Once the request is received, the OpenCAPIF team will review the details and provide the necessary credentials or follow up if additional information is required.</p>"},{"location":"sandbox/requestaccess/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sandbox/sandbox/","title":"Introduction","text":"<p>The OpenCAPIF Sandbox is a dedicated environment designed to allow developers, researchers, and potential users to explore and test the latest developments in OpenCAPIF. This controlled setting provides a safe and isolated space to interact with OpenCAPIF APIs, ensuring that users can evaluate functionalities, experiment with integrations, and validate use cases without affecting live systems.</p>"},{"location":"sandbox/sandbox/#benefits-of-using-the-sandbox","title":"Benefits of Using the Sandbox","text":"<ul> <li>Risk-Free Testing: Users can experiment with the latest OpenCAPIF features without impacting production environments.</li> <li>Hands-On Experience: Gain practical insights into OpenCAPIF capabilities through real API interactions.</li> <li>Rapid Prototyping: Test and refine API integrations efficiently before deploying in real-world scenarios.</li> <li>Up-to-Date Environment: Always access the most recent OpenCAPIF developments and improvements.</li> </ul> <p>For more details on accessing the Sandbox and utilizing its features, please refer to the following sections:</p> <ul> <li>Request Access: Learn how to create a user account and obtain credentials to interact with the Sandbox.</li> <li>Relevant Information: Find important details such as endpoint URLs and links to example use cases in the documentation.</li> </ul>"},{"location":"sandbox/sandbox/#disclaimer","title":"Disclaimer","text":"<p>The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.</p>"},{"location":"sdk/sdk/","title":"SDK","text":"<p>Check SDK repository for further information.</p>"},{"location":"testing/postman/","title":"Postman","text":"<p>This section shows how OpenCAPIF is used through requests made with Postman, from the creation of a provider together with the publication of an api, to the creation of an invoker and the consumption of the published api. Everything you need to run the test is in Postman-Test.zip.</p>"},{"location":"testing/postman/#requisites","title":"Requisites","text":"<ul> <li>We will need to have Node.js installed since we will use a small script to create the CSRs of the certificates.</li> <li>An instance of CAPIF (If it is not local, certain variables would have to be modified both in the Node.js script and in the Postman environment variables).</li> </ul>"},{"location":"testing/postman/#first-steps","title":"First steps","text":"<ol> <li>Install the Node dependencies package.json to run the script with:</li> </ol> <pre><code>npm i\n</code></pre> <ol> <li>Run the script.js with the following command:</li> </ol> <pre><code>node script.js\n</code></pre> <ol> <li>Import Postman collection and environment variables (CAPIF.postman_collection.json and CAPIF.postman_environment.json)</li> <li>Select CAPIF Environment before start testing.</li> <li>Install the necessary dependencies from requirements.txt using the following command:</li> </ol> <pre><code>pip install -r requirements.txt\n</code></pre>"},{"location":"testing/postman/#remote-capif","title":"Remote CAPIF","text":"<p>If the CAPIF is not local, the host and port of both the CAPIF and the register would have to be specified in the variables, and the CAPIF_HOSTNAME in the script, necessary to obtain the server certificate.</p> <p>Enviroments in Postman</p> <pre><code>CAPIF_HOSTNAME capifcore\nCAPIF_PORT 8080\nREGISTER_HOSTNAME register\nREGISTER_PORT 8084\n</code></pre> <p>Const in script.js</p> <pre><code>CAPIF_HOSTNAME capifcore\n</code></pre>"},{"location":"testing/postman/#capif-flows","title":"CAPIF Flows","text":"<p>Once the first steps have been taken, we can now use Postman requests. These requests are numbered in the order that must be followed to obtain everything necessary from CAPIF.</p>"},{"location":"testing/postman/#creation-of-user-by-admin","title":"Creation of User by Admin","text":"<p>The first step would be for an administrator to create a user with which a provider and an invoker will be created. To do this, the admin must log in to obtain the token needed in admin requests.</p>"},{"location":"testing/postman/#01-login_admin","title":"01-Login_admin","text":""},{"location":"testing/postman/#02-creation-of-user","title":"02-Creation of User","text":""},{"location":"testing/postman/#publication-of-an-api","title":"Publication of an API","text":"<p>The next step is to register a provider using the user created by the administrator in order to publish an API.</p>"},{"location":"testing/postman/#03-getauth_provider","title":"03-getauth_provider","text":""},{"location":"testing/postman/#04-onboard_provider","title":"04-onboard_provider","text":""},{"location":"testing/postman/#05-publish_api","title":"05-publish_api","text":"<p>At this point we move on to using certificate authentication in CAPIF. In Postman it is necessary to add the certificates manually and using more than one certificate for the same host as we do in CAPIF complicates things. For this reason, we use the script to overwrite a certificate and a key when it is necessary to have a specific one.</p> <p>To configure go to settings in Postman and open the certificates section. </p> <ul> <li>Here, activate the CA certificates option and add the ca_cert.pem file found in the Responses folder.</li> <li>Adds a client certificate specifying the CAPIF host being used and the files client_cert.crt and client_key.key in the Responses folder.</li> </ul> <p>Once this is done, the node script will be in charge of changing the certificate that is necessary in each request.</p> <p></p> <p>Once the api is published, we can start it. In this case we have a test one created in python called hello_api.py that can be executed with the following command:</p> <pre><code>python3 hello_api.py\n</code></pre> <p>The API publication interface is set to localhost with port 8088, so the service must be set up locally. If you wanted to build it on another site, you would have to change the interface description in the body of publish_api.</p> <p>With this the provider part would be finished.</p>"},{"location":"testing/postman/#calling-the-api","title":"Calling the API","text":"<p>Finally, we will create an invoker with the user given by the administrator to be able to use the published api.</p>"},{"location":"testing/postman/#06-getauth_invoker","title":"06-getauth_invoker","text":""},{"location":"testing/postman/#07-onboard_invoker","title":"07-onboard_invoker","text":""},{"location":"testing/postman/#08-discover","title":"08-discover","text":"<p>At this point we move on to using certificate authentication in CAPIF. If you did not configure the provider's certificates, you would have to do it now.</p> <p></p>"},{"location":"testing/postman/#09-security_context","title":"09-security_context","text":""},{"location":"testing/postman/#10-get_token","title":"10-get_token","text":""},{"location":"testing/postman/#11-call_service","title":"11-call_service","text":"<p>With this, we would have made the API call and finished the flow.</p>"},{"location":"testing/postman/#other-requests","title":"Other requests","text":"<p>Other requests that we have added are the following:</p> <ul> <li>offboard_provider Performs offboarding of the provider, thereby eliminating the published APIs.</li> <li>offboard_invoker Offboards the invoker, also eliminating access to the APIs of that invoker.</li> <li>remove_user Delete the user.</li> <li>refresh_admin_token Return a new access token to the admin.</li> </ul>"},{"location":"testing/postman/#notes","title":"Notes","text":"<ul> <li>This process is designed to teach how requests are made in Postman and the flow that should be followed to publish and use an API.</li> <li>It is possible that if external CAPIFs are used (Public CAPIF) the test data may already be used or the API already registered.</li> <li>It is necessary to have the Node service running to make the certificate change for the requests, otherwise it will not work.</li> <li>We are working on adding more requests to the Postman collection.</li> <li>This collection is a testing guide and is recommended for testing purposes only.</li> </ul>"},{"location":"testing/robotframework/","title":"Robot Framework","text":""},{"location":"testing/robotframework/#steps-to-test","title":"Steps to Test","text":"<p>To run any test locally you will need docker and docker-compose installed in order run services and execute test plan. Steps will be:</p> <ul> <li> <p>Run All Services: See section Run All CAPIF Services</p> </li> <li> <p>Run desired tests: At this point we have 2 options:</p> </li> <li> <p>Using helper script: Script Test Execution</p> </li> <li>Build robot docker image and execute manually robot docker: Manual Build And Test Execution</li> </ul>"},{"location":"testing/robotframework/#script-test-execution","title":"Script Test Execution","text":"<p>This script will build robot docker image if it's need and execute tests selected by \"include\" option. Just go to service folder, execute and follow steps.</p> <pre><code>./run_capif_tests.sh --include <TAG>\n</code></pre> <p>Results will be stored at /results <p>Please check parameters (include) under Test Execution at Manual Build And Test Execution.</p>"},{"location":"testing/robotframework/#mock-server","title":"Mock Server","text":"<p>Some tests on Test Plans require mockserver. That mock server must be deployed and reachable by Robot Framework and CCF under test.</p> <p>To run Mock Server locally you can just execute the next script:</p> <pre><code>cd services\n./run_mock_server.sh\n\nor\n./run.sh -s\n</code></pre> <p>If you want to launch only tests that not needed mockserver, just add \"--exclude mockserver\" parameter to robot execution:</p> <pre><code>./run_capif_tests.sh --include <TAG> --exclude mockserver\n</code></pre> <p>After run tests the Mock Server can be removed from local deployment:</p> <pre><code>./clean_mock_server.sh\n\nor\n./clean_capif_docker_services.sh -s\n</code></pre>"},{"location":"testing/robotframework/#manual-build-and-test-execution","title":"Manual Build And Test Execution","text":"<ul> <li>Build Robot docker image:</li> </ul> <pre><code>cd tools/robot\ndocker build . -t capif-robot-test:latest\n</code></pre> <ul> <li>Tests Execution:</li> </ul> <p>Execute all tests locally:</p> <pre><code><PATH_TO_REPOSITORY>=path in local machine to repository cloned.\n<PATH_RESULT_FOLDER>=path to a folder on local machine to store results of Robot Framework execution.\n<CAPIF_HOSTNAME>=Is the hostname set when run.sh is executed, by default it is capifcore.\n<CAPIF_HTTP_PORT>=This is the port to reach when robot framework want to reach CAPIF deployment using http, this should be set to port without TLS set on Nginx, 8080 by default.\n<CAPIF_HTTPS_PORT>=This is the port to be used when we want to use https connection, this should be set to port with TLS set on Nginx, 443 by default\n<CAPIF_REGISTER>=This is the hostname of register service deployed. By default it is register.\n<CAPIF_REGISTER_PORT>=This is the port to be used to reach register service deployed. By default it is 8084.\n<CAPIF_VAULT>=This is the hostname of vault service. By default it is vault.\n<CAPIF_VAULT_PORT>=This is the port to be used to reach vault service. By default it is 8200.\n<CAPIF_VAULT_TOKEN>=Vault token to be used on request through vault. By default it is \"read-ca-token\".\n<MOCK_SERVER_URL>=Setup Mock server url to be used in notifications at tests marked with mockserver tag. By default it is not set.\n\nTo execute all tests run :\ndocker run -ti --rm --network=\"host\" \\\n --add-host host.docker.internal:host-gateway \\\n --add-host vault:host-gateway \\\n --add-host register:host-gateway \\\n --add-host mock-server:host-gateway \\\n -v <PATH_TO_REPOSITORY>/tests:/opt/robot-tests/tests \\\n -v <PATH_RESULT_FOLDER>:/opt/robot-tests/results capif-robot-test:latest \\\n --variable CAPIF_HOSTNAME:$CAPIF_HOSTNAME \\\n --variable CAPIF_HTTP_PORT:$CAPIF_HTTP_PORT \\\n --variable CAPIF_HTTPS_PORT:$CAPIF_HTTPS_PORT \\\n --variable CAPIF_REGISTER:$CAPIF_REGISTER \\\n --variable CAPIF_REGISTER_PORT:$CAPIF_REGISTER_PORT \\\n --variable CAPIF_VAULT:$CAPIF_VAULT \\\n --variable CAPIF_VAULT_PORT:$CAPIF_VAULT_PORT \\\n --variable CAPIF_VAULT_TOKEN:$CAPIF_VAULT_TOKEN \\\n --variable MOCK_SERVER_URL:$MOCK_SERVER_URL \\\n --include all\n</code></pre> <p>Execute specific tests locally:</p> <pre><code>To run more specific tests, for example, only one functionality:\n<TAG>=Select one from list:\n \"capif_api_acl\",\n \"capif_api_auditing_service\",\n \"capif_api_discover_service\",\n \"capif_api_events\",\n \"capif_api_invoker_management\",\n \"capif_api_logging_service\",\n \"capif_api_provider_management\",\n \"capif_api_publish_service\",\n \"capif_security_api\",\n \"api_status\",\n \"vendor_extensibility\",\n \"smoke\"\n\nAnd Run:\ndocker run -ti --rm --network=\"host\" \\\n --add-host host.docker.internal:host-gateway \\\n --add-host vault:host-gateway \\\n --add-host register:host-gateway \\\n --add-host mock-server:host-gateway \\\n -v <PATH_TO_REPOSITORY>/tests:/opt/robot-tests/tests \\\n -v <PATH_RESULT_FOLDER>:/opt/robot-tests/results capif-robot-test:latest \\\n --variable CAPIF_HOSTNAME:$CAPIF_HOSTNAME \\\n --variable CAPIF_HTTP_PORT:$CAPIF_HTTP_PORT \\\n --variable CAPIF_HTTPS_PORT:$CAPIF_HTTPS_PORT \\\n --variable CAPIF_REGISTER:$CAPIF_REGISTER \\\n --variable CAPIF_REGISTER_PORT:$CAPIF_REGISTER_PORT \\\n --variable CAPIF_VAULT:$CAPIF_VAULT \\\n --variable CAPIF_VAULT_PORT:$CAPIF_VAULT_PORT \\\n --variable CAPIF_VAULT_TOKEN:$CAPIF_VAULT_TOKEN \\\n --variable MOCK_SERVER_URL:$MOCK_SERVER_URL \\\n --include <TAG>\n</code></pre>"},{"location":"testing/robotframework/#test-result-review","title":"Test result review","text":"<p>In order to Review results after tests, you can check general report at /report.html or if you need more detailed information /log.html, example: <ul> <li> <p>Report: </p> </li> <li> <p>Detailed information: </p> </li> </ul> <p>NOTE: If you need more detail at Robot Framework Logs you can set log level option just adding to command --loglevel DEBUG</p>"},{"location":"testing/testplan/","title":"Test Plan Index","text":"<p>List of Common API Services implemented:</p> <ul> <li>Common Operations</li> <li>Api Invoker Management</li> <li>Api Provider Management</li> <li>Api Publish Service</li> <li>Api Discover Service</li> <li>Api Events Service</li> <li>Api Security Service</li> <li>Api Logging Service</li> <li>Api Auditing Service</li> <li>Api Access Control Policy</li> </ul>"},{"location":"testing/testplan/#features","title":"Features","text":"<ul> <li>Vendor Extensibility</li> <li>Api Status</li> <li>Event Filter</li> </ul>"},{"location":"testing/testplan/api_access_control_policy/","title":"Test Plan for CAPIF Api Access Control Policy","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_access_control_policy/#test-case-1-retrieve-acl","title":"Test Case 1: Retrieve ACL","text":"<p>Test ID: capif_api_acl-1</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-2-retrieve-acl-with-2-service-apis-published","title":"Test Case 2: Retrieve ACL with 2 Service APIs published","text":"<p>Test ID: capif_api_acl-2</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF for 2 different serviceApis published.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had two Service API Published on CAPIF</li> <li>API Invoker had a Security Context for both Service APIs published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information for service_1.</li> <li>Provider Get ACL information for service_2.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId1</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId2</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId2}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-3-retrieve-acl-with-security-context-created-by-two-different-invokers","title":"Test Case 3: Retrieve ACL with security context created by two different Invokers","text":"<p>Test ID: capif_api_acl-3</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL from CAPIF containing 2 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain two objects.</li> <li>One object must match with apiInvokerId1 and the other one with apiInvokerId2 an registered previously.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-4-retrieve-acl-filtered-by-api-invoker-id","title":"Test Case 4: Retrieve ACL filtered by api-invoker-id","text":"<p>Test ID: capif_api_acl-4</p> <p>Description:</p> <p>This test case will check that an API Provider can retrieve ACL filtering by apiInvokerId from CAPIF containing 1 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information with query parameter indicating first api-invoker-id.</li> <li>Provider Get ACL information with query parameter indicating second api-invoker-id.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId1</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={apiInvokerId1}</li> <li>Use serviceApiId, aefId and apiInvokerId1</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId2</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={apiInvokerId2}</li> <li>Use serviceApiId, aefId and apiInvokerId2</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with apiInvokerId1.</li> </ol> </li> </ol> </li> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with apiInvokerId2.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-5-retrieve-acl-filtered-by-supported-features","title":"Test Case 5: Retrieve ACL filtered by supported-features","text":"<p>Test ID: capif_api_acl-5</p> <p>Description:</p> <p>CURRENTLY NOT SUPPORTED FEATURE</p> <p>This test case will check that an API Provider can retrieve ACL filtering by supportedFeatures from CAPIF containing 1 objects.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>Two API Invokers had a Security Context for same Service API published by provider.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1 and service_2</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information with query parameter indicating first supported-features.</li> <li>Provider Get ACL information with query parameter indicating second supported-features.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker for both published APIs</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Repeat previous 3 steps in order to have a new Invoker.</p> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}&supported-features={apiInvokerId1}</li> <li>Use serviceApiId, aefId and apiInvokerId1</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL for serviceApiId</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId1}?aef-id=${aef_id}&supported-features={apiInvokerId2}</li> <li>Use serviceApiId, aefId and apiInvokerId2</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with supportedFeatures1.</li> </ol> </li> </ol> </li> <li> <p>ACL Response:</p> <ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>Contain one objects.</li> <li>Object must match with supportedFeatures1.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-6-retrieve-acl-with-aef-id-not-valid","title":"Test Case 6: Retrieve ACL with aef-id not valid","text":"<p>Test ID: capif_api_acl-6</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if aef-id is not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${AEF_ID_NOT_VALID}</li> <li>Use serviceApiId and AEF_ID_NOT_VALID</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {service_api_id}, aef_id: {aef_id}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-7-retrieve-acl-with-service-id-not-valid","title":"Test Case 7: Retrieve ACL with service-id not valid","text":"<p>Test ID: capif_api_acl-7</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if service-api-id is not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${NOT_VALID_SERVICE_API_ID}?aef-id=${aef_id}</li> <li>Use NOT_VALID_SERVICE_API_ID and aef_id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {service_api_id}, aef_id: {aef_id}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-8-retrieve-acl-with-service-api-id-and-aef-id-not-valid","title":"Test Case 8: Retrieve ACL with service-api-id and aef-id not valid","text":"<p>Test ID: capif_api_acl-8</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF if service-api-id and aef-id are not valid</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${NOT_VALID_SERVICE_API_ID}?aef-id=${AEF_ID_NOT_VALID}</li> <li>Use NOT_VALID_SERVICE_API_ID and aef_id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-9-retrieve-acl-without-securitycontext-created-previously-by-invoker","title":"Test Case 9: Retrieve ACL without SecurityContext created previously by Invoker","text":"<p>Test ID: capif_api_acl-9</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL if no invoker had requested Security Context to CAPIF</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker created but no Security Context for Service API published had been requested.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li> <p>Discover published APIs</p> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-10-retrieve-acl-filtered-by-api-invoker-id-not-present","title":"Test Case 10: Retrieve ACL filtered by api-invoker-id not present","text":"<p>Test ID: capif_api_acl-10</p> <p>Description:</p> <p>This test case will check that an API Provider get not found response if filter by not valid api-invoker-id doesn't match any registered ACL.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={NOT_VALID_API_INVOKER_ID}</li> <li>Use serviceApiId, aefId and NOT_VALID_API_INVOKER_ID</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: {api_invoker_id} and supportedFeatures: {supported_features}\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-11-retrieve-acl-with-apf-certificate","title":"Test Case 11: Retrieve ACL with APF Certificate","text":"<p>Test ID: capif_api_acl-11</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using APF Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use APF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-12-retrieve-acl-with-amf-certificate","title":"Test Case 12: Retrieve ACL with AMF Certificate","text":"<p>Test ID: capif_api_acl-12</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using AMF Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AMF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-13-retrieve-acl-with-invoker-certificate","title":"Test Case 13: Retrieve ACL with Invoker Certificate","text":"<p>Test ID: capif_api_acl-13</p> <p>Description:</p> <p>This test case will check that an API Provider can't retrieve ACL from CAPIF using Invoker Certificate</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_access_control_policy/#test-case-14-no-acl-for-invoker-after-be-removed","title":"Test Case 14: No ACL for invoker after be removed","text":"<p>Test ID: capif_api_acl-14</p> <p>Description:</p> <p>This test case will check that ACLs are removed after invoker is removed.</p> <p>Pre-Conditions:</p> <ul> <li>API Provider had a Service API Published on CAPIF</li> <li>API Invoker had a Security Context for Service API published and ACL is present</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Provider at CCF.</li> <li>Publish a provider API with name service_1</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Provider Get ACL information of invoker.</li> <li>Remove Invoker from CAPIF.</li> <li>Provider Get ACL information of invoker.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform Invoker Onboarding store apiInvokerId</p> </li> <li>Discover published APIs</li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Provider Retrieve ACL</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={api-invoker-id}</li> <li>Use serviceApiId, aefId and api-invoker-id</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Remove Invoker from CAPIF</li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}&api-invoker-id={api-invoker-id}</li> <li>Use serviceApiId, aefId and api-invoker-id</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result: 1. ACL Response: 1. 200 OK Response. 2. body returned must accomplish AccessControlPolicyList data structure. 3. apiInvokerPolicies must: 1. contain only one object. 2. apiInvokerId must match apiInvokerId registered previously.</p> <ol> <li>ACL Response:<ol> <li>404 Not Found Response.</li> <li>body returned must accomplish Problem Details data structure.</li> <li>apiInvokerPolicies must:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"No ACLs found for the requested service: {NOT_VALID_SERVICE_API_ID}, aef_id: {AEF_ID_NOT_VALID}, invoker: None and supportedFeatures: None\".</li> <li>cause with message \"Wrong id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/","title":"Test Plan for CAPIF Api Auditing Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_auditing_service/#test-case-1-get-capif-log-entry","title":"Test Case 1: Get CAPIF Log Entry.","text":"<p>Test ID: capif_api_auditing-1</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>200 OK</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-2-get-capif-log-entry-with-no-log-entry-in-capif","title":"Test Case 2: Get CAPIF Log Entry With no Log entry in CAPIF.","text":"<p>Test ID: capif_api_auditing-2</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found Log Entry in CAPIF\".</li> <li>cause with message \"Not Exist Logs with the filters applied\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-3-get-capif-log-entry-without-aef-id-and-api-invoker-id","title":"Test Case 3: Get CAPIF Log Entry without aef-id and api-invoker-id.","text":"<p>Test ID: capif_api_auditing-3</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is no pre-authorised (has no valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"aef_id and api_invoker_id parameters are mandatory\".</li> <li>cause with message \"Mandatory parameters missing\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-4-get-capif-log-entry-with-filtter-api-version","title":"Test Case 4: Get CAPIF Log Entry with filtter api-version.","text":"<p>Test ID: capif_api_auditing-4</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}&api-version={v1}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>200 OK</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_auditing_service/#test-case-5-get-capif-log-entry-with-filter-api-version-but-not-exist-in-log-entry","title":"Test Case 5: Get CAPIF Log Entry with filter api-version but not exist in log entry.","text":"<p>Test ID: capif_api_auditing-4</p> <p>Description:</p> <p>This test case will check that a CAPIF AMF can get log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid AMF cert from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> <li>Log Entry exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry 4. Get Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding, invoker onboarding </p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Log Entry:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Get Log:</p> <ol> <li>Send GET to https://{CAPIF_HOSTNAME}/logs/v1/apiInvocationLogs?aef-id={aefId}&api-invoker-id={api-invoker-id}&api-version={v58}</li> <li>Use AMF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>detail with message \"Parameters do not match any log entry\"</li> <li>cause with message \"No logs found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/","title":"Test Plan for CAPIF Discover Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_discover_service/#test-case-1-discover-published-service-apis-by-authorised-api-invoker","title":"Test Case 1: Discover Published service APIs by Authorised API Invoker","text":"<p>Test ID: capif_api_discover_service-1</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-2-discover-published-service-apis-by-non-authorised-api-invoker","title":"Test Case 2: Discover Published service APIs by Non Authorised API Invoker","text":"<p>Test ID: capif_api_discover_service-2</p> <p>Description:</p> <p>This test case will check that an API Publisher can't discover published APIs because is not authorized.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by no invoker entity</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs by no invoker entity:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use not Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By no invoker entity:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-3-discover-published-service-apis-by-not-registered-api-invoker","title":"Test Case 3: Discover Published service APIs by not registered API Invoker","text":"<p>Test ID: capif_api_discover_service-3</p> <p>Description:</p> <p>This test case will check that a not registered invoker is forbidden to discover published APIs.</p> <p>Pre-Conditions:</p> <ul> <li>Service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Publisher</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs with not valid apiInvoker:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={INVOKER_NOT_REGISTERED}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker does not exist\".</li> <li>cause with message \"API Invoker id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-4-discover-published-service-apis-by-registered-api-invoker-with-1-result-filtered","title":"Test Case 4: Discover Published service APIs by registered API Invoker with 1 result filtered","text":"<p>Test ID: capif_api_discover_service-4</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>At least 2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover filtered by api-name service_1 Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs filtering by api-name:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&api-name=service_1**</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> <li>filter by api-name service_1</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains previously registered Service APIs published.</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains only Service API published with api-name service_1</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-5-discover-published-service-apis-by-registered-api-invoker-filtered-with-no-match","title":"Test Case 5: Discover Published service APIs by registered API Invoker filtered with no match","text":"<p>Test ID: capif_api_discover_service-5</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>At least 2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover filtered by api-name not published Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs filtering by api-name not published:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&api-name=NOT_VALID_NAME</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> <li>filter by api-name NOT_VALID_NAME</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains previously registered Service APIs published.</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_discover_service/#test-case-6-discover-published-service-apis-by-registered-api-invoker-not-filtered","title":"Test Case 6: Discover Published service APIs by registered API Invoker not filtered","text":"<p>Test ID: capif_api_discover_service-6</p> <p>Description:</p> <p>This test case will check if Network App (Invoker) can discover published service APIs.</p> <p>Pre-Conditions:</p> <ul> <li>2 Service APIs are published.</li> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 and service_2 at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Discover without filter by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs not filtered:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the 2 previously registered Service APIs published.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/","title":"Test Plan for CAPIF Api Events Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_events_service/#test-case-1-creates-a-new-individual-capif-event-subscription","title":"Test Case 1: Creates a new individual CAPIF Event Subscription.","text":"<p>Test ID: capif_api_events-1</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) can Subscribe to Events</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-2-creates-a-new-individual-capif-event-subscription-with-invalid-subscriberid","title":"Test Case 2: Creates a new individual CAPIF Event Subscription with Invalid SubscriberId","text":"<p>Test ID: capif_api_events-2</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Subscribe to Events without valid SubcriberId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is not pre-authorised (has invalid InvokerId or apfId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{SUBSCRIBER_NOT_REGISTERED}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker or APF or AEF or AMF Not found\".</li> <li>cause with message \"Subscriber Not Found\".</li> </ul> </li> </ol> </li> <li> <p>Event Subscriptions are not stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-3-deletes-an-individual-capif-event-subscription","title":"Test Case 3: Deletes an individual CAPIF Event Subscription","text":"<p>Test ID: capif_api_events-3</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) can Delete an Event Subscription</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Remove Event Subscription</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subscription:</p> <ol> <li>Send DELETE to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li> <p>Remove Event Subscription:</p> <ol> <li>204 No Content</li> </ol> </li> <li> <p>Event Subscription is not present at CAPIF Database.</p> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-4-deletes-an-individual-capif-event-subscription-with-invalid-subscriberid","title":"Test Case 4: Deletes an individual CAPIF Event Subscription with invalid SubscriberId","text":"<p>Test ID: capif_api_events-4</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Delete to Events without valid SubcriberId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId).</li> <li>CAPIF subscriber is subscribed to Events.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve Location Header with subscriptionId.</li> <li>Remove Event Subscribed with not valid Subscriber.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subcription with not valid subscriber:</p> <ol> <li>Send DELETE to https://{CAPIF_HOSTNAME}/capif-events/v1/{SUBSCRIBER_ID_NOT_VALID}/subscriptions/{subcriptionId}</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li> <p>Error Response Body must accomplish with ProblemDetails data structure with:</p> <ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker or APF or AEF or AMF Not found\".</li> <li>cause with message \"Subscriber Not Found\".</li> </ul> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-5-deletes-an-individual-capif-event-subscription-with-invalid-subscriptionid","title":"Test Case 5: Deletes an individual CAPIF Event Subscription with invalid SubscriptionId","text":"<p>Test ID: capif_api_events-5</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (Invoker or Publisher) cannot Delete an Event Subscription without valid SubscriptionId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has invalid InvokerId or apfId).</li> <li>CAPIF subscriber is subscribed to Events.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events</li> <li>Retrieve Location Header with subscriptionId.</li> <li>Remove Event Subscribed with not valid Subscriber.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Remove Event Subcription with not valid subscriber:</p> <ol> <li>Send DELETE to to https://{CAPIF_HOSTNAME}/capif-events/v1/{subcriberId}/subscriptions/{SUBSCRIPTION_ID_NOT_VALID}</li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Event Subscriptions are stored in CAPIF Database</p> </li> <li>Remove Event Subscription with not valid subscriber:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>detail with message \"Service API not existing\".</li> <li>cause with message \"Event API subscription id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-6-invoker-receives-service-api-invocation-events","title":"Test Case 6: Invoker receives Service API Invocation events","text":"<p>Test ID: capif_api_events-6, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE, receive the notification when AEF Send TO logging service result of invocations to their APIs. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE event filtering by aefId. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Emulate Success and Failure on API invocation of provider by Invoker, using Invocation Logs API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']</li> <li>eventFilter: only receive events from provider's aefId.</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Create Log Entry emulating provider receive Success and Failure api invocation from invoker:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body with:<ol> <li>aefId from provider published.</li> <li>apiInvokerId from invoker onboarded.</li> <li>apiId of published API</li> <li>apiName of published API</li> <li>200 and 400 results in two logs.</li> </ol> </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to creation of log entry on CCF must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/api-invocation-logs/{apiVersion}/{aefId}/subscriptions/{logId}</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with invocationLog in eventDetail parameter.<ol> <li>One should be SERVICE_API_INVOCATION_SUCCESS related with 200 result at Log.</li> <li>The other one must be SERVICE_API_INVOCATION_FAILURE related with 400 result at Log.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-7-invoker-subscribe-to-service-api-available-and-unavailable-events","title":"Test Case 7: Invoker subscribe to Service API Available and Unavailable events","text":"<p>Test ID: capif_api_events-7, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, receive the notification when AEF publish and remove it. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE event. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Provider publish new API.</li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Publish new Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of service_2 published API.</li> <li>The other one must be SERVICE_API_UNAVAILABLE apiId of service_1 published API.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-8-invoker-subscribe-to-service-api-update","title":"Test Case 8: Invoker subscribe to Service API Update","text":"<p>Test ID: capif_api_events-8, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_UPDATE, receive the notification when AEF Update some information on API Published. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_UPDATE event. Enhanced_event_report active at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header at event subscription</li> <li>Provider update information of Service API Published.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> <li>Store serviceApiId</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_UPDATE:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> <li>eventFilter set to apiId from published API.</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body [service api description] with overrided apiName to service_1_modified**</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Update Published Service API:<ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified**</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with serviceAPIDescriptions in eventDetail parameter.<ol> <li>Event should be SERVICE_API_UPDATE with eventDetail with modified apiName.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-9-provider-subscribe-to-api-invoker-events","title":"Test Case 9: Provider subscribe to API Invoker events","text":"<p>Test ID: capif_api_events-9, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to API Invoker events (API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED), receive the notifications when Invoker is onboarded, updated and removed respectively. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Subscribe Provider to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events. Enhanced_event_report active at supported features.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> <li>Offboard Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Event Subscription to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['API_INVOKER_ONBOARDED', 'API_INVOKER_UPDATED', 'API_INVOKER_OFFBOARDED']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Perform invoker onboarding</li> <li>Update information of previously onboarded Invoker:<ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> <li>Offboard:<ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiInvokerIds in eventDetail parameter.<ol> <li>One Event should be API_INVOKER_ONBOARDED with eventDetail with modified apiInvokerId.</li> <li>One Event should be API_INVOKER_UPDATED with eventDetail with modified apiInvokerId.</li> <li>One Event should be API_INVOKER_OFFBOARDED with eventDetail with modified apiInvokerId.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-10-provider-subscribed-to-acl-update-event","title":"Test Case 10: Provider subscribed to ACL update event","text":"<p>Test ID: capif_api_events-10, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE receive a notification when ACL Changes. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>API Invoker had a Security Context for the Service API published by provider.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Provider to ACCESS_CONTROL_POLICY_UPDATE event. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UPDATE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UPDATE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, with accCtrlPolListExt in eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UPDATE with eventDetail with accCtrlPolListExt including the apiId and apiInvokerPolicies.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-11-provider-receives-an-acl-unavailable-event-when-invoker-remove-security-context","title":"Test Case 11: Provider receives an ACL unavailable event when invoker remove Security Context.","text":"<p>Test ID: capif_api_events-11, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to ACCESS_CONTROL_POLICY_UNAVAILABLE will receive the notification when AEF remove Security Context created previously. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE event. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL.</li> <li>Remove Security Context for Invoker.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Delete Security Context of Invoker by Provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Delete security context:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-12-invoker-receives-an-invoker-authorization-revoked-and-acl-unavailable-event-when-provider-revoke-invoker-authorization","title":"Test Case 12: Invoker receives an Invoker Authorization Revoked and ACL unavailable event when Provider revoke Invoker Authorization.","text":"<p>Test ID: capif_api_events-12, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to API_INVOKER_AUTHORIZATION_REVOKED and ACCESS_CONTROL_POLICY_UNAVAILABLE receive both notification when AEF revoke invoker's authorization. Enhanced Event Report feature must be active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED events. Enhanced_event_report active at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Revoke Authorization by Provider.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE','API_INVOKER_AUTHORIZATION_REVOKED']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Revoke Authorization by Provider:<ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>Revoke Authorization:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> <li>One Event should be API_INVOKER_AUTHORIZATION_REVOKED without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-13-creates-a-new-individual-capif-event-subscription-without-supported-features-attribute","title":"Test Case 13: Creates a new individual CAPIF Event Subscription without supported features attribute.","text":"<p>Test ID: capif_api_events-13</p> <p>Description:</p> <p>This test case will check error when CAPIF subscriber (Invoker or Publisher) Subscribe to Events without supported features attribute.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Subscribe to Events without supported features</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Event Subscription:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body<ol> <li>supportedFeatures NOT PRESENT.</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"supportedFeatures not present in request\".</li> <li>cause with message \"supportedFeatures not present\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-14-invoker-receives-service-api-invocation-events-without-enhanced-event-report","title":"Test Case 14: Invoker receives Service API Invocation events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-14, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE, receive the notification when AEF Send TO logging service result of invocations to their APIs. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Emulate Success and Failure on API invocation of provider by Invoker, using Invocation Logs API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Create Log Entry emulating provider receive Success and Failure api invocation from invoker:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body with:<ol> <li>aefId from provider published.</li> <li>apiInvokerId from invoker onboarded.</li> <li>apiId of published API</li> <li>apiName of published API</li> <li>200 and 400 results in two logs.</li> </ol> </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to creation of log entry on CCF must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/api-invocation-logs/{apiVersion}/{aefId}/subscriptions/{logId}</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_INVOCATION_SUCCESS related with 200 result at Log.</li> <li>The other one must be SERVICE_API_INVOCATION_FAILURE related with 400 result at Log.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-15-invoker-subscribe-to-service-api-available-and-unavailable-events-without-enhanced-event-report","title":"Test Case 15: Invoker subscribe to Service API Available and Unavailable events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-15, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, receive the notification when AEF publish and remove it. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header</li> <li>Provider publish new API.</li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Publish new Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_2</li> <li>Store serviceApiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of service_2 published API.</li> <li>The other one must be SERVICE_API_UNAVAILABLE apiId of service_1 published API.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-16-invoker-subscribe-to-service-api-update-without-enhanced-event-report","title":"Test Case 16: Invoker subscribe to Service API Update without Enhanced Event Report","text":"<p>Test ID: capif_api_events-16, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to SERVICE_API_UPDATE, receive the notification when AEF Update some information on API Published. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered and published APIs.</li> <li>API Provider had a Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider and publish one API at CCF</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover published APIs and extract apiIds and apiNames</li> <li>Subscribe to SERVICE_API_UPDATE event filtering by aefId. Enhanced_event_report inactive at supported features.</li> <li>Retrieve {subscriberId} and {subscriptionId} from Location Header at event subscription</li> <li>Provider update information of Service API Published.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> <li>Store serviceApiId</li> </ul> </li> <li> <p>Perform invoker onboarding</p> </li> <li> <p>Discover published APIs:</p> <ul> <li>Get Api Ids And Api Names from response.</li> </ul> </li> <li> <p>Event Subscription to SERVICE_API_UPDATE of provider previously registered:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_UPDATE']</li> <li>eventFilter: Not present.</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body [service api description] with overrided apiName to service_1_modified**</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Update Published Service API:<ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified**</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with serviceAPIDescriptions in eventDetail parameter.<ol> <li>Event should be SERVICE_API_UPDATE with eventDetail with modified apiName.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-17-provider-subscribe-to-api-invoker-events-without-enhanced-event-report","title":"Test Case 17: Provider subscribe to API Invoker events without Enhanced Event Report","text":"<p>Test ID: capif_api_events-17, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to API Invoker events (API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED), receive the notifications when Invoker is onboarded, updated and removed respectively. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Subscribe Provider to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events. Enhanced_event_report inactive at supported features.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> <li>Offboard Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Event Subscription to API_INVOKER_ONBOARDED, API_INVOKER_UPDATED and API_INVOKER_OFFBOARDED events:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['API_INVOKER_ONBOARDED', 'API_INVOKER_UPDATED', 'API_INVOKER_OFFBOARDED']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Perform invoker onboarding</li> <li>Update information of previously onboarded Invoker:<ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> <li>Offboard:<ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be API_INVOKER_ONBOARDED</li> <li>One Event should be API_INVOKER_UPDATED</li> <li>One Event should be API_INVOKER_OFFBOARDED</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-18-provider-subscribed-to-acl-update-event-without-enhanced-event-report","title":"Test Case 18: Provider subscribed to ACL update event without Enhanced Event Report","text":"<p>Test ID: capif_api_events-18, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE receive a notification when ACL Changes. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>API Invoker had a Security Context for the Service API published by provider.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Provider to ACCESS_CONTROL_POLICY_UPDATE event. Enhanced_event_report inactive at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UPDATE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UPDATE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Provider AMF Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UPDATE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-19-provider-receives-an-acl-unavailable-event-when-invoker-remove-security-context-without-enhanced-event-report","title":"Test Case 19: Provider receives an ACL unavailable event when invoker remove Security Context without Enhanced Event Report","text":"<p>Test ID: capif_api_events-19, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to ACCESS_CONTROL_POLICY_UNAVAILABLE will receive the notification when AEF remove Security Context created previously. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE event. Enhanced_event_report inactive at supported features.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Provider Retrieve ACL.</li> <li>Remove Security Context for Invoker.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Provider Retrieve ACL<ul> <li>Send GET https://{CAPIF_HOSTNAME}/access-control-policy/v1/accessControlPolicyList/${serviceApiId}?aef-id=${aef_id}</li> <li>Use serviceApiId and aefId</li> <li>Use AEF Provider Certificate</li> </ul> </li> <li>Delete Security Context of Invoker by Provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>ACL Response:<ol> <li>200 OK Response.</li> <li>body returned must accomplish AccessControlPolicyList data structure.</li> <li>apiInvokerPolicies must:<ol> <li>contain only one object.</li> <li>apiInvokerId must match apiInvokerId registered previously.</li> </ol> </li> </ol> </li> <li>Delete security context:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_events_service/#test-case-20-invoker-receives-an-invoker-authorization-revoked-and-acl-unavailable-event-when-provider-revoke-invoker-authorization-without-enhanced-event-report","title":"Test Case 20: Invoker receives an Invoker Authorization Revoked and ACL unavailable event when Provider revoke Invoker Authorization without Enhanced Event Report","text":"<p>Test ID: capif_api_events-20, mockserver</p> <p>Description:</p> <p>This test case will check that a CAPIF Invoker subscribed to API_INVOKER_AUTHORIZATION_REVOKED and ACCESS_CONTROL_POLICY_UNAVAILABLE receive both notification when AEF revoke invoker's authorization. Enhanced Event Report feature must be inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered.</li> <li>API Provider had one Service API Published on CAPIF</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF.</li> <li>Publish a provider API with name service_1.</li> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Subscribe Invoker to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED events.</li> <li>Discover APIs filtered by aef_id</li> <li>Create Security Context for Invoker.</li> <li>Revoke Authorization by Provider.</li> </ol> <p>Information of Test:</p> <ol> <li>Check and Clean Mock Server</li> <li>Perform provider registration</li> <li>Perform invoker onboarding</li> <li>Event Subscription to ACCESS_CONTROL_POLICY_UNAVAILABLE and API_INVOKER_AUTHORIZATION_REVOKED event:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['ACCESS_CONTROL_POLICY_UNAVAILABLE','API_INVOKER_AUTHORIZATION_REVOKED']</li> <li>eventFilters: apiInvokerIds array with apiInvokerId of invoker</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Discover published APIs</li> <li>Create Security Context for Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Revoke Authorization by Provider:<ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> <li>Revoke Authorization:<ol> <li>204 No Content response.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events has been received.</li> <li>Validate received event follow EventNotification data structure, without eventDetail parameter.<ol> <li>One Event should be ACCESS_CONTROL_POLICY_UNAVAILABLE without eventDetail.</li> <li>One Event should be API_INVOKER_AUTHORIZATION_REVOKED without eventDetail.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/","title":"Test Plan for CAPIF Api Invoker Management","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_invoker_management/#test-case-1-onboard-network-app","title":"Test Case 1: Onboard Network App","text":"<p>Test ID: capif_api_invoker_management-1</p> <p>Description:</p> <p>This test will try to register new Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was not registered previously</li> <li>Network App was not onboarded previously</li> <li>Preconditions: The administrator must have previously registered the User.</li> </ul> <p>Execution Steps:</p> <ol> <li>Retrieve access_token by User from register</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at invoker</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Onboard Invoker:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-2-onboard-network-app-already-onboarded","title":"Test Case 2: Onboard Network App Already onboarded","text":"<p>Test ID: capif_api_invoker_management-2</p> <p>Description:</p> <p>This test will check second onboard of same Network App is not allowed.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Network App at CCF</li> <li>Onboard Network App at CCF</li> <li>Store signed Certificate at Network App</li> <li>Onboard Again the Network App at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Repeat Onboard Invoker:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Second Onboard of Network App must accomplish:<ol> <li>403 Forbidden</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 403</li> <li>title with message \"Forbidden\"</li> <li>detail with message \"Invoker Already registered\".</li> <li>cause with message \"Identical invoker public key\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-3-update-onboarded-network-app","title":"Test Case 3: Update Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-3</p> <p>Description:</p> <p>This test will try to update information of previous onboard Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Update Onboarding Information at CCF with a minor change on \"notificationDestination\"</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Update information of previously onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-4-update-not-onboarded-network-app","title":"Test Case 4: Update Not Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-4</p> <p>Description:</p> <p>This test will try to update information of not onboarded Network App at CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was not onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Update Onboarding Information at CCF of not onboarded</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Update information of not onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{INVOKER_NOT_REGISTERED}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> </ol> </li> <li>Response to Update Request (PUT) must contain:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Please provide an existing Network App ID\".</li> <li>cause with message \"Not exist Network App ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-5-offboard-network-app","title":"Test Case 5: Offboard Network App","text":"<p>Test ID: capif_api_invoker_management-5</p> <p>Description:</p> <p>This test case will check that a Registered Network App can be deleted.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Offboard Invoker at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Offboard:</p> <ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> </ol> </li> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>204 No Content</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-6-offboard-not-previsouly-onboarded-network-app","title":"Test Case 6: Offboard Not previsouly Onboarded Network App","text":"<p>Test ID: capif_api_invoker_management-6</p> <p>Description:</p> <p>This test case will check that a Non-Registered Network App cannot be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was not onboarded previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Offboard Invoker at CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Offboard:</p> <ul> <li>Send DELETE to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{INVOKER_NOT_REGISTERED}</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Offboard Request (DELETE) must contain:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Please provide an existing Network App ID\".</li> <li>cause with message \"Not exist Network App ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_invoker_management/#test-case-7-update-onboarded-network-app-certificate","title":"Test Case 7: Update Onboarded Network App Certificate","text":"<p>Test ID: capif_api_invoker_management-7</p> <p>Description:</p> <p>This test will try to update public key and get a new signed certificate by CAPIF Core.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId} and {public_key_1}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker at CCF</li> <li>Onboard Invoker at CCF</li> <li>Store signed Certificate</li> <li>Update Onboarding Information at CCF with new public key</li> <li>Update Onboarding Information at CCF with minor change</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding with public_key_1.</p> </li> <li> <p>Create {public_key_2}</p> </li> <li> <p>Update information of previously onboarded Invoker:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>[\"onboardingInformation\"][\"apiInvokerPublicKey\"]: {public_key_2},</li> <li>Store new certificate.</li> </ul> </li> <li> <p>Update information of previously onboarded Invoker Using new certificate:</p> <ul> <li>Send PUT to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}</li> <li>Reference Request Body is: [put invoker onboarding body]</li> <li>\"notificationDestination\": \"http://host.docker.internal:8086/netapp_new_callback\",</li> <li>Use new Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Update Request (PUT) with new public key:<ol> <li>200 OK response.</li> <li>apiInvokerCertificate with new certificate on response -> store to use.</li> </ol> </li> <li>Response to Update Request (PUT) with minor change must contain:<ol> <li>200 OK response.</li> <li>notificationDestination on response must contain the new value</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/","title":"Test Plan for CAPIF Api Logging Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_logging_service/#test-case-1-creates-a-new-individual-capif-log-entry","title":"Test Case 1: Creates a new individual CAPIF Log Entry.","text":"<p>Test ID: capif_api_logging-1</p> <p>Description:</p> <p>This test case will check that a CAPIF AEF can create log entry to Logging Service</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid aefId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow InvocationLog data structure with:<ul> <li>aefId</li> <li>apiInvokerId</li> <li>logs</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invocation-logs/v1/{aefId}/logs/{logId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-2-creates-a-new-individual-capif-log-entry-with-invalid-aefid","title":"Test Case 2: Creates a new individual CAPIF Log Entry with Invalid aefId","text":"<p>Test ID: capif_api_logging-2</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is not pre-authorised (has not valid aefId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{not-valid-aefId}/logs</li> <li>body log entry request body</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Exposer not exist\".</li> <li>cause with message \"Exposer id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-3-creates-a-new-individual-capif-log-entry-with-invalid-serviceapi","title":"Test Case 3: Creates a new individual CAPIF Log Entry with Invalid serviceAPI","text":"<p>Test ID: capif_api_logging-3</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid aefId from CAPIF Authority)</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with serviceAPI apiName apiId not valid]</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not exist\".</li> <li>cause with message \"Invoker id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-4-creates-a-new-individual-capif-log-entry-with-invalid-apiinvokerid","title":"Test Case 4: Creates a new individual CAPIF Log Entry with Invalid apiInvokerId","text":"<p>Test ID: capif_api_logging-4</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid aefId from CAPIF Authority)</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with invokerId not valid]</li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> <li> <p>Response to Logging Service must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not exist\".</li> <li>cause with message \"Invoker id not found\".</li> </ul> </li> </ol> </li> <li> <p>Log Entry are not stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_logging_service/#test-case-5-creates-a-new-individual-capif-log-entry-with-invalid-aefid-in-body","title":"Test Case 5: Creates a new individual CAPIF Log Entry with Invalid aefId in body","text":"<p>Test ID: capif_api_logging-5</p> <p>Description:</p> <p>This test case will check that a CAPIF subscriber (AEF) cannot create Log Entry without valid aefId in body</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF provider is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>Service exist in CAPIF</li> <li>Invoker exist in CAPIF</li> </ul> <p>Execution Steps: 1. Register Provider and Invoker CCF 2. Publish Service 3. Create Log Entry</p> <p>Information of Test:</p> <ol> <li> <p>Perform provider onboarding and invoker onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body [service api description] with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Log Entry:</p> <ol> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invocation-logs/v1/{aefId}/logs</li> <li>body [log entry request body with bad aefId] </li> <li>Use AEF Certificate</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Logging Service must accomplish:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"AEF id not matching in request and body\".</li> <li>cause with message \"Not identical AEF id\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/","title":"Test Plan for CAPIF Api Provider Management","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_provider_management/#test-case-1-register-api-provider","title":"Test Case 1: Register Api Provider","text":"<p>Test ID: capif_api_provider_management-1</p> <p>Description:</p> <p>This test case will check that Api Provider can be registered con CCF</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid certificate from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Register Provider at Provider Management:<ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-2-register-api-provider-already-registered","title":"Test Case 2: Register Api Provider Already registered","text":"<p>Test ID: capif_api_provider_management-2</p> <p>Description:</p> <p>This test case will check that a Api Provider previously registered cannot be re-registered</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider.</li> <li>Re-Register Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Re-Register Provider:</p> <ul> <li>Same regSec than Previous registration</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Re-Register Provider:<ol> <li>403 Forbidden response.</li> <li> <p>body returned must accomplish ProblemDetails data structure, with:</p> <ul> <li>status 403</li> <li>title with message \"Forbidden\"</li> <li>detail with message \"Provider already registered\".</li> <li>cause with message \"Identical provider reg sec\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-3-update-registered-api-provider","title":"Test Case 3: Update Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-3</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Create private and public key for provider and each function to register.</li> <li>Register Provider</li> <li>Update Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Create public and private key at provider for provider itself and each function (apf, aef and amf)</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Get Resource URL from Location</li> </ul> </li> <li> <p>Update Provider:</p> <ul> <li>Send PUT to Resource URL returned at registration https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>body provider request body with apiProvDomInfo set to ROBOT_TESTING_MOD</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Register Provider:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> <li> <p>Update Provider:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure, with:<ul> <li>apiProvDomInfo set to ROBOT_TESTING_MOD</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-4-update-not-registered-api-provider","title":"Test Case 4: Update Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-4</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Update Not Registered Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Update Not Registered Provider:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_PROVIDER_NOT_REGISTERED}</li> <li>body provider request body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update Not Registered Provider:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-5-partially-update-registered-api-provider","title":"Test Case 5: Partially Update Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-5</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be partially updated</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Partial update provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Partial update provider:</p> <ul> <li>Send PATCH https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>body provider request patch body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Partial update provider at Provider Management:<ol> <li>200 OK response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure, with:<ul> <li>apiProvDomInfo with \"ROBOT_TESTING_MOD\"</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-6-partially-update-not-registered-api-provider","title":"Test Case 6: Partially Update Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-6</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be partially updated </p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Partial update provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Partial update Provider:</p> <ul> <li>Send PATCH https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_API_PROVIDER_NOT_REGISTERED}</li> <li>body provider request patch body</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Partial update provider:<ol> <li>404 Not Found response.</li> <li> <p>body returned must accomplish ProblemDetails data structure, with:</p> <ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-7-delete-registered-api-provider","title":"Test Case 7: Delete Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-7</p> <p>Description:</p> <p>This test case will check that a Registered Api Provider can be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider</li> <li>Delete Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Delete registered provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete Provider:<ol> <li>204 No Content response.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_provider_management/#test-case-8-delete-not-registered-api-provider","title":"Test Case 8: Delete Not Registered Api Provider","text":"<p>Test ID: capif_api_provider_management-8</p> <p>Description:</p> <p>This test case will check that a Non-Registered Api Provider cannot be deleted</p> <p>Pre-Conditions:</p> <ul> <li>Api Provider was not registered previously</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Create public and private key at provider for provider itself and each function (apf, aef and amf)</p> </li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Authentication Bearer with access_token</li> <li>Store each cert in a file with according name.</li> </ul> </li> <li> <p>Delete registered provider at Provider Management:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{API_PROVIDER_NOT_REGISTERED}</li> <li>Use AMF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete Provider:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Not Exist Provider Enrolment Details\".</li> <li>cause with message \"Not found registrations to Send THIS api provider details\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/","title":"Test Plan for CAPIF Api Publish Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_publish_service/#test-case-1-publish-api-by-authorised-api-publisher","title":"Test Case 1: Publish API by Authorised API Publisher","text":"<p>Test ID: capif_api_publish_service-1</p> <p>Description:</p> <p>This test case will check that an API Publisher can Publish an API</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li> <p>Register Provider at CCF and store certificates.</p> </li> <li> <p>Publish Service API</p> </li> <li> <p>Retrieve {apiId} from body and Location header with new resource created from response</p> </li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> </li> <li> <p>Send POST to ccf_publish_url: https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</p> </li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Published Service API is stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-2-publish-api-by-non-authorised-api-publisher","title":"Test Case 2: Publish API by NON Authorised API Publisher","text":"<p>Test ID: capif_api_publish_service-2</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Publish an API withot valid apfId </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API with invalid APF ID</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API with invalid APF ID at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{APF_ID_NOT_VALID}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Publisher not existing\".</li> <li>cause with message \"Publisher id not found\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-3-retrieve-all-apis-published-by-authorised-apfid","title":"Test Case 3: Retrieve all APIs Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-3</p> <p>Description:</p> <p>This test case will check that an API Publisher can Retrieve all API published</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>At least 2 service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API service_1</li> <li>Retrieve {apiId1} from body and Location header with new resource created from response</li> <li>Publish Service API service_2</li> <li>Retrieve {apiId2} from body and Location header with new resource created from response</li> <li>Retrieve All published APIs and check if both are present.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Other Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve all published APIs:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to service 1 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId1}</li> </ol> </li> <li> <p>Response to service 2 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId2}</li> </ol> </li> <li> <p>Published Service APIs are stored in CAPIF Database</p> </li> <li> <p>Response to Retrieve all published APIs:</p> <ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-4-retrieve-all-apis-published-by-non-authorised-apfid","title":"Test Case 4: Retrieve all APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-4</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Retrieve API published when apfId is not authorised </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Retrieve All published APIs</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Retrieve all published APIs:</p> <ul> <li>Send GET to https://{CAPIF_HOSTNAME}/published-apis/v1/{APF_ID_NOT_VALID}/service-apis</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>401 Non Authorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Provider not existing\".</li> <li>cause with message \"Provider id not found\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-5-retrieve-single-apis-published-by-authorised-apfid","title":"Test Case 5: Retrieve single APIs Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-5</p> <p>Description:</p> <p>This test case will check that an API Publisher can Retrieve API published one by one</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>At least 2 service APIs are published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API service_1.</li> <li>Retrieve {apiId1} from body and Location header with new resource created from response.</li> <li>Publish Service API service_2.</li> <li>Retrieve {apiId2} from body and Location header with new resource created from response.</li> <li>Retrieve service_1 API Detail.</li> <li>Retrieve service_2 API Detail.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Publish Other Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve service_1 published APIs detail:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{apiId1}</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve service_2 published APIs detail:</p> <ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{apiId2}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to service 1 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId1}</li> </ol> </li> <li> <p>Response to service 2 Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId2}</li> </ol> </li> <li> <p>Published Service APIs are stored in CAPIF Database</p> </li> <li> <p>Response to Retrieve service_1 published API using apiId1:</p> <ol> <li>200 OK</li> <li>Response body must return a ServiceAPIDescription data.</li> <li>Array must contain same information than service_1 published registration response.</li> </ol> </li> <li> <p>Response to Retrieve service_2 published API using apiId2:</p> <ol> <li>200 OK</li> <li>Response body must return a ServiceAPIDescription data.</li> <li>Array must contain same information than service_2 published registration response.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-6-retrieve-single-apis-non-published-by-authorised-apfid","title":"Test Case 6: Retrieve single APIs non Published by Authorised apfId","text":"<p>Test ID: capif_api_publish_service-6</p> <p>Description:</p> <p>This test case will check that an API Publisher try to get detail of not published api.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>No published api</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Retrieve not published API Detail.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration</li> <li>Retrieve not published APIs detail:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Retrieve for NOT published API must accomplish:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"No Service with specific credentials exists\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-7-retrieve-single-apis-published-by-non-authorised-apfid","title":"Test Case 7: Retrieve single APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-7</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Retrieve detailed API published when apfId is not authorised </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API at CCF</li> <li>Retrieve {apiId} from body and Location header with new resource created from response.</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Invoker Certificate</li> <li>Retrieve detailed published API acting as Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve detailed published APIs:</p> <ul> <li>Send GET to https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/${apiId}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Retrieve Detailed published API acting as Invoker must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> <li> <p>Service API is NOT stored in CAPIF Database</p> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-8-update-api-published-by-authorised-apfid-with-valid-serviceapiid","title":"Test Case 8: Update API Published by Authorised apfId with valid serviceApiId","text":"<p>Test ID: capif_api_publish_service-8</p> <p>Description:</p> <p>This test case will check that an API Publisher can Update published API with a valid serviceApiId </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> <li>A service APIs is published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API</li> <li>Retrieve {apiId} from body and Location header with new resource url created from response</li> <li>Update published Service API.</li> <li>Retrieve detail of Service API</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>get resource url from location Header.</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>body service api description with overrided apiName to service_1_modified</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve detail of service API:</p> <ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>check apiName is service_1_modified</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Update Published Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified</li> </ul> </li> </ol> </li> <li> <p>Response to Retrieve detail of Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1_modified.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-9-update-apis-published-by-authorised-apfid-with-invalid-serviceapiid","title":"Test Case 9: Update APIs Published by Authorised apfId with invalid serviceApiId","text":"<p>Test ID: capif_api_publish_service-9</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Update published API with a invalid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Update published Service API.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>body service api description with overrided apiName to service_1*_modified*</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Update Published Service API:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"Service API id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-10-update-apis-published-by-non-authorised-apfid","title":"Test Case 10: Update APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-10</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Update API published when apfId is not authorised</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is NOT pre-authorised (has invalid apfId from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API at CCF</li> <li>Retrieve {apiId} from body and Location header with new resource created from response.</li> <li>Register and onboard Invoker at CCF</li> <li>Store signed Invoker Certificate</li> <li>Update published API at CCF as Invoker</li> <li>Retrieve detail of Service API as publisher</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update published API at CCF:</p> <ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>body service api description with overrided apiName to service_1*_modified*</li> <li>Use Invoker Certificate</li> </ul> </li> <li> <p>Retrieve detail of service API:</p> <ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>check apiName is service_1</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Update published API acting as Invoker must accomplish:</p> <ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> <li> <p>Response to Retrieve Detail of Service API:</p> <ol> <li>200 OK</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiName service_1.</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-11-delete-api-published-by-authorised-apfid-with-valid-serviceapiid","title":"Test Case 11: Delete API Published by Authorised apfId with valid serviceApiId","text":"<p>Test ID: capif_api_publish_service-11</p> <p>Description:</p> <p>This test case will check that an API Publisher can Delete published API with a valid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> <li>A service APIs is published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Publish Service API</li> <li>Retrieve {apiId} from body and Location header with new resource created from response</li> <li>Remove published API at CCF</li> <li>Try to retreive deleted service API from CCF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Use APF Certificate</li> </ul> </li> <li>Retrieve detail of service API:<ul> <li>Send GET to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{serivceApiId}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Published Service API is stored in CAPIF Database</p> </li> <li> <p>Response to Remove published Service API at CCF:</p> <ol> <li>204 No Content</li> </ol> </li> <li> <p>Response to Retrieve for DELETED published API must accomplish:</p> <ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"No Service with specific credentials exists\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-12-delete-apis-published-by-authorised-apfid-with-invalid-serviceapiid","title":"Test Case 12: Delete APIs Published by Authorised apfId with invalid serviceApiId","text":"<p>Test ID: capif_api_publish_service-12</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Delete with invalid serviceApiId</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Remove published API at CCF with invalid serviceId</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Remove published Service API at CCF with invalid serviceId:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Remove published Service API at CCF:<ol> <li>404 Not Found</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Service API not found\".</li> <li>cause with message \"Service API id not found\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-13-delete-apis-published-by-non-authorised-apfid","title":"Test Case 13: Delete APIs Published by NON Authorised apfId","text":"<p>Test ID: capif_api_publish_service-13</p> <p>Description:</p> <p>This test case will check that an API Publisher cannot Delete API published when apfId is not authorised</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF and store certificates.</li> <li>Register Invoker and onboard Invoker at CCF</li> <li>Remove published API at CCF with invalid serviceId as Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Remove published Service API at CCF with invalid serviceId as Invoker:</p> <ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID_NOT_VALID}</li> <li>Use Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Remove published Service API at CCF:<ol> <li>401 Unauthorized</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"User not authorized\".</li> <li>cause with message \"Certificate not authorized\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_publish_service/#test-case-14-check-two-published-apis-with-different-apfs-are-removed-when-provider-is-deleted","title":"Test Case 14: Check Two Published APIs with different APFs are removed when Provider is deleted","text":"<p>Test ID: capif_api_publish_service-13</p> <p>Description:</p> <p>This test case will check that a Provider registered with two APFs, with one API published with each APF are removed properly when provider is removed. </p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider with 2 APFs at CCF and store certificates.</li> <li>Publish service_1 API with APF_1</li> <li>Publish service_2 API with APF_2</li> <li>Retrieve APIs published by APF_1</li> <li>Retrieve APIs published by APF_2</li> <li>Remove Provider by AMF</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish service_1 Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId1}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Get apiId</li> <li>Use APF_1 Certificate</li> </ul> </li> <li>Publish service_2 Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId2}/service-apis</li> <li>body service api description with apiName service_2</li> <li>Get apiId</li> <li>Use APF_2 Certificate</li> </ul> </li> <li>Retrieve all published APIs by APF_1:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId1}/service-apis</li> <li>Use APF_1 Certificate</li> </ul> </li> <li>Retrieve all published APIs by APF_2:<ul> <li>Send GET to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId2}/service-apis</li> <li>Use APF_2 Certificate</li> </ul> </li> <li>Get Number of services published by superadmin:<ol> <li>Store value obtained in services_present_on_ccf_after_publish</li> </ol> </li> <li>Delete registered provider:<ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}</li> <li>Use AMF Certificate.</li> </ul> </li> <li>Get Number of services published by superadmin:<ol> <li>Store value obtained in services_present_on_ccf_after_delete_provider</li> </ol> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId1}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId2}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Retrieve all published APIs by APF_1:<ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs by APF_1.</li> </ol> </li> <li>Response to Retrieve all published APIs by APF_2:<ol> <li>200 OK</li> <li>Response body must return an array of ServiceAPIDescription data.</li> <li>Array must contain all previously published APIs by APF_2.</li> </ol> </li> <li>Delete Provider:<ol> <li>204 No Content response.</li> </ol> </li> <li>Check two APIs where removed after remove provider:<ol> <li>services_present_on_ccf_after_publish - services_present_on_ccf_after_delete_provider = 2</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/","title":"Test Plan for CAPIF Api Security Service","text":"<p>At this documentation you will have all information and related files and examples of test plan for this API.</p>"},{"location":"testing/testplan/api_security_service/#test-case-1-create-a-security-context-for-an-api-invoker","title":"Test Case 1: Create a security context for an API invoker","text":"<p>Test ID: capif_security_api-1</p> <p>Description:</p> <p>This test case will check that an API Invoker can create a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body with aefId and apiId</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context:<ol> <li>201 Created response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> <li>Location Header must contain the new resource URL {apiRoot}/capif-security/v1/trustedInvokers/{apiInvokerId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-2-create-a-security-context-for-an-api-invoker-with-provider-role","title":"Test Case 2: Create a security context for an API invoker with Provider role","text":"<p>Test ID:: capif_security_api-2</p> <p>Description:</p> <p>This test case will check that an Provider cannot create a Security context with valid apiInvokerId.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with Provider role</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF.</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker but using Provider certificate.<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Create security context using Provider certificate:</p> <ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\".</li> </ul> </li> </ol> </li> <li> <p>No context stored at DB</p> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-3-create-a-security-context-for-an-api-invoker-with-provider-entity-role-and-invalid-apiinvokerid","title":"Test Case 3: Create a security context for an API invoker with Provider entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-3</p> <p>Description:</p> <p>This test case will check that an Provider cannot create a Security context with invalid apiInvokerID.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with Provider role</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this not valid apiInvokerId and using Provider certificate.<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context using Provider certificate:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\".</li> </ul> </li> </ol> </li> <li>No context stored at DB</li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-4-create-a-security-context-for-an-api-invoker-with-invoker-entity-role-and-invalid-apiinvokerid","title":"Test Case 4: Create a security context for an API invoker with Invoker entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-4</p> <p>Description:</p> <p>This test case will check that an Invoker cannot create a Security context with valid apiInvokerId.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID), but user that create Security Context with invalid apiInvokerId</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Create Security Context for this Invoker:<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>body service security body</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Create security context using Provider certificate:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> <li> <p>No context stored at DB</p> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-5-retrieve-the-security-context-of-an-api-invoker","title":"Test Case 5: Retrieve the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-5, smoke</p> <p>Description:</p> <p>This test case will check that an provider can retrieve the Security context of an API Invoker</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Retrieve Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker.</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-6-retrieve-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 6: Retrieve the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-6</p> <p>Description:</p> <p>This test case will check that an provider can retrieve the Security context of an API Invoker</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Retrieve Security Context by Provider of invalid invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of invalid Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-7-retrieve-the-security-context-of-an-api-invoker-with-invalid-apfid","title":"Test Case 7: Retrieve the Security Context of an API Invoker with invalid apfId","text":"<p>Test ID:: capif_security_api-7</p> <p>Description:</p> <p>This test case will check that an Provider cannot retrieve the Security context of an API Invoker without valid apfId</p> <p>Pre-Conditions:</p> <ul> <li>API Exposure Function is not pre-authorised (has invalid apfId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Store signed Certificate</li> <li>Create Security Context</li> <li>Retrieve Security Context as Provider.</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context as Invoker role:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Create security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-8-delete-the-security-context-of-an-api-invoker","title":"Test Case 8: Delete the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-8, smoke</p> <p>Description:</p> <p>This test case will check that an Provider can delete a Security context</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Delete Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker but using Provider certificate.</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> <li> <p>Delete Security Context of Invoker by Provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use AEF Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Delete security context:</p> <ol> <li>204 No Content response.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Security context not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-9-delete-the-security-context-of-an-api-invoker-with-invoker-entity-role","title":"Test Case 9: Delete the Security Context of an API Invoker with Invoker entity role","text":"<p>Test ID:: capif_security_api-9</p> <p>Description:</p> <p>This test case will check that an Invoker cannot delete a Security context</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority) and API Invoker has created a valid Security Context</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context using Provider certificate</li> <li>Delete Security Context by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Delete Security Context of Invoker:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-10-delete-the-security-context-of-an-api-invoker-with-invoker-entity-role-and-invalid-apiinvokerid","title":"Test Case 10: Delete the Security Context of an API Invoker with Invoker entity role and invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-10</p> <p>Description:</p> <p>This test case will check that an Invoker cannot delete a Security context with invalid </p> <p>Pre-Conditions:</p> <ul> <li>Invoker is pre-authorised.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Security Context by invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Invoker Onboarding</p> </li> <li> <p>Delete Security Context of Invoker:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Delete security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be aef\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-11-delete-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 11: Delete the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-11</p> <p>Description:</p> <p>This test case will check that an Provider cannot delete a Security context of invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>Provider is pre-authorised (has valid apfId from CAPIF Authority).</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF</li> <li>Delete Security Context by provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration</p> </li> <li> <p>Delete Security Context of Invoker by Provider:</p> <ul> <li>Send DELETE https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}</li> <li>Use AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-12-update-the-security-context-of-an-api-invoker","title":"Test Case 12: Update the Security Context of an API Invoker","text":"<p>Test ID:: capif_security_api-12, smoke</p> <p>Description:</p> <p>This test case will check that an API Invoker can update a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context By Invoker</li> <li>Update Security Context By Invoker</li> <li>Retrieve Security Context By Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Update Security Context of Invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/update</li> <li>body service security body but with notification destination modified to http://robot.testing2</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Update security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this returned object match with modified one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-13-update-the-security-context-of-an-api-invoker-with-provider-entity-role","title":"Test Case 13: Update the Security Context of an API Invoker with Provider entity role","text":"<p>Test ID:: capif_security_api-13</p> <p>Description:</p> <p>This test case will check that an Provider cannot update a Security context</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized.</li> <li>Invoker has created the Security Context previously.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Update Security Context as Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Update Security Context of Invoker by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/update</li> <li>body service security body but with notification destination modified to http://robot.testing2</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\". </li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-14-update-the-security-context-of-an-api-invoker-with-aef-entity-role-and-invalid-apiinvokerid","title":"Test Case 14: Update the Security Context of an API Invoker with AEF entity role and invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-14</p> <p>Description:</p> <p>This test case will check that an Provider cannot update a Security context of invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized.</li> <li>Invoker has created the Security Context previously.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Update Security Context as Provider</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update Security Context of Invoker by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update</li> <li>body service security body</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Update security context:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be invoker\". </li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-15-update-the-security-context-of-an-api-invoker-with-invalid-apiinvokerid","title":"Test Case 15: Update the Security Context of an API Invoker with invalid apiInvokerID","text":"<p>Test ID:: capif_security_api-15</p> <p>Description:</p> <p>This test case will check that an API Invoker cannot update a Security context not valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Update Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Update Security Context of Invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Retrieve security context:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-16-revoke-the-authorization-of-the-api-invoker-for-apis","title":"Test Case 16: Revoke the authorization of the API invoker for APIs.","text":"<p>Test ID:: capif_security_api-16</p> <p>Description:</p> <p>This test case will check that a Provider can revoke the authorization for APIs</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context by Invoker</li> <li>Revoke Security Context by Provider</li> <li>Retrieve Security Context by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context By Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Revoke Authorization by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Authorization:</p> <ol> <li>204 No Content response.</li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Security context not found\".</li> <li>cause with message \"API Invoker has no security context\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-17-revoke-the-authorization-of-the-api-invoker-for-apis-without-valid-apfid","title":"Test Case 17: Revoke the authorization of the API invoker for APIs without valid apfID.","text":"<p>Test ID:: capif_security_api-17</p> <p>Description:</p> <p>This test case will check that an Invoker can't revoke the authorization for APIs</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Revoke Security Context by invoker</li> <li>Retrieve Security Context</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Revoke Authorization by invoker:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete</li> <li>body security notification body</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>Using Provider Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Security Context by invoker:</p> <ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 401</li> <li>title with message \"Unauthorized\"</li> <li>detail with message \"Role not authorized for this API route\".</li> <li>cause with message \"User role must be provider\". </li> </ul> </li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this returned object match with created one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-18-revoke-the-authorization-of-the-api-invoker-for-apis-with-invalid-apiinvokerid","title":"Test Case 18: Revoke the authorization of the API invoker for APIs with invalid apiInvokerId.","text":"<p>Test ID:: capif_security_api-18</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot revoke the authorization for APIs for invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker at CCF</li> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF.</li> <li>Create Security Context</li> <li>Revoke Security Context by Provider</li> <li>Retrieve Security Context</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker:</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> </ul> </li> <li> <p>Revoke Authorization by Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/delete</li> <li>body security notification body</li> <li>Using AEF Certificate.</li> </ul> </li> <li> <p>Retrieve Security Context of Invoker by Provider:</p> <ul> <li>Send GET https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}?authenticationInfo=true&authorizationInfo=true</li> <li>This request will ask with parameter to retrieve authenticationInfo and authorizationInfo</li> <li>Using AEF Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Revoke Security Context by invoker:</p> <ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"Invoker not found\".</li> <li>cause with message \"API Invoker not exists or invalid ID\".</li> </ul> </li> </ol> </li> <li> <p>Retrieve security context:</p> <ol> <li>200 OK response.</li> <li>body returned must accomplish ServiceSecurity data structure.<ol> <li>Check is this return one object that match with created one.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-19-retrieve-access-token","title":"Test Case 19: Retrieve access token","text":"<p>Test ID:: capif_security_api-19, smoke</p> <p>Description:</p> <p>This test case will check that an API Invoker can retrieve a security access token OAuth 2.0.</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerId)</li> <li>Service API of Provider is published</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token:</li> <li>body access token req body and example example</li> <li>securityId is apiInvokerId.</li> <li>grant_type=client_credentials.</li> <li>Create Scope properly for request: 3gpp#{aef_id}:{api_name}</li> <li>Using Invoker Certificate.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>200 OK</li> <li>body must follow AccessTokenRsp with:<ol> <li>access_token present</li> <li>token_type=Bearer</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-20-retrieve-access-token-by-provider","title":"Test Case 20: Retrieve access token by Provider","text":"<p>Test ID:: capif_security_api-20</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot revoke the authorization for APIs for invalid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerID from CAPIF Authority) and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by provider:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token:</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error unauthorized_client</li> <li>error_description=Role not authorized for this API route</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-21-retrieve-access-token-by-provider-with-invalid-apiinvokerid","title":"Test Case 21: Retrieve access token by Provider with invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-21</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token without valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Provider</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by provider:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{API_INVOKER_NOT_VALID}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using AEF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>401 Unauthorized response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error unauthorized_client</li> <li>error_description=Role not authorized for this API route</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-22-retrieve-access-token-with-invalid-apiinvokerid","title":"Test Case 22: Retrieve access token with invalid apiInvokerId","text":"<p>Test ID:: capif_security_api-22</p> <p>Description:</p> <p>This test case will check that an API Invoker can't retrieve a security access token without valid apiInvokerId</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised (has valid apiInvokerId)</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs not filtered:<ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li>Create Security Context for this Invoker<ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li>Request Access Token by invoker:<ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{API_INVOKER_NOT_VALID}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>404 Not Found response.</li> <li>body returned must accomplish ProblemDetails29571 data structure, with:<ul> <li>status 404</li> <li>title Not Found</li> <li>detail Security context not found</li> <li>cause API Invoker has no security context</li> </ul> </li> </ol> </li> </ol> <p>NOTE: ProblemDetails29571 is the definition present for this request at swagger of ProblemDetails, and this is different from definition of ProblemDetails across other CAPIF Services</p>"},{"location":"testing/testplan/api_security_service/#test-case-23-retrieve-access-token-with-invalid-client_id","title":"Test Case 23: Retrieve access token with invalid client_id","text":"<p>Test ID:: capif_security_api-23</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token without valid client_id at body</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>client_id is not-valid </li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_client</li> <li>error_description=Client Id not found</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-24-retrieve-access-token-with-unsupported-grant_type","title":"Test Case 24: Retrieve access token with unsupported grant_type","text":"<p>Test ID:: capif_security_api-24</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with unsupported grant_type</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=not_valid</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish ProblemDetails data structure, with:<ul> <li>title=Bad Request</li> <li>detail='not_valid' is not one of \\['client_credentials', 'authorization_code'\\] - 'grant_type'</li> <li>status=400</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-25-retrieve-access-token-with-invalid-scope","title":"Test Case 25: Retrieve access token with invalid scope","text":"<p>Test ID:: capif_security_api-25</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with complete invalid scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=not-valid-scope</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=The first characters must be '3gpp'</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-26-retrieve-access-token-with-invalid-aefid-at-scope","title":"Test Case 26: Retrieve access token with invalid aefid at scope","text":"<p>Test ID:: capif_security_api-26</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with invalid aefId at scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=3gpp#1234:*service_1*</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=One of aef_id not belongs of your security context</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_security_service/#test-case-27-retrieve-access-token-with-invalid-apiname-at-scope","title":"Test Case 27: Retrieve access token with invalid apiName at scope","text":"<p>Test ID:: capif_security_api-27</p> <p>Description:</p> <p>This test case will check that an API Exposure Function cannot retrieve a security access token with invalid apiName at scope</p> <p>Pre-Conditions:</p> <ul> <li>API Invoker is pre-authorised and Provider is also authorized</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates and Publish Service API service_1 at CCF</li> <li>Register and onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker.</li> <li>Create Security Context According to Service APIs discovered.</li> <li>Request Access Token by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li> <p>Perform Provider Registration and Invoker Onboarding</p> </li> <li> <p>Publish Service API at CCF:</p> <ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>Use APF Certificate</li> </ul> </li> <li> <p>Request Discover Published APIs not filtered:</p> <ul> <li>Send GET to ccf_discover_url https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}</li> <li>Param api-invoker-id is mandatory</li> <li>Using Invoker Certificate</li> </ul> </li> <li> <p>Create Security Context for this Invoker</p> <ul> <li>Send PUT https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}</li> <li>body service security body</li> <li>Using Invoker Certificate.</li> <li>Create Security Information Body with one securityInfo for each aef present at each serviceAPIDescription present at Discover.</li> </ul> </li> <li> <p>Request Access Token by invoker:</p> <ul> <li>Sent POST https://{CAPIF_HOSTNAME}/securities/{securityId}/token.</li> <li>body access token req body</li> <li>securityId is apiInvokerId</li> <li>grant_type=client_credentials</li> <li>scope=3gpp#{aef_id}:not-valid</li> <li>Using Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Request of Access Token:<ol> <li>400 Bad Request response.</li> <li>body returned must accomplish AccessTokenErr data structure, with:<ul> <li>error invalid_scope</li> <li>error_description=One of the api names does not exist or is not associated with the aef id provided</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/","title":"Test Plan for API Status Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/api_status/#test-case-1-publish-without-apistatus-feature-receive-eventdetails-with-serviceapidescription","title":"Test Case 1: Publish without apiStatus feature receive eventDetails with serviceAPIDescription","text":"<p>Test ID: api_status-1</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing apiIds and serviceAPIDescription at eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report and apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-2-publish-without-apistatus-feature-receive-eventdetails-without-serviceapidescription","title":"Test Case 2: Publish without apiStatus feature receive eventDetails without serviceAPIDescription","text":"<p>Test ID: api_status-2</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with only Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing apiIds at eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report active at supported features (binary 0100-> string 4)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-3-publish-without-apistatus-feature-receive-eventdetails-without-eventdetails-apimonitoringstatus-active","title":"Test Case 3: Publish without apiStatus feature receive eventDetails without eventDetails (apiMonitoringStatus active)","text":"<p>Test ID: api_status-3</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with only apiStatusMonitoring active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, not containing eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1000-> string 8)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1000 -> string 8</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-4-publish-without-apistatus-feature-receive-eventdetails-without-eventdetails","title":"Test Case 4: Publish without apiStatus feature receive eventDetails without eventDetails","text":"<p>Test ID: api_status-4</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report not active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, not containing eventDetails, and the same when api is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 0000-> string 0)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains the apiStatus keys</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-5-publish-with-apistatus-present-but-apistatusmonitoring-inactive-receive-bad-request","title":"Test Case 5: Publish with apiStatus present but apiStatusMonitoring inactive receive bad Request","text":"<p>Test ID: api_status-5</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report not active, receive Bad Request when api is published by a provider.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring and Enhanced_event_report inactive at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag inactive (binary 0 0000 0000 -> string 000)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>No Events have been received.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-6-publish-with-apistatus-feature-active-receive-eventdetails-with-serviceapidescription","title":"Test Case 6: Publish with apiStatus feature active receive eventDetails with serviceAPIDescription","text":"<p>Test ID: api_status-6</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification including apiIds and serviceAPIDescriptions.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-7-publish-with-apistatus-active-feature-receive-eventdetails-without-serviceapidescription","title":"Test Case 7: Publish with apiStatus active feature receive eventDetails without serviceAPIDescription","text":"<p>Test ID: api_status-7</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring inactive and Enhanced_event_report active, receive event notification including only apiIds.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report active and apiStatusMonitoring inactive at supported features (binary 0100-> string 4)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0100 -> string 4</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with only apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-8-publish-with-apistatus-active-feature-receive-eventdetails-without-eventdetails-with-apistatus-apimonitoringstatus-active","title":"Test Case 8: Publish with apiStatus active feature receive eventDetails without eventDetails with apiStatus (apiMonitoringStatus active)","text":"<p>Test ID: api_status-8</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring active and Enhanced_event_report inactive, receive event notification without eventDetails.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report inactive and apiStatusMonitoring active at supported features (binary 1000-> string 8)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1000 -> string 8</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-9-publish-with-apistatus-active-feature-receive-eventdetails-without-eventdetails","title":"Test Case 9: Publish with apiStatus active feature receive eventDetails without eventDetails","text":"<p>Test ID: api_status-9</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report inactive, receive event notification without eventDetails.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. Enhanced_event_report and apiStatusMonitoring inactive at supported features (binary 0000-> string 0)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with aefId1 inside array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 0000 -> string 0</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, without eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>The other one must be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-10-publish-with-apistatus-feature-active-no-aefid-active-receive-eventdetails-with-serviceapidescription-with-apistatus-empty-array","title":"Test Case 10: Publish with apiStatus feature active no aefId active receive eventDetails with serviceAPIDescription with apiStatus empty array","text":"<p>Test ID: api_status-10</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification SERVICE_API_UNAVAILABLE including apiIds and serviceAPIDescriptions when API is published containing apiStatus with empty array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty aefIds array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with empty aefIds array. </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>One Event has been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>Only one SERVICE_API_UNAVAILABLE event.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-11-publish-with-apistatus-not-present-but-apistatusmonitoring-feature-active-receive-eventdetails-with-serviceapidescription-without-apistatus","title":"Test Case 11: Publish with apiStatus not present but apiStatusMonitoring feature active receive eventDetails with serviceAPIDescription without apiStatus","text":"<p>Test ID: api_status-11</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE, with apiStatusMonitoring and Enhanced_event_report active, receive event notification SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE including apiIds and serviceAPIDescriptions when API is published wihtout apiStatus.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE. apiStatusMonitoring active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API not includes \"API Status\" information at service API Description.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus not present. </li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus key.</li> </ul> </li> </ol> </li> <li>Response to Remove published Service API at CCF:<ol> <li>204 No Content</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>First SERVICE_API_AVAILABLE event.</li> <li>Other with SERVICE_API_UNAVAILABLE event.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-12-update-published-api-without-apistatus-and-apistatusmonitoring-inactive","title":"Test Case 12: Update published API without apiStatus and apiStatusMonitoring inactive","text":"<p>Test ID: api_status-12</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, and SERVICE_API_UPDATE after update apiStatus to not present.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus Not present</li> <li>aipStatusMonitoring feature not active (binary 0 0000 0000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus not present.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetail with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetail containing serviceAPIDescription updated.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-13-update-published-api-with-apistatus-empty-and-apistatusmonitoring-inactive","title":"Test Case 13: Update published API with apiStatus empty and apiStatusMonitoring inactive","text":"<p>Test ID: api_status-13</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, and SERVICE_API_UPDATE after update apiStatus to empty aefIds array with ApiStatusMonitoring inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature not active (binary 0 0000 0000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 0</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with empty aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li> <p>Response to Update request must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li> <p>Mock Server received messages must accomplish:</p> <ol> <li>One Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-14-update-published-api-with-apistatus-empty-and-apistatusmonitoring-active","title":"Test Case 14: Update published API with apiStatus empty and apiStatusMonitoring active","text":"<p>Test ID: api_status-14</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails, SERVICE_API_UPDATE and SERVICE_API_UNAVAILABLE after update apiStatus to empty aefIds array with ApiStatusMonitoring active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with empty aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>One should be SERVICE_API_UPDATE.</li> <li>One should be SERVICE_API_UNAVAILABLE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-15-update-published-api-with-apistatus-only-aef2-and-apistatusmonitoring-active","title":"Test Case 15: Update published API with apiStatus only aef2 and apiStatusMonitoring active","text":"<p>Test ID: api_status-15</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider, containing eventDetails and SERVICE_API_UPDATE after update apiStatus to aefId2 array with ApiStatusMonitoring active.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with empty aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with aefId2 in aefIds array.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE.</li> <li>One should be SERVICE_API_UPDATE.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-16-published-api-without-aefs-available-updated-to-one-aef-available","title":"Test Case 16: Published API without aefs available updated to one aef available","text":"<p>Test ID: api_status-16</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_UNAVAILABLE in mockserver when api is published with apiStatus empty by a provider containing eventDetails, SERVICE_API_UPDATE and SERVICE_API_AVAILABLE after update apiStatus to aefId2 array with ApiStatusMonitoring active, and SERVICE_API_UNAVAILABLE when API is unpublished.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty aefIds array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Update Published API:<ol> <li>apiStatus present with aefId2 in aefIds array.</li> <li>apiStatusMonitoring feature active (binary 0 0010 0000 -> string 20)</li> </ol> </li> <li>Provider remove published API.</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with empty aefIds array.</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PUT to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 20</li> <li>2 profiles, one with each aef.</li> <li>apiStatus present with aefId2 in aefIds array.</li> </ul> </li> <li>Remove published Service API:<ul> <li>Send DELETE to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Update published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Event have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds and serviceAPIDescription in eventDetail parameter.<ol> <li>One should be SERVICE_API_UNAVAILABLE aefIds array inside apiStatus empty.</li> <li>One should be SERVICE_API_UPDATE aefIds array inside apiStatus contains apfId2.</li> <li>One should be SERVICE_API_AVAILABLE aefIds array inside apiStatus contains apfId2.</li> <li>One should be SERVICE_API_UNAVAILABLE aefIds array inside apiStatus contains apfId2.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-17-patch-published-apistatusmonitoring-active-api-with-apistatus-only-aefid2","title":"Test Case 17: Patch published (apiStatusMonitoring active) API with apiStatus only aefId2","text":"<p>Test ID: api_status-17</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE after patch with apfId2 in apiStatus array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-18-patch-published-apistatusmonitoring-active-api-with-apistatus-aef1-and-aef2","title":"Test Case 18: Patch published (apiStatusMonitoring active) API with apiStatus aef1 and aef2","text":"<p>Test ID: api_status-18</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE after patch with apfId1 and apfId2 in apiStatus array.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId1 and aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-19-patch-published-apistatusmonitoring-inactive-api-with-apistatus-aefid1-and-aefid2","title":"Test Case 19: Patch published (apiStatusMonitoring inactive) API with apiStatus aefId1 and aefId2","text":"<p>Test ID: api_status-19</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_AVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring inactive), containing eventDetails, and NO SERVICE_API_UPDATE after patch with apfId1 and apfId2 in apiStatus array, because apiStatusMonitoring in publish is inactive.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0000 0000 -> string 000)</li> <li>This API includes \"API Status\" information at service API Description with only aefId1.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 000</li> <li>2 profiles, one with each aef.</li> <li>apiStatus with aefId1 inside array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Event Subscription must accomplish:</p> <ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"Set apiStatus with apiStatusMonitoring feature inactive at supportedFeatures if not allowed\".</li> <li>cause with message \"apiStatus can't be set if apiStatusMonitoring is inactive\".</li> </ul> </li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>No Events have been received.</li> </ol> </li> </ol>"},{"location":"testing/testplan/api_status/#test-case-20-patch-published-without-aefs-available-api-with-apistatus-only-aef2","title":"Test Case 20: Patch published without aefs available API with apiStatus only aef2","text":"<p>Test ID: api_status-20</p> <p>Description:</p> <p>This test case will check if an invoker subscribed to events SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE with apiStatusMonitoring and Enhanced_event_report active, receive SERVICE_API_UNAVAILABLE in mockserver when api is published by a provider (with apiStatusMonitoring active), containing eventDetails, and SERVICE_API_UPDATE and SERVICE_API_AVAILABLE after patch with apfId1 and apfId2 in apiStatus array, becasue change from unavailable to available and also serviceAPIDescription is updated.</p> <p>Pre-Conditions:</p> <ul> <li>CAPIF subscriber is pre-authorised (has valid InvokerId or apfId from CAPIF Authority)</li> <li>CAPIF provider is correctly registered with 2 aefs.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Invoker and Onboard Invoker at CCF.</li> <li>Register Provider at CCF with 2 aefs.</li> <li>Subscribe to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE. apiStatusMonitoring and Enhanced_event_report active at supported features (binary 1100-> string C)</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with apiStatusMonitoring flag active (binary 0 0010 0000 -> string 020)</li> <li>This API includes \"API Status\" information at service API Description with empty array.</li> </ol> </li> <li>Discover Service APIs by Invoker<ol> <li>includes filter by query parameter aef-id</li> </ol> </li> <li>Patch Published API:<ol> <li>apiStatus present with aefId1 and aefId2 in array.</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Invoker Onboarding</li> <li>Perform Provider Registration with 2 aefs</li> <li>Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body with:<ol> <li>events: ['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE','SERVICE_API_UPDATE']</li> <li>supportedFeatures: binary 1100 -> string C</li> </ol> </li> <li>Use Invoker Certificate</li> </ol> </li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with service_1 and service_2 apiNames and realted with aefId1 and aefId2.</li> <li>supportedFeatures 020</li> <li>2 profiles, one with each aef.</li> <li>apiStatus empty array</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> <li>Update published Service API:<ul> <li>Send PATCH to resource URL https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis/{SERVICE_API_ID}</li> <li>Use APF Certificate</li> <li>body service api description patch and realted with aefId1 and aefId2.</li> <li>apiStatus present with aefId1 and aefId2.</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Onboard request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> <li>Response to Publish request must accomplish:<ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> <li>2 profiles with:</li> <li>resourceName resource_1 and aefId1</li> <li>resourceName resource_2 and aefId2</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the apiStatus with aefId1</li> </ul> </li> </ol> </li> <li>Response to Patch published Service API at CCF:<ol> <li>200 OK</li> <li>Store response with updated serviceAPIDescription.</li> </ol> </li> <li>Mock Server received messages must accomplish:<ol> <li>Two Events have been received.</li> <li>Validate received events follow EventNotification data structure, with apiIds in eventDetail parameter.<ol> <li>One should be SERVICE_API_UNAVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> <li>The other one must be SERVICE_API_UPDATE apiId published API with eventDetails containing serviceAPIDescription patched.</li> <li>Last one should be SERVICE_API_AVAILABLE apiId of published API with eventDetails with apiIds and serviceAPIDescription.</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/","title":"Common Operations","text":""},{"location":"testing/testplan/common_operations/#default-supported-features","title":"Default Supported Features","text":"<p>By default all required supported features on POST Request will be present and set to \"0\" unless test define it with other value. Also it can be set to NONE is we want to test supported features not present.</p>"},{"location":"testing/testplan/common_operations/#register-new-user","title":"Register new user","text":"<p>In order to use OpenCAPIF we must add a new user. This new user can onboard/register any Invokers or Providers.</p> <p>That new user must be created by administrator of Register Service and with the credentials shared by administrator, the new user can get the access_token by requesting it to Register service.</p> <p>The steps to register a new user at Register Service are:</p>"},{"location":"testing/testplan/common_operations/#admin-create-user","title":"Admin create User","text":"<p>1) Login as Admin to get access_token:</p> <ul> <li>Send POST to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/login<ul> <li>Include basic Auth Header with Admin credentials</li> </ul> </li> <li>Get access_token and refresh_token from response</li> </ul> <p></p> <p>2) Create User:</p> <ul> <li>Send POST to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/createUser<ul> <li>Include Admin access_token in Authorization Bearer Header</li> <li>Body user_registration_body</li> </ul> </li> </ul> <p></p>"},{"location":"testing/testplan/common_operations/#user-retrieve-access-token-and-other-information","title":"User Retrieve access token and other information","text":"<p>1) Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth<ul> <li>Include basic Auth Header with User credentials</li> </ul> </li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> <p></p>"},{"location":"testing/testplan/common_operations/#onboard-an-invoker","title":"Onboard an Invoker","text":""},{"location":"testing/testplan/common_operations/#steps-to-perform-operation","title":"Steps to perform operation","text":"<p>Preconditions: The administrator must have previously registered the User.</p> <ol> <li>Create public and private key at invoker</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Onboard Invoker: </p> <ul> <li>Send POST to https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers</li> <li>Reference Request Body: invoker onboarding body</li> <li>\"onboardingInformation\"->\"apiInvokerPublicKey\": must contain public key generated by Invoker.</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> </ul> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-onboarding","title":"Checks to ensure onboarding","text":"<ol> <li> <p>Response to Get Auth:</p> <ol> <li>200 OK</li> <li>access_token returned.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#example-flow","title":"Example Flow","text":""},{"location":"testing/testplan/common_operations/#register-a-provider","title":"Register a Provider","text":""},{"location":"testing/testplan/common_operations/#steps-to-perform-operation_1","title":"Steps to Perform operation","text":"<ol> <li>Create public and private key at provider for provider itself and each function (apf, aef and amf)</li> <li> <p>Retrieve access_token by User:</p> <ul> <li>Send GET to https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth</li> <li>Include basic Auth Header with Admin user/password</li> <li>Retrieve access_token and the urls needed for next requests from response body user_getauth_response_body_example</li> </ul> </li> <li> <p>Register Provider:</p> <ul> <li>Send POST https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations</li> <li>body provider request body</li> <li>Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})</li> <li>Store each cert in a file with according name.</li> </ul> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-provider-registration","title":"Checks to ensure provider registration","text":"<ol> <li> <p>Response to Register:</p> <ol> <li>201 Created</li> </ol> </li> <li> <p>Response to Get Auth:</p> <ol> <li>200 OK</li> <li>access_token returned.</li> </ol> </li> <li> <p>Register Provider at Provider Management:</p> <ol> <li>201 Created response.</li> <li>body returned must accomplish APIProviderEnrolmentDetails data structure.</li> <li>For each apiProvFuncs, we must check:<ol> <li>apiProvFuncId is set</li> <li>apiProvCert under regInfo is set properly</li> </ol> </li> <li>Location Header must contain the new resource URL {apiRoot}/api-provider-management/v1/registrations/{registrationId}</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#example-flow_1","title":"Example Flow","text":""},{"location":"testing/testplan/common_operations/#subscribe-to-events","title":"Subscribe to Events","text":"<p>Subscription to an Event by any entity (Invoker, Provider or other CCF), will ensure when subscription is matched one event will be sent to notification destination present on subscription creation.</p>"},{"location":"testing/testplan/common_operations/#how-to-create-a-subscription","title":"How to create a subscription","text":"<p>In order to create a subcription, customer must setup some different parameters.</p>"},{"location":"testing/testplan/common_operations/#basic-subscription","title":"Basic Subscription","text":"<p>Basic subcription will be used when Enhanced_event_report feature is not active at supportedFeatures attribute at event subscription request body, this means this kind of subcription:</p> <ul> <li>Won't be filtered by eventFilters.</li> <li>Reporting specific requierements won't be enable (eventReq).</li> <li>Response will only contains basic information without eventDetail.</li> </ul> <p>With this in mind, customer must select next parameters:</p>"},{"location":"testing/testplan/common_operations/#events-to-subscribe","title":"Events to subscribe","text":"<p>Select event or events to subscribe. Check from next list:</p> Event Description Status SERVICE_API_AVAILABLE Events related to the availability of service APIs after the service APIs are published. Implemented SERVICE_API_UNAVAILABLE Events related to the unavailability of service APIs after the service APIs are unpublished. Implemented SERVICE_API_UPDATE Events related to change in service API information. Implemented API_INVOKER_ONBOARDED Events related to API invoker onboarded to CAPIF. Implemented API_INVOKER_OFFBOARDED Events related to API invoker offboarded from CAPIF. Implemented SERVICE_API_INVOCATION_SUCCESS Events related to the successful invocation of service APIs. Implemented SERVICE_API_INVOCATION_FAILURE Events related to the failed invocation of service APIs. Implemented ACCESS_CONTROL_POLICY_UPDATE Events related to the update for the access control policy related to the service APIs. Implemented ACCESS_CONTROL_POLICY_UNAVAILABLE Events related to the unavailability of the access control policy related to the service APIs (NOTE). Implemented API_INVOKER_AUTHORIZATION_REVOKED Events related to the revocation of the authorization of API invokers to access the service APIs. (NOTE). Implemented API_INVOKER_UPDATED Events related to API invoker profile updated to CAPIF. Implemented API_TOPOLOGY_HIDING_CREATED Events related to the creation or update of the API topology hiding information of the service API after the service APIs are published. Not Implemented API_TOPOLOGY_HIDING_REVOKED Events related to the revocation of the API topology information of the service API after the service APIs are unpublished. Not Implemented <p>NOTE: 3GPP Common API Framework release 19 specs not specify further details (e.g event filters) for this event.</p>"},{"location":"testing/testplan/common_operations/#notification-destination","title":"Notification Destination","text":"<ul> <li>Set notification destination at event subscription request body with the endpoint to be reached by CCF when an event matches.</li> </ul>"},{"location":"testing/testplan/common_operations/#enhanced-subscription","title":"Enhanced Subscription","text":"<p>Enhanced will be the requiered subscription if customer needs one or more next functionality:</p> <ul> <li>Filter events. (eventFilters)</li> <li>Setup some reporting requirements. (eventReq)</li> <li>Get more detailed information when event notification is received (eventDetail on response)</li> </ul> <p>If that is the case, then event subscription request body must setup supported features with Enhanced_event_report feature active (feature 3)</p> <p>With this feature active, customer can send eventFilter and EventReq with required information.</p>"},{"location":"testing/testplan/common_operations/#event-filter","title":"Event Filter","text":"<p>We can include an array for each suscribed array with desired eventFilter to be applied, but we need to keep in mind not all events allows all filters, take a look to next table:</p> Event Event filter allowed SERVICE_API_AVAILABLE apiIds SERVICE_API_UNAVAILABLE apiIds SERVICE_API_UPDATE apiIds API_INVOKER_ONBOARDED apiInvokerIds API_INVOKER_OFFBOARDED apiInvokerIds SERVICE_API_INVOCATION_SUCCESS apiIds, apiInvokerIds, aefIds. SERVICE_API_INVOCATION_FAILURE apiIds, apiInvokerIds, aefIds. ACCESS_CONTROL_POLICY_UPDATE apiIds, apiInvokerIds. ACCESS_CONTROL_POLICY_UNAVAILABLE - API_INVOKER_AUTHORIZATION_REVOKED - API_INVOKER_UPDATED apiInvokerIds API_TOPOLOGY_HIDING_CREATED - API_TOPOLOGY_HIDING_REVOKED -"},{"location":"testing/testplan/common_operations/#event-req","title":"Event Req","text":"<p>Currently not implemented</p>"},{"location":"testing/testplan/common_operations/#steps-to-perform-operation_2","title":"Steps to Perform operation","text":"<ol> <li>Perform invoker onboarding or provider registration</li> <li>Event Subscription:<ol> <li>Send POST to https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions</li> <li>body event subscription request body</li> <li>Use Invoker Certificate or AMF Provider Certificate</li> </ol> </li> </ol>"},{"location":"testing/testplan/common_operations/#checks-to-ensure-provider-registration_1","title":"Checks to ensure provider registration","text":"<ol> <li>Response to Event Subscription must accomplish:<ol> <li>201 Created</li> <li>The URI of the created resource shall be returned in the \"Location\" HTTP header, following this structure: {apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}</li> <li>Response Body must follow EventSubscription data structure.</li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/","title":"Test Plan for Event Filter Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/event_filter/#test-case-1-invoker-subscribed-to-service_api_available-service_api_unavailable-and-service_api_update-events-filtered-by-apiids","title":"Test Case 1: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by apiIds","text":"<p>Test ID: event_filter-1 Additional Tags: mockserver</p> <p>Description:</p> <p>This test case will check an invoker can subscribe to SERVICE_API events and filter them by apiId.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> <li>Two providers registered and with APIs published.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Register Provider 1 and publish service_1 api:<ol> <li>Setup provider with Two AEFs.</li> <li>Publish service_1 with:<ol> <li>Two AEFs. (aef_id_1 and aef_id_2)</li> <li>apiStatus empty list.</li> <li>supportedFeatures 020.</li> </ol> </li> </ol> </li> <li>Register Provider 2 and publish service_2 api:<ol> <li>Publish service_2 with:<ol> <li>apiStatus with AEF Id (aef2_id_1)</li> <li>supportedFeatures 020</li> </ol> </li> </ol> </li> <li>Discover APIs by Invoker:<ol> <li>filter by aef_id_1</li> <li>Only one api will be obtained, store apiId at api_id.</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [apiId], [apiId], [apiId].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Update service_1 api:<ol> <li>apiStatus with aefIds present on Provider 1.</li> <li>SupportedFeatures set to 20</li> </ol> </li> <li>Remove Provider 1</li> <li>Remove Provider 2</li> </ol> <p>Expected Results:</p> <p>Mock Server received messages must accomplish:</p> <ol> <li>Three Events have been received.</li> <li>Validate received events follow EventNotification data structure, with:<ol> <li>SERVICE_API_AVAILABLE:<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> <li>SERVICE_API_UPDATE:<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> <li>SERVICE_API_UNAVAILABLE<ol> <li>EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-2-invoker-subscribed-to-service_api_available-service_api_unavailable-and-service_api_update-events-filtered-by-not-valid-filters","title":"Test Case 2: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by not valid filters","text":"<p>Test ID: event_filter-2 Additional Tags: smoke</p> <p>Description:</p> <p>This test case will check all error response related with wrong filtering options when invoker subscribes to SERVICE_API events.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> <li>Two providers registered and with APIs published.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Register Provider 1 and publish service_1 api:<ol> <li>Setup provider with Two AEFs.</li> <li>Publish service_1 with:<ol> <li>Two AEFs. (aef_id_1 and aef_id_2)</li> <li>apiStatus empty list.</li> <li>supportedFeatures 020.</li> </ol> </li> </ol> </li> <li>Register Provider 2 and publish service_2 api:<ol> <li>Publish service_2 with:<ol> <li>apiStatus with AEF Id (aef2_id_1)</li> <li>supportedFeatures 020</li> </ol> </li> </ol> </li> <li>Discover APIs by Invoker:<ol> <li>filter by aef_id_1</li> <li>Only one api will be obtained, store apiId at api_id.</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [aefIds], [empty], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [aefIds], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [empty], [aefIds].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.</li> <li>EventFilter: [empty], [empty], [apiInvokerIds].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <p>We will receive one error after each Event subscription:</p> <ol> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_AVAILABLE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_AVAILABLE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UNAVAILABLE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UNAVAILABLE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event SERVICE_API_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter api_invoker_ids for event SERVICE_API_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-3-provider-subscribed-to-api_invoker_onboarded-api_invoker_offboarded-and-api_invoker_updated-events-filtered-by-invokerids","title":"Test Case 3: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by invokerIds","text":"<p>Test ID: event_filter-3 Additional Tags: mockserver</p> <p>Description:</p> <p>This test case will check subcription to all API_INVOKER events by one provider.</p> <p>Pre-Conditions:</p> <ul> <li>Provider is previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Subscribe to events:<ol> <li>Events: API_INVOKER_ONBOARDED</li> <li>EventFilter: No filter.</li> <li>supportedFeatures: C</li> </ol> </li> <li>Register and onboard Invoker 1</li> <li>Register and onboard Invoker 2</li> <li>Subscribe provider to events:<ol> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [apiInvokerId1], [apiInvokerId2].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Update Invoker 1:<ol> <li>Setup new notificationDestination at invoker.</li> </ol> </li> <li>Update Invoker 2:<ol> <li>Setup new notificationDestination at invoker.</li> </ol> </li> <li>Remove Invoker 1.</li> <li>Remove Invoker 2.</li> </ol> <p>Expected Results:</p> <p>Mock Server received messages must accomplish:</p> <ol> <li>Four Events have been received.</li> <li>Validate received events follow EventNotification data structure, with:<ol> <li>API_INVOKER_ONBOARDED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 1</li> </ol> </li> <li>API_INVOKER_ONBOARDED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 2</li> </ol> </li> <li>API_INVOKER_UPDATED:<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 2</li> </ol> </li> <li>API_INVOKER_OFFBOARDED<ol> <li>EventDetail include apiInvokerIds with apiInvokerId of provider 1</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-4-provider-subscribed-to-api_invoker_onboarded-api_invoker_offboarded-and-api_invoker_updated-events-filtered-by-not-valid-filters","title":"Test Case 4: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by not valid filters","text":"<p>Test ID: event_filter-4 Additional Tags: </p> <p>Description:</p> <p>This test will check API_INVOKER events subscription by Provider with not valid filters.</p> <p>Pre-Conditions:</p> <ul> <li>Provider is previously registered.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Register and onboard Invoker 1</li> <li>Register and onboard Invoker 2</li> <li>Subscribe provider to events:<ol> <li>Subscription 1</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [aefIds], [empty], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 2</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [aefIds], [empty].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 3</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [empty], [aefIds].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider to events:<ol> <li>Subscription 4</li> <li>Events: API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED</li> <li>EventFilter: [empty], [empty], [apiIds].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to first subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_ONBOARDED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_ONBOARDED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to second subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_OFFBOARDED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_OFFBOARDED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to third subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_UPDATED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_UPDATED are not applicable }]</li> </ol> </li> </ol> </li> <li>Response to fourth subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event API_INVOKER_UPDATED</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter api_ids for event API_INVOKER_UPDATED are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-5-provider-subscribed-to-access_control_policy_update-event-filtered-by-only-apiid-only-invokerid-and-both","title":"Test Case 5: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by only apiId, only invokerId and both","text":"<p>Test ID: event_filter-5 Additional Tags: smoke, mockserver</p> <p>Description:</p> <p>This test case will check subcription to ACCESS_CONTROL_POLICY_UPDATE event by one provider.</p> <p>Pre-Conditions:</p> <ul> <li>Two Providers are previously registered and published APIs</li> <li>Two invoker are previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1 and publish service_1 api:<ul> <li>Store apiId1</li> </ul> </li> <li>Register Provider 2 and publish service_2 api:<ul> <li>Store apiId2</li> </ul> </li> <li>Register and onboard Invoker 1<ul> <li>apiInvokerId1</li> </ul> </li> <li>Register and onboard Invoker 2<ul> <li>apiInvokerId2</li> </ul> </li> <li>Subscribe to events:<ol> <li>Subscription1</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Subscription2</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiInvokerId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe to events:<ol> <li>Subscription3</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [apiInvokerId2] and [apiId2].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Create Security Context Between Invoker 1 and provider 1 exposed API.<ol> <li>Store acl_provider_1</li> </ol> </li> <li>Create Security Context Between Invoker 2 and provider 1 exposed API.<ol> <li>Store acl_provider_1 (array will contain 2 values)</li> </ol> </li> <li>Create Security Context Between Invoker 1 and provider 2 exposed API.<ol> <li>Store acl_provider_2 (array will contain 2 values)</li> </ol> </li> <li>Create Security Context Between Invoker 2 and provider 2 exposed API.<ol> <li>Store acl_provider_2 (array will contain 2 values)</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Eight Events have been received for 3 different subscriptions.</li> <li>Validate received events follow EventNotification data structure</li> <li>Subcription 1:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 1 (acl_provider_1[1])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])</li> </ol> </li> </ol> </li> <li>Subcription 2:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])</li> </ol> </li> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])</li> </ol> </li> </ol> </li> <li>Subcription 3:<ol> <li>ACCESS_CONTROL_POLICY_UPDATE:<ol> <li>EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-6-provider-subscribed-to-access_control_policy_update-event-filtered-by-aefid","title":"Test Case 6: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by aefId","text":"<p>Test ID: event_filter-6 Additional Tags:</p> <p>Description:</p> <p>This test will check ACCESS_CONTROL_POLICY_UPDATE event subscription by Provider with not valid filters.</p> <p>Pre-Conditions:</p> <ul> <li>One Provider is previously registered.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1.</li> <li>Subscribe to events:<ol> <li>Subscription1</li> <li>Events: ACCESS_CONTROL_POLICY_UPDATE</li> <li>EventFilter: [aef_ids].</li> <li>supportedFeatures: C</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Invalid eventFilter for event ACCESS_CONTROL_POLICY_UPDATE</li> <li>invalidParams: [{ param:eventFilter, reason: The eventFilter aef_ids for event ACCESS_CONTROL_POLICY_UPDATE are not applicable }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-7-provider-subscribed-to-service_api_invocation_success-and-service_api_invocation_failure-filtered-by-apiid-invokerid-aefid-and-all-of-them","title":"Test Case 7: Provider subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE filtered by apiId, invokerId, aefId and all of them","text":"<p>Test ID: event_filter-7 Additional Tags: smoke, mockserver</p> <p>Description:</p> <p>This test will check all possible filters options allowed for SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE.</p> <p>Pre-Conditions:</p> <ul> <li>Two Providers are previously registered and published APIs</li> <li>Two invoker are previously registered.</li> <li>Mock Server is up and running to receive requests.</li> <li>Mock Server is clean.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider 1 and publish service_1 api:<ul> <li>Store apiId1</li> <li>Store aefId1</li> </ul> </li> <li>Register Provider 2 and publish service_2 api:<ul> <li>Store apiId2</li> <li>Store aefId2</li> </ul> </li> <li>Register and onboard Invoker 1<ul> <li>apiInvokerId1</li> </ul> </li> <li>Register and onboard Invoker 2<ul> <li>apiInvokerId2</li> </ul> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 1</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 2</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 3</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 4</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 5</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 6</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Subscribe provider 1 to events:<ol> <li>Subscription 7</li> <li>Events: SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.</li> <li>EventFilter: [apiId1], [apiId1].</li> <li>supportedFeatures: C</li> </ol> </li> <li>Send Log entry by provider1:<ol> <li>apiNames: [service_1]</li> <li>apiIds: [apiId1]</li> <li>aefId: aefId1</li> <li>apiInvokerId: apiInvokerId1</li> <li>results: [200, 400]</li> <li>Store body to request_body_log_1</li> </ol> </li> <li>Send Log entry by provider2:<ol> <li>apiNames: [service_2]</li> <li>apiIds: [apiId2]</li> <li>aefId: aefId2</li> <li>apiInvokerId: apiInvokerId1</li> <li>results: [200]</li> <li>Store body to request_body_log_2</li> </ol> </li> <li>Send Log entry by provider2:<ol> <li>apiNames: [service_2]</li> <li>apiIds: [apiId2]</li> <li>aefId: aefId2</li> <li>apiInvokerId: apiInvokerId2</li> <li>results: [200]</li> <li>Store body to request_body_log_3</li> </ol> </li> <li>Send Log entry by provider1:<ol> <li>apiNames: [service_1]</li> <li>apiIds: [apiId1]</li> <li>aefId: aefId1</li> <li>apiInvokerId: apiInvokerId2</li> <li>results: [400]</li> <li>Store body to request_body_log_4</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Thirteen Events have been received for 7 different subscriptions.</li> <li>Validate received events follow EventNotification data structure</li> <li>Subcription 1:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_4</li> </ol> </li> </ol> </li> <li>Subcription 2:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 3:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_1</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> </ol> </li> <li>Subcription 4:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_2</li> </ol> </li> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 5:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> <li>Subcription 6:<ol> <li>SERVICE_API_INVOCATION_FAILURE:<ol> <li>EventDetail include invocationLogs with request_body_log_4</li> </ol> </li> </ol> </li> <li>Subcription 7:<ol> <li>SERVICE_API_INVOCATION_SUCCESS:<ol> <li>EventDetail include invocationLogs with request_body_log_3</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/event_filter/#test-case-8-event-filter-present-with-enhanced_event_report-feature-not-active","title":"Test Case 8: Event Filter present with Enhanced_event_report feature not active.","text":"<p>Test ID: event_filter-8 Additional Tags: smoke</p> <p>Description:</p> <p>This test will check event subscription by Invoker with eventFilter attribute but without Enhanced_event_report feature active.</p> <p>Pre-Conditions:</p> <ul> <li>Invoker is previously registered and onboarded.</li> </ul> <p>Execution Steps:</p> <ol> <li>Register and onboard Invoker</li> <li>Subscribe to events:<ol> <li>Events: SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE</li> <li>EventFilter: [empty], [empty], [empty].</li> <li>supportedFeatures: 0</li> </ol> </li> </ol> <p>Expected Results:</p> <ol> <li>Response to subscription:<ol> <li>400 Bad Request</li> <li>ProblemDetails Body with:<ol> <li>title: Bad Request</li> <li>status: 400</li> <li>detail: Bad Param</li> <li>cause: Event filters provided but EnhancedEventReport is not enabled</li> <li>invalidParams: [{ param:eventFilter, reason: EnhancedEventReport is not enabled }]</li> </ol> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/","title":"Test Plan for Vendor Extensibility Feature","text":"<p>At this documentation you will have all information and related files and examples of test plan for this feature.</p>"},{"location":"testing/testplan/vendor_extensibility/#test-case-1-published-api-with-vendor-extensibility","title":"Test Case 1: Published API with vendor extensibility","text":"<p>Test ID: vendor_extensibility-1</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag active and vendorSpecific, can be discovered by invoker with all vendorSpecific fields.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>includes supported-features with VendSpecQueryParams active (binary 010 -> string 2)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if contains the vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-2-published-api-with-vendor-extensibility-and-discover-with-vendspecqueryparams-disabled","title":"Test Case 2: Published API with vendor extensibility and discover with VendSpecQueryParams disabled","text":"<p>Test ID: vendor_extensibility-2</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag active and vendorSpecific, but discovered filter only APIs without vendorSpecific parameter</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-3-publish-api-with-vendorext-active-and-discover-without-supported-features-filter","title":"Test Case 3: Publish API with vendorExt active and discover without supported features filter","text":"<p>Test ID: vendor_extensibility-3</p> <p>Description:</p> <p>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</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li>Response to Discover Request By Invoker:<ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check NOT contains the vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-4-publish-api-with-vendorext-active-but-without-vendorspecifics","title":"Test Case 4: Publish API with vendorExt active but without vendorSpecifics","text":"<p>Test ID: vendor_extensibility-4</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 1 0000 0000 -> string 100)</li> <li>This API NOT includes any \"Vendor Specific\" information.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDED vendor specific service in root of service api description.</li> <li>NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 100</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"If and only if VendorExt feature is enabled, then vendor-specific fields should be defined\".</li> <li>cause with message \"Vendor extensibility misconfiguration\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-5-publish-api-with-vendorext-inactive-but-with-vendorspecifics","title":"Test Case 5: Publish API with vendorExt inactive but with vendorSpecifics","text":"<p>Test ID: vendor_extensibility-5</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API includes any \"Vendor Specific\" information.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>include vendor specific service in root of service api description.</li> <li>include vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 000</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"If and only if VendorExt feature is enabled, then vendor-specific fields should be defined\".</li> <li>cause with message \"Vendor extensibility misconfiguration\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-6-published-api-without-vendor-extensibility-discover-with-vendspecqueryparams-enabled","title":"Test Case 6: Published API without vendor extensibility discover with VendSpecQueryParams enabled","text":"<p>Test ID: vendor_extensibility-6</p> <p>Description:</p> <p>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</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API NOT includes \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>Supported-features: binary 010 -> string 2</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDED vendor specific service in root of service api description.</li> <li>NOT INCLUDED vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 00</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include any \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>404 Not Found response.</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 404</li> <li>title with message \"Not Found\"</li> <li>detail with message \"API Invoker {api_invoker_id} has no API Published that accomplish filter conditions\".</li> <li>cause with message \"No API Published accomplish filter conditions\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-7-published-api-without-vendor-extensibility-and-discover-with-vendspecqueryparams-disabled","title":"Test Case 7: Published API without vendor extensibility and discover with vendSpecQueryParams disabled","text":"<p>Test ID: vendor_extensibility-7</p> <p>Description:</p> <p>This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker filtering by vendSpecQueryParams.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 0)</li> <li>This API NOT includes any \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>includes supported-features with VendSpecQueryParams active (binary 000 -> string 0)</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDE vendor specific service in root of service api description.</li> <li>NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 0</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains any vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-8-published-api-without-vendor-extensibility-and-discover-without-supported-features-query-parameter","title":"Test Case 8: Published API without vendor extensibility and discover without supported-features query parameter","text":"<p>Test ID: vendor_extensibility-8</p> <p>Description:</p> <p>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.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF:<ol> <li>Supported Features with vendorExt flag active (binary 0 0000 0000 -> string 000)</li> <li>This API NOT includes any \"Vendor Specific\" information at service API Description and inside AEF Profile.</li> </ol> </li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker<ol> <li>NOT includes supported-features</li> </ol> </li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>NOT INCLUDE vendor specific service in root of service api description.</li> <li>NOT INCLUDE vendor specific aef profile in one AEFProfile inside aefProfiles key.</li> <li>supportedFeatures 000</li> <li>Use APF Certificate</li> </ul> </li> <li>Request Discover Published APIs:<ul> <li>Send GET to https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}</li> <li>Param api-invoker-id is mandatory</li> <li>Use Invoker Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li> <p>Response to Publish request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow ServiceAPIDescription data structure with:<ul> <li>apiId</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}</li> <li>Response must NOT include \"vendorSpecific\" keys inside root and at AEF Profile.</li> </ol> </li> <li> <p>Response to Onboard request must accomplish:</p> <ol> <li>201 Created</li> <li>Response Body must follow APIInvokerEnrolmentDetails data structure with:<ul> <li>apiInvokerId</li> <li>onboardingInformation->apiInvokerCertificate must contain the public key signed.</li> </ul> </li> <li>Response Header Location must be received with URI to new resource created, following this structure: {apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}</li> </ol> </li> <li> <p>Response to Discover Request By Invoker:</p> <ol> <li>200 OK response.</li> <li>Response body must follow DiscoveredAPIs data structure:<ul> <li>Check if DiscoveredAPIs contains the API Published previously</li> <li>Check if NOT contains any vendorSpecific keys</li> </ul> </li> </ol> </li> </ol>"},{"location":"testing/testplan/vendor_extensibility/#test-case-9-publish-api-without-supportedfeatures","title":"Test Case 9: Publish API without supportedFeatures","text":"<p>Test ID: vendor_extensibility-9</p> <p>Description:</p> <p>This test case will check if a published API without supportedFeatures receives the 400 Bad Request, because is not allowed by definition.</p> <p>Pre-Conditions:</p> <ul> <li>Network App was registered previously</li> <li>Network App was onboarded previously with {onboardingId}</li> </ul> <p>Execution Steps:</p> <ol> <li>Register Provider at CCF, store certificates.</li> <li>Publish Service API at CCF.</li> <li>Register Invoker and Onboard Invoker at CCF</li> <li>Discover Service APIs by Invoker</li> </ol> <p>Information of Test:</p> <ol> <li>Perform Provider Registration and Invoker Onboarding</li> <li>Publish Service API at CCF:<ul> <li>Send POST to ccf_publish_url https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis</li> <li>body service api description with apiName service_1</li> <li>without supportedFeatures parameter.</li> <li>Use APF Certificate</li> </ul> </li> </ol> <p>Expected Result:</p> <ol> <li>Response to Publish request must accomplish:<ol> <li>400 Bad Request</li> <li>Error Response Body must accomplish with ProblemDetails data structure with:<ul> <li>status 400</li> <li>title with message \"Bad Request\"</li> <li>detail with message \"supportedFeatures not present in request\".</li> <li>cause with message \"supportedFeatures not present\".</li> </ul> </li> </ol> </li> </ol>"},{"location":"vendor-ext/vendor-ext/","title":"Vendor Extensibility","text":"<p>Mechanism for the APIs to re-use, extend their functionalities and data models and engage with third-party API frameworks (e.g. ETSI MEC)</p> <p>Vendor specific extensions are defined on 3GPP TS 29.122 (section 5.2.13) and 29.500 (section 6.6.3) and is tightly connected with \"supported-features\u201d and \"feature negotiation\" procedures.</p>"},{"location":"vendor-ext/vendor-ext/#vendor-extensibility-in-capif","title":"Vendor Extensibility in CAPIF:","text":"<p>Vendor Extensibility is a feature focused on the APIs that are published and exposed via CAPIF. As a result, the feature is supported by the ServiceAPIDescription object (and any other objects embeded on it e.g. AefProfile). In the figure below, depicting all supported features of ServiceAPIDescription, VendExt feature is noted, which enables vendor-specific extension in the body of the specific object.</p> <p></p> <p>Vendor extensibility feature can be enabled and leveraged in 2 CAPIF APIs, Publish and Discover.</p>"},{"location":"vendor-ext/vendor-ext/#vendor-extensibility-in-capif-apis","title":"Vendor Extensibility in CAPIF APIs","text":""},{"location":"vendor-ext/vendor-ext/#publish-api","title":"Publish API","text":"<p>A vendor can extend the ServiceAPIDescription object by adding additional member elements. However, in order to avoid duplication of member names inside a same object it is necessary to comply with a naming scheme for vendor-specific data elements, to avoid clashing names between vendors. Vendor-specific member names in JSON objects shall be named in the following manner:</p> <pre><code> \"vendorSpecific-nnnnnnnnn\": {\n ...\n }\n</code></pre> <p>where the value \"nnnnnn\" can be:</p> <ol> <li>6-digit IANA-assigned enterprise code:</li> </ol> <pre><code> \"vendorSpecific-010415\": {\n ...\n }\n</code></pre> <ol> <li>domain name:</li> </ol> <pre><code>\"vendorSpecific-3gpp.org\": {\n ...\n }\n</code></pre> <ol> <li>URN:</li> </ol> <pre><code>\"vendorSpecific-urn:3gpp:example\": {\n ...\n }\n</code></pre> <p>A concrete example of vendor-specific extensibility exists on section 9 of ETSI GS MEC 011 V3.2.1, where ETSI MEC extends the ServiceAPIDescription as depicted on the following two figures.</p> <p></p> <p></p> <p>Example:</p> <p>ServiceAPIDescription vendorSpecific looks like:</p> <pre><code>\"vendorSpecific-urn:etsi:mec:capifext:service-info\": {\n \"serializer\": \"JSON\",\n \"state\": \"ACTIVE\",\n \"scopeOfLocality\": \"MEC_SYSTEM\",\n \"consumedLocalOnly\": \"True\",\n \"isLocal\": \"True\",\n \"category\": {\n \"href\": \"https://www.location.com\",\n \"id\": \"location_1\",\n \"name\": \"Location\",\n \"version\": \"1.0\"\n }\n}\n</code></pre> <p>AEFProfile vendorSpecific looks like:</p> <pre><code>\"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n}\n</code></pre> <p>Complete ETSI MEC ServiceAPIDescription with vendor extensibility would be like this:</p> <pre><code>{\n \"apiName\": \"service_1\",\n \"vendorSpecific-urn:etsi:mec:capifext:service-info\": {\n \"serializer\": \"JSON\",\n \"state\": \"ACTIVE\",\n \"scopeOfLocality\": \"MEC_SYSTEM\",\n \"consumedLocalOnly\": \"True\",\n \"isLocal\": \"True\",\n \"category\": {\n \"href\": \"https://www.location.com\",\n \"id\": \"location_1\",\n \"name\": \"Location\",\n \"version\": \"1.0\"\n }\n },\n \"aefProfiles\": [\n {\n \"aefId\": \"string\",\n \"vendorSpecific-urn:etsi:mec:capifext:transport-info\": {\n \"name\": \"trasport1\",\n \"description\": \"Transport Info 1\",\n \"type\": \"REST_HTTP\",\n \"protocol\": \"HTTP\",\n \"version\": \"2\",\n \"security\": {\n \"grantTypes\": \"OAUTH2_CLIENT_CREDENTIALS\",\n \"tokenEndpoint\": \"https://token-endpoint/\"\n }\n },\n \"versions\": [\n {}\n ],\n \"protocol\": \"HTTP_1_1\",\n \"dataFormat\": \"JSON\",\n \"securityMethods\": [\"PSK\"],\n \"interfaceDescriptions\": [\n {\n \"ipv4Addr\": \"string\",\n \"port\": 65535,\n \"securityMethods\": [\"PSK\"]\n }\n ]\n }\n ],\n \"description\": \"string\",\n \"supportedFeatures\": \"0\",\n \"shareableInfo\": {\n \"isShareable\": true,\n \"capifProvDoms\": [\n \"string\"\n ]\n },\n \"serviceAPICategory\": \"string\",\n \"apiSuppFeats\": \"fffff\",\n \"pubApiPath\": {\n \"ccfIds\": [\n \"string\"\n ]\n },\n \"ccfId\": \"string\"\n}\n</code></pre>"},{"location":"vendor-ext/vendor-ext/#discover-api","title":"Discover API","text":"<p>In order to use vendor-specific fields as filters in Discover API, vendor-specific query parameter shall be encoded as follows:</p> <pre><code>https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-<query parameter name>={\n \"target\": <string that contains the JSON pointer to the attribute in the resource representation>, \n \"value\": <query parameter value>\n}\n</code></pre> <p>Example:</p> <pre><code> https://{{CAPIF_HOSTNAME}}:{{CAPIF_PORT}}/{{DISCOVER_URL}}?\n ...\n vend-spec-type={\n \"target\": \"/vendorSpecific-urn:etsi:mec:capifext:transport-info\", \n \"value\": \"REST_HTTP\"\n }\n</code></pre>"}]}
\ No newline at end of file
diff --git a/public/develop/sitemap.xml b/public/develop/sitemap.xml
index 3b17df3..229dfcd 100644
--- a/public/develop/sitemap.xml
+++ b/public/develop/sitemap.xml
@@ -2,146 +2,146 @@
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://ocf.etsi.org/develop/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/FAQ/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/architecture/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/releasenotes/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/api-status/api-status/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/configuration/configuration/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/contribute/documenting/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/event-filter/event-filter/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/example-clients/example-clients/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/gettingstarted/howtorun/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/gettingstarted/repository/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/helper/helper/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/helper/swagger/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/register/register/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/register/swagger/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/sandbox/relevantinfo/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/sandbox/requestaccess/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/sandbox/sandbox/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/sdk/sdk/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/postman/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/robotframework/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_access_control_policy/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_auditing_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_discover_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_events_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_invoker_management/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_logging_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_provider_management/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_publish_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_security_service/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/api_status/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/common_operations/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/event_filter/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/testing/testplan/vendor_extensibility/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
<url>
<loc>https://ocf.etsi.org/develop/vendor-ext/vendor-ext/</loc>
- <lastmod>2025-03-31</lastmod>
+ <lastmod>2025-04-03</lastmod>
</url>
</urlset>
\ No newline at end of file
diff --git a/public/develop/sitemap.xml.gz b/public/develop/sitemap.xml.gz
index 496dc4c1f22a721d63db1f9042c26594c981e1b6..4a9cf06a141834521231f4956dfe699aa31c14c3 100644
GIT binary patch
delta 526
zcmV+p0`dKy1fK*4ABzYGfY0rb2OWRYZ7a1^l2tEzuhgC`0uvi8W+*eZleh2KNu#tm
zwFj^zYXD*XkMRJ*_T|*M)c}z!`d#sEy(w1UH5%)iUGd}lYx${o**|Uj=m>ZvojvV}
zmN|T>s&O3GWEnaYXpOO{NVig<>e^Us)}M?0(@LIcfJ<q9whr}v8iiyS)W?4{Fxhzs
z0|Ph=)wY_t+<&2nJ2d;}&GW}{^P$|lmoC?~i$rzP_-D1(uip|Ys;FD>lIA`_V(ADD
z6oE$uN<HgfOJc=6-51j`X!J+h^ii>d{9m=?BpmIbXQ&M7z5~y)>=HwW@mwCQV~BrN
z5_6nX7aWw@Sz(}udRm$Wc=~@A5}=X6R4tB-vG;i?A_SDJ72`QEM++`UKwM20Z5mb6
zBo~j+Sen+tt&mAS&-6)obHLMlVhn29osO6d;b#xB5VQuOObowmVs-O2ziCw^H<%A2
z*>Sj2K9hRH1M)Gd4n~Z*Trk<-viaa9FBwyPiT`@e9MIJPoz>?>fc1XHPOUXT9IS>V
zFd0i4<!-Yira8l+B@tOa;F~x}R=H|mN<x=F<*;cM7EU4JV9nw@75am-)Go<W1iFuw
z&x>Npao2nx(b#q9Ym}6BzHw#;n)jnR%Z=}WMNkaJ8cqzJ?7=z-p~OrVgi;Xhi~r3q
Q8v@?{0<YO$lxPzG0BSV;?EnA(
delta 526
zcmV+p0`dKy1fK*4ABzYG0Nd%22OWR2yQ<VyNmhH=d!_bl5t!I$F+-WLoxFX=P8y}%
zQ+ohgvIY?5{}>N2Y+p{DTMZD&qTdyd>rJr&uhCfF?1~@X-^$O$%l={8M@PUb>FjA&
zw9MgaRgL4gCd<&NKx>RmMY@#=RoBL9v;I=-A6D{A16)e;vvsKV(<mgvpgw=DfyvH8
z7#P4|sJ7MA<^Bsr+@aY&ZJs`ro9FWRQMz2)E)vyE<Db>uUcV()R8hC$CCz<=#L^KQ
zC<2cRlzP^|mc)vCx-X_>(CCl0>7!x^`M+w(NjTa=&rliEeFvUp*(HV$<GDOq#}NOl
zB<47&E;uN)v%)|h>S<{j;OT!~NPtELQ?)oU#@^?ph!9Y=R*dJw94)vY0dX~1v}sgL
zlUzJPV`*9ow?ZcUJkuxT%>hsIi7}{YcRFG=gr7agLeLtBGBNzNiPg>f{H9fv++aS8
zWXIu7`Aq5&56H);Iv6qLa=~PS%jScdykt!ECI0I<b3j)IbXK1i0oHySJGIsXaj+Ve
zz+^0Gl)KH6nC1+NmPBOzfbZfYS>>vMDG6NymBXf4SU81<gEfouROk=RQoAHi5$HZz
zJ}-(X$6fOSiN>x&U!$b7^Nlk*(7YejS#EqESOmpjtl`Aq$sVke5K7E+K_~^`zWCn^
QvmxO9FFzc<;Aj&703U}3F#rGn
diff --git a/public/develop/testing/postman/index.html b/public/develop/testing/postman/index.html
index 85491b1..98f172f 100644
--- a/public/develop/testing/postman/index.html
+++ b/public/develop/testing/postman/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/robotframework/index.html b/public/develop/testing/robotframework/index.html
index dcdb963..c8df2f3 100644
--- a/public/develop/testing/robotframework/index.html
+++ b/public/develop/testing/robotframework/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_access_control_policy/index.html b/public/develop/testing/testplan/api_access_control_policy/index.html
index f70f7fe..804c1ab 100644
--- a/public/develop/testing/testplan/api_access_control_policy/index.html
+++ b/public/develop/testing/testplan/api_access_control_policy/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_auditing_service/index.html b/public/develop/testing/testplan/api_auditing_service/index.html
index f02358a..00902b7 100644
--- a/public/develop/testing/testplan/api_auditing_service/index.html
+++ b/public/develop/testing/testplan/api_auditing_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_discover_service/index.html b/public/develop/testing/testplan/api_discover_service/index.html
index 9bf18a0..b3e59cd 100644
--- a/public/develop/testing/testplan/api_discover_service/index.html
+++ b/public/develop/testing/testplan/api_discover_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_events_service/index.html b/public/develop/testing/testplan/api_events_service/index.html
index 08ff7d5..5c6d366 100644
--- a/public/develop/testing/testplan/api_events_service/index.html
+++ b/public/develop/testing/testplan/api_events_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_invoker_management/index.html b/public/develop/testing/testplan/api_invoker_management/index.html
index 2a894f8..d3f86af 100644
--- a/public/develop/testing/testplan/api_invoker_management/index.html
+++ b/public/develop/testing/testplan/api_invoker_management/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_logging_service/index.html b/public/develop/testing/testplan/api_logging_service/index.html
index 87cd0bd..1689ad8 100644
--- a/public/develop/testing/testplan/api_logging_service/index.html
+++ b/public/develop/testing/testplan/api_logging_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_provider_management/index.html b/public/develop/testing/testplan/api_provider_management/index.html
index 71b69e6..f19c338 100644
--- a/public/develop/testing/testplan/api_provider_management/index.html
+++ b/public/develop/testing/testplan/api_provider_management/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_publish_service/index.html b/public/develop/testing/testplan/api_publish_service/index.html
index 10d9c23..728adac 100644
--- a/public/develop/testing/testplan/api_publish_service/index.html
+++ b/public/develop/testing/testplan/api_publish_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_security_service/index.html b/public/develop/testing/testplan/api_security_service/index.html
index 5eecab8..2b12586 100644
--- a/public/develop/testing/testplan/api_security_service/index.html
+++ b/public/develop/testing/testplan/api_security_service/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/api_status/index.html b/public/develop/testing/testplan/api_status/index.html
index ee5083d..87cd6f1 100644
--- a/public/develop/testing/testplan/api_status/index.html
+++ b/public/develop/testing/testplan/api_status/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/common_operations/index.html b/public/develop/testing/testplan/common_operations/index.html
index e19c82d..d91880c 100644
--- a/public/develop/testing/testplan/common_operations/index.html
+++ b/public/develop/testing/testplan/common_operations/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/event_filter/index.html b/public/develop/testing/testplan/event_filter/index.html
index 039ed98..123ba23 100644
--- a/public/develop/testing/testplan/event_filter/index.html
+++ b/public/develop/testing/testplan/event_filter/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/index.html b/public/develop/testing/testplan/index.html
index 216fc1d..89229f8 100644
--- a/public/develop/testing/testplan/index.html
+++ b/public/develop/testing/testplan/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/testing/testplan/vendor_extensibility/index.html b/public/develop/testing/testplan/vendor_extensibility/index.html
index 2bc985e..32388a1 100644
--- a/public/develop/testing/testplan/vendor_extensibility/index.html
+++ b/public/develop/testing/testplan/vendor_extensibility/index.html
@@ -18,7 +18,7 @@
<link rel="icon" href="../../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -127,11 +127,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -163,6 +165,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
diff --git a/public/develop/vendor-ext/vendor-ext/index.html b/public/develop/vendor-ext/vendor-ext/index.html
index 33e9050..fc65c32 100644
--- a/public/develop/vendor-ext/vendor-ext/index.html
+++ b/public/develop/vendor-ext/vendor-ext/index.html
@@ -22,7 +22,7 @@
<link rel="icon" href="../../images/favicon.png">
- <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.10">
+ <meta name="generator" content="mkdocs-1.6.1, mkdocs-material-9.6.11">
@@ -131,11 +131,13 @@
- <label class="md-header__button md-icon" for="__search">
-
- <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
- </label>
- <div class="md-search" data-md-component="search" role="dialog">
+
+
+ <label class="md-header__button md-icon" for="__search">
+
+ <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M9.5 3A6.5 6.5 0 0 1 16 9.5c0 1.61-.59 3.09-1.56 4.23l.27.27h.79l5 5-1.5 1.5-5-5v-.79l-.27-.27A6.52 6.52 0 0 1 9.5 16 6.5 6.5 0 0 1 3 9.5 6.5 6.5 0 0 1 9.5 3m0 2C7 5 5 7 5 9.5S7 14 9.5 14 14 12 14 9.5 12 5 9.5 5"/></svg>
+ </label>
+ <div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
@@ -167,6 +169,7 @@
</div>
</div>
</div>
+
<div class="md-header__source">
--
GitLab