Repository: Aitia-IIOT/ah5-docs-java-spring
Pull request #21: Documenting authentication policies
Author: login: borditamas
Created: 2025-03-10T21:34:01Z | Merged: 2025-03-24T12:19:05Z

Changes deployed to: https://aitia-iiot.github.io/ah5-docs-java-spring


Diff:
diff --git a/docs/api/authentication_policy.md b/docs/api/authentication_policy.md
new file mode 100644
index 00000000..1c455541
--- /dev/null
+++ b/docs/api/authentication_policy.md
@@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certificate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to be authenticated and to join the Local Cloud always depend on the actual authentication method behind the identity service, but the outcome is always an identity token (and optionally an expiration time) that the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) identity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) identity info is contained in the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) identity info is a string token generated by a dedicated Core or Support system and obtained as a result of a successful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN//<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) identiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
+
+~~~
+SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"SYSTEM//temperature-consumer1",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### certificate-mqtt
+
+The [certificate](#certificate) identity info is contained by the client certificate that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) where the [PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/#ftoc-heading-1) format of the certificate is expected as a [Base64](https://datatracker.ietf.org/doc/html/rfc4648#section-4) encoded string.
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0...",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### outsourced-mqtt
+
+The [outsourced](#outsourced) identity info is a string token generated by a dedicated Core or Support system and obtained as a result of a successful authentication attempt. This token must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme:
+
+~~~
+IDENTITY-TOKEN//<token>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
diff --git a/docs/api/serviceregistry/device-discovery-generic-http.md b/docs/api/serviceregistry/device-discovery-generic-http.md
index f6946f1b..ac3c6d3c 100644
--- a/docs/api/serviceregistry/device-discovery-generic-http.md
+++ b/docs/api/serviceregistry/device-discovery-generic-http.md
@@ -33,12 +33,12 @@ Hereby the **Interface Design Description** (IDD) is provided to the [device-dis
 
 ### register
 
-The service operation **request** requires an authorization bearer header and a [DeviceRegistrationRequest](../data-models/device-registration-request.md)
+The service operation **request** requires an [identity related header or certfificate](../authentication_policy.md/#http) and a [DeviceRegistrationRequest](../data-models/device-registration-request.md)
 JSON encoded body.
 
 ```
 POST /serviceregistry/device-registry/register HTTP/1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 
 {
    "name":"thermometer2",
@@ -109,11 +109,11 @@ The **error codes** are `400` if the request is malformed, `401` if the requeste
 
 ### lookup
 
-The service operation **request** requires an authorization bearer header and may optionally include a [DeviceLookupRequest](../data-models/device-lookup-request.md) JSON encoded body.
+The service operation **request** requires an [identity related header or certfificate](../authentication_policy.md/#http) and may optionally include a [DeviceLookupRequest](../data-models/device-lookup-request.md) JSON encoded body.
 
 ```
 POST /serviceregistry/device-registry/lookup HTTP/1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 
 {
    "deviceNames":[
@@ -182,11 +182,11 @@ The error codes are, `400` if the request is malformed, `401` if the requester a
 
 ### revoke
 
-The service operation **request** requires an authorization bearer header and a device `name` as path parameter.
+The service operation **request** requires an [identity related header or certfificate](../authentication_policy.md/#http) and a device `name` as path parameter.
 
 ```
 DELETE /serviceregistry/device-discovery/revoke/thermometer2 HTTP/1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 ```
 
 The service operation **responds** with the status code `200` if called successfully and an existing device
diff --git a/docs/api/serviceregistry/device-discovery-generic-mqtt.md b/docs/api/serviceregistry/device-discovery-generic-mqtt.md
index b94008cb..bfd9e35b 100644
--- a/docs/api/serviceregistry/device-discovery-generic-mqtt.md
+++ b/docs/api/serviceregistry/device-discovery-generic-mqtt.md
@@ -33,14 +33,14 @@ Hereby the **Interface Design Description** (IDD) is provided to the [device-dis
 
 ### register
 
-The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the payload is a [DeviceRegistrationRequest](../data-models/device-registration-request.md).
+The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the authentication is a proper [identity info](../../api/authentication_policy.md/#mqtt) and the payload is a [DeviceRegistrationRequest](../data-models/device-registration-request.md).
 
 ```
 Topic: arrowhead/serviceregistry/device-discovery/register
 
 {
    "traceId":"<trace-id>",
-   "authentication":"<authentication-data>",
+   "authentication":"<identity-info>",
    "responseTopic":"<response-topic>",
    "qosRequirement":"<0|1|2>",
    "payload":{
@@ -123,14 +123,14 @@ The **error codes** are `400` if the request is malformed, `401` if the requeste
 
 ### lookup
 
-The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the payload is a  [DeviceLookupRequest](../data-models/device-lookup-request.md).
+The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the authentication is a proper [identity info](../../api/authentication_policy.md/#mqtt) and the payload is a  [DeviceLookupRequest](../data-models/device-lookup-request.md).
 
 ```
 Topic: arrowhead/serviceregistry/device-discovery/lookup
 
 {
    "traceId":"<trace-id>",
-   "authentication":"<authentication-data>",
+   "authentication":"<identity-info>",
    "responseTopic":"<response-topic>",
    "qosRequirement":"<0|1|2>",
    "payload":{
@@ -212,14 +212,14 @@ The **error codes** are, `400` if the request is malformed, `401` if the request
 
 ### revoke
 
-The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the payload is the `device name`.
+The service operation **request** requires an [MQTTRequestTemplate](../data-models/mqtt-request-template.md) JSON encoded message in which the authentication is a proper [identity info](../../api/authentication_policy.md/#mqtt) and the payload is the `device name`.
 
 ```
 Topic: arrowhead/serviceregistry/device-discovery/revoke
 
 {
    "traceId":"<trace-id>",
-   "authentication":"<authentication-data>",
+   "authentication":"<identity-info>",
    "responseTopic":"<response-topic>",
    "qosRequirement":"<0|1|2>",
    "payload":"thermometer2"
diff --git a/docs/api/serviceregistry/system-discovery-generic-http.md b/docs/api/serviceregistry/system-discovery-generic-http.md
index 83dea6d3..2c1c49cf 100644
--- a/docs/api/serviceregistry/system-discovery-generic-http.md
+++ b/docs/api/serviceregistry/system-discovery-generic-http.md
@@ -29,12 +29,12 @@ Hereby the **Interface Design Description** (IDD) is provided to the [system-dis
 
 ### register
 
-The service operation **request** requires an authorization bearer header and a [SystemRegistrationRequest](../data-models/system-registration-request.md)
+The service operation **request** requires an [identity related header or certfificate](../authentication_policy.md/#http) and a [SystemRegistrationRequest](../data-models/system-registration-request.md)
 JSON encoded body.
 
 ```
 POST /serviceregistry/system-discovery/register HTTP/1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 
 {
   "metadata": {
@@ -126,11 +126,11 @@ The **error codes** are `400` if the request is malformed, `401` if the requeste
 
 ### lookup
 
-The service operation **request** requires an authorization bearer header. The URI can contain an optional query parameter with the key "_verbose_" and a [Boolean](../primitives.md#boolean) value. If verbose is true, detailed device information also returns (only if the provider supports it). The request may optionally include a [SystemLookupRequest](../data-models/system-lookup-request.md) JSON encoded body.
+The service operation **request** requires an [identity related header or certfificate](../authentication_policy.md/#http). The URI can contain an optional query parameter with the key "_verbose_" and a [Boolean](../primitives.md#boolean) value. If verbose is true, detailed device information also returns (only if the provider supports it). The request may optionally include a [SystemLookupRequest](../data-models/system-lookup-request.md) JSON encoded body.
 
 ```
 POST /serviceregistry/system-discovery/lookup?verbose=<verbose-value> HTTP/1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 
 {
   "systemNames": [
@@ -201,11 +201,11 @@ The error codes are, `400` if the request is malformed, `401` if the requester a
 
 ### revoke
 
-The service operation **request** only requires an authorization bearer header. The name of the system to be revoked will be identified during authentication.
+The service operation **request** only requires an [identity related header or certfificate](../authentication_policy.md/#http). The name of the system to be revoked will be identified during authentication.
 
 ```
 DELETE /serviceregistry/system-discovery/revoke HTTP1.1
-Authorization: Bearer <authorization-info>
+Authorization: Bearer <identity-info>
 ```
 
 The service operation **responds** with the status code `200` if called successfully and an existing system
diff --git a/docs/core_systems/system_authentication.md b/docs/core_systems/authentication.md
similarity index 83%
rename from docs/core_systems/system_authentication.md
rename to docs/core_systems/authentication.md
index b45ea892..82df76af 100644
--- a/docs/core_systems/system_authentication.md
+++ b/docs/core_systems/authentication.md
@@ -1,4 +1,4 @@
-# System Authentication
+# Authentication
 
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum congue neque, in lobortis felis mattis et. Sed tincidunt non urna eleifend posuere. Sed consequat nulla felis, non ultricies massa blandit eu. Nam in eros ac nunc viverra accumsan eu id risus.
 
@@ -6,6 +6,20 @@ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum
 
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum congue neque, in lobortis felis mattis et. Sed tincidunt non urna eleifend posuere. Sed consequat nulla felis, non ultricies massa blandit eu. Nam in eros ac nunc viverra accumsan eu id risus.
 
+### identity
+
+TODO
+
+### identity-management
+
+TODO
+
 ## Configuration
 
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum congue neque, in lobortis felis mattis et. Sed tincidunt non urna eleifend posuere. Sed consequat nulla felis, non ultricies massa blandit eu. Nam in eros ac nunc viverra accumsan eu id risus.
\ No newline at end of file
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum congue neque, in lobortis felis mattis et. Sed tincidunt non urna eleifend posuere. Sed consequat nulla felis, non ultricies massa blandit eu. Nam in eros ac nunc viverra accumsan eu id risus.
+
+## Changelog
+
+#### :material-tag: v5.0.0 
+
+- Initial 5th generation release.
\ No newline at end of file
diff --git a/docs/core_systems/service_authorization.md b/docs/core_systems/authorization.md
similarity index 97%
rename from docs/core_systems/service_authorization.md
rename to docs/core_systems/authorization.md
index 1b74631b..944c17e6 100644
--- a/docs/core_systems/service_authorization.md
+++ b/docs/core_systems/authorization.md
@@ -1,4 +1,4 @@
-# Service Authorization
+# Authorization
 
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum congue neque, in lobortis felis mattis et. Sed tincidunt non urna eleifend posuere. Sed consequat nulla felis, non ultricies massa blandit eu. Nam in eros ac nunc viverra accumsan eu id risus.
 
diff --git a/docs/core_systems/service_registry.md b/docs/core_systems/service_registry.md
index 142766e8..5a01478d 100644
--- a/docs/core_systems/service_registry.md
+++ b/docs/core_systems/service_registry.md
@@ -138,13 +138,7 @@ The system configuration properties can be found in the `application.properties`
 
 ### General parameters
 
-:fontawesome-solid-wrench: **server.address**
-
-IP address of the server.
-
-:fontawesome-solid-wrench: **server.port**
-
-Port number of the server
+See the [general configuration properties](../general/general_config_props.md).
 
 ### Database parameters
 
diff --git a/docs/general/general_config_props.md b/docs/general/general_config_props.md
new file mode 100644
index 00000000..c09d986b
--- /dev/null
+++ b/docs/general/general_config_props.md
@@ -0,0 +1,15 @@
+# General Configuartion Properties
+
+The following cofiguration properties are applied by every Core and Support system:
+
+:fontawesome-solid-wrench: **authentication.policy**
+
+Specifies the applied [authentication policy](../api/authentication_policy.md). Can be `declared`, `certificate` or `outsourced`. 
+
+:fontawesome-solid-wrench: **server.address**
+
+IP address of the server.
+
+:fontawesome-solid-wrench: **server.port**
+
+Port number of the server.
\ No newline at end of file
diff --git a/docs/help/tutorials/serviceregistry-http-demo.md b/docs/help/tutorials/serviceregistry-http-demo.md
index 31c18ddd..9c56174c 100644
--- a/docs/help/tutorials/serviceregistry-http-demo.md
+++ b/docs/help/tutorials/serviceregistry-http-demo.md
@@ -38,7 +38,7 @@ after registering itself into the Local Cloud.
 
 ### Step 1: Authentication
 
-First of all, the system should perform some kind of authentication. In Arrowhead 5, there are three ways for a system to authenticate itself: involving an Authentication Core System, using X.509 Certicifates, or telling who they are by themselves. In this example, the last one will be used, which is called _self-declared authentication_.
+First of all, the system should perform some kind of [authentication](../../api/authentication_policy.md). In this example the [declared](../../api/authentication_policy.md/#declared) authentication strategy will be used.
 
 To perform this type of authentication, the system must provide an authentication header for each request. This should consist of the _SYSTEM//_ prefix, followed by the name of the system. 
 
diff --git a/mkdocs.yml b/mkdocs.yml
index 6c95b443..6201affe 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -10,8 +10,8 @@ nav:
   - Core Systems:
     - Service Registry: core_systems/service_registry.md
     - Service Orchestration: core_systems/service_orchestration.md
-    - Service Authorization: core_systems/service_authorization.md
-    - System Authentication: core_systems/system_authentication.md
+    - Authorization: core_systems/authorization.md
+    - Authentication: core_systems/authentication.md
   - Support Systems: support_systems.md
   - API:
     - Interface Descriptions:
@@ -22,6 +22,7 @@ nav:
         - MQTT:
           - device-discovery: api/serviceregistry/device-discovery-generic-mqtt.md
           - system-discovery: api/serviceregistry/system-discovery-generic-mqtt.md          
+    - Authentication Policy: api/authentication_policy.md
     - Data Models:
       - AddressDescriptor: api/data-models/address-descriptor.md
       - DeviceDescriptor: api/data-models/device-descriptor.md


Reviews:
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:17:05Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:19:11Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:19:47Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:21:11Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:21:44Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:22:54Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:23:05Z
user: login: rbocsi
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:26:21Z
user: login: rbocsi
body: see inline comments
state: CHANGES_REQUESTED
author_association: COLLABORATOR
submitted_at: 2025-03-18T07:26:53Z
user: login: rbocsi
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-18T10:20:03Z
user: login: Katinka666
state: CHANGES_REQUESTED
author_association: COLLABORATOR
submitted_at: 2025-03-19T14:50:39Z
user: login: Katinka666
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-23T19:35:25Z

Review comments:
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
path: docs/api/authentication_policy.md
user: login: rbocsi
body: client => clients
created_at: 2025-03-18T07:17:05Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
path: docs/api/authentication_policy.md
user: login: rbocsi
body: identitiy => identity
created_at: 2025-03-18T07:19:11Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
path: docs/api/authentication_policy.md
user: login: rbocsi
body: identiy  => identity
created_at: 2025-03-18T07:19:47Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
path: docs/api/authentication_policy.md
user: login: rbocsi
body: succesful => successful
created_at: 2025-03-18T07:21:11Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN/<token>
path: docs/api/authentication_policy.md
user: login: rbocsi
body: need two slashes (//), not one
created_at: 2025-03-18T07:21:44Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN/<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
+
+~~~
+SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"SYSTEM//temperature-consumer1",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### certificate-mqtt
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) where the [PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/#ftoc-heading-1) format of the certificate is expected as a [Base64](https://datatracker.ietf.org/doc/html/rfc4648#section-4) encoded string.
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0...",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### outsourced-mqtt
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme:
path: docs/api/authentication_policy.md
user: login: rbocsi
body: succesful => successful
created_at: 2025-03-18T07:22:54Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all client are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identitiy tokens in order to prevent any kind of identitiy theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN/<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
+
+~~~
+SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"SYSTEM//temperature-consumer1",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### certificate-mqtt
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) where the [PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/#ftoc-heading-1) format of the certificate is expected as a [Base64](https://datatracker.ietf.org/doc/html/rfc4648#section-4) encoded string.
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0...",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### outsourced-mqtt
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a succesful authentication attempt. This token must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme:
+
+~~~
+IDENTITY-TOKEN/<token>
path: docs/api/authentication_policy.md
user: login: rbocsi
body: 2 slashes
created_at: 2025-03-18T07:23:05Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,15 @@
+# General Configuartion Properties
+
+The following cofiguration properties are applied by every core and support system:
+
+:fontawesome-solid-wrench: **authentication.policy**
+
+Specifies the applied [authentication policy](../api/authentication_policy.md). Can be `declared`, `certificate` and `outsourced`. 
+
+:fontawesome-solid-wrench: **server.address**
+
+IP address of the server.
+
+:fontawesome-solid-wrench: **server.port**
+
+Port number of the server
path: docs/general/general_config_props.md
user: login: rbocsi
body: missing dot
created_at: 2025-03-18T07:26:21Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
path: docs/api/authentication_policy.md
user: login: Katinka666
body: typo: system profile certif-i-cate
created_at: 2025-03-19T13:31:36Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
path: docs/api/authentication_policy.md
user: login: Katinka666
body: - The actual credentials required ~~to being~~ `to be` authenticated and ~~joining~~ `to join` ~~to~~ the Local Cloud ~~are always depending~~ `always depend`
- but the outcome is always an `identi-t-y` token (and optionally an expiration time) ~~what~~ `that `the authenticated system is required to use
created_at: 2025-03-19T13:43:29Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
path: docs/api/authentication_policy.md
user: login: Katinka666
body: typo: i ~~n~~ dentity
created_at: 2025-03-19T14:07:27Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
path: docs/api/authentication_policy.md
user: login: Katinka666
body: - typo: i ~~n~~ dentity
- (I think "contained **in** the client certificate" might be better)
created_at: 2025-03-19T14:09:39Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a successful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
path: docs/api/authentication_policy.md
user: login: Katinka666
body: - typo: i ~~n~~ dentity
- previously it was "Core or Support system" (with capitals)
created_at: 2025-03-19T14:11:48Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a successful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN//<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
path: docs/api/authentication_policy.md
user: login: Katinka666
body: typo: i ~~n~~ dentity
created_at: 2025-03-19T14:14:06Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a successful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN//<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
+
+~~~
+SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"SYSTEM//temperature-consumer1",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### certificate-mqtt
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) where the [PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/#ftoc-heading-1) format of the certificate is expected as a [Base64](https://datatracker.ietf.org/doc/html/rfc4648#section-4) encoded string.
path: docs/api/authentication_policy.md
user: login: Katinka666
body: typo: i ~~n~~ dentity
created_at: 2025-03-19T14:17:45Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,146 @@
+# Authentication Policy
+
+During the interactions with the Arrowhead Core and Support systems, all clients are required to prove their identity by providing appropriate identity info. The authentication can be done based on the given identity info.
+
+Three authentication policies are offered: [declared](#declared), [certificate](#certificate) and [outsourced](#outsourced).
+
+The actual policy in force is depending on how the core and support systems are configured. See the `authentication.policy` configuration property under the [general configurations](../general/general_config_props.md).
+
+## Policies
+
+### declared
+
+Applying the **declared** authentication policy results in **no real identity verification taking place**. The core and supports systems simply accept the identity provided by the application systems. **This policy is not recommended for use in production environment.** 
+
+Applicable to [HTTP](#declared-http) and [MQTT](#declared-mqtt) interface protocols.
+
+### certificate
+
+Applying the **certificate** authentication policy results in requiring client side [system profile certifcate](../help/certificate-profiles.md/#system-profile) being provided by the application systems. The issuer and the identity related content of the certificate are always verified during every interaction with the Arrowhead Core and Support systems.
+
+Applicable to [HTTP](#certificate-http) and [MQTT](#certificate-mqtt) interface protocols.
+
+### outsourced
+
+Applying the **outsourced** authentication policy results in requiring the [identity service](../assets/sd/5_0_0/identity_sd.pdf) being provided by a core/support system within the Local Cloud. This dedicated system can be the offical [Authentication Core System](../core_systems/authentication.md) or any third party solution that implements this service.
+
+The actual credentials required to being authenticated and joining to the Local Cloud are always depending on the actual authentication method behind the identity service, but the outcome is always an identiy token (and optionally an expiration time) what the authenticated system is required to use to prove its own identity when interacting with the Arrowhead Core and Support systems. 
+
+**The interactions between the consumers and providers should never contain identity tokens in order to prevent any kind of identity theft. Identities should only be shared with the trusted Arrowhead Core and Support systems.**
+
+Applicable to [HTTP](#outsourced-http) and [MQTT](#outsourced-mqtt) interface protocols.
+
+## Usage
+
+### HTTP
+
+#### declared-http
+
+The [declared](#declared) indentity info is the unique system name itself that must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer SYSTEM//temperature-consumer1'
+~~~
+
+#### certificate-http
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be attached to the HTTPS request.
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'https://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  --cert my-cert.p12 --cert-type P12 --pass 123456
+~~~
+
+#### outsourced-http
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a successful authentication attempt. This token must be present in the [HTTP Authorization request header](https://datatracker.ietf.org/doc/html/rfc7235#section-4.2) according to the following scheme: 
+
+~~~
+Bearer IDENTITY-TOKEN//<token>
+~~~
+
+Example:
+
+~~~
+curl -X 'DELETE' \
+  'http://localhost:8443/serviceregistry/system-discovery/revoke' \
+  -H 'accept: */*' \
+  -H 'Authorization: Bearer IDENTITY-TOKEN//3d7b084d-1259-4a04-8789-880b7da3a530'
+~~~
+
+### MQTT
+
+#### declared-mqtt
+
+The [declared](#declared) indentiy info is the unique system name itself that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme: 
+
+~~~
+SYSTEM//<system-name>
+~~~
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"SYSTEM//temperature-consumer1",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### certificate-mqtt
+
+The [certificate](#certificate) indentity info is contained by the client certificate that must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) where the [PEM](https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/#ftoc-heading-1) format of the certificate is expected as a [Base64](https://datatracker.ietf.org/doc/html/rfc4648#section-4) encoded string.
+
+Example:
+
+~~~
+Topic: arrowhead/serviceregistry/system-discovery/revoke
+
+{
+   "traceId":"abc123",
+   "authentication":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0...",
+   "responseTopic":"my/response/topic",
+   "qosRequirement":2
+   
+}
+~~~
+
+#### outsourced-mqtt
+
+The [outsourced](#outsourced) indentity info is a string token generated by a dedicated core or support system and obtained as a result of a successful authentication attempt. This token must be present in the [authentication field of the MqttRequestTemplate](../api/data-models/mqtt-request-template.md) according to the following scheme:
path: docs/api/authentication_policy.md
user: login: Katinka666
body: - typo: i ~~n~~ dentity
- previously it was "Core or Support system" (with capitals)
created_at: 2025-03-19T14:19:40Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,15 @@
+# General Configuartion Properties
+
+The following cofiguration properties are applied by every core and support system:
path: docs/general/general_config_props.md
user: login: Katinka666
body: maybe rather Core and Support system (with capitals)
created_at: 2025-03-19T14:49:34Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,15 @@
+# General Configuartion Properties
+
+The following cofiguration properties are applied by every core and support system:
+
+:fontawesome-solid-wrench: **authentication.policy**
+
+Specifies the applied [authentication policy](../api/authentication_policy.md). Can be `declared`, `certificate` and `outsourced`. 
path: docs/general/general_config_props.md
user: login: Katinka666
body: `declared`, `certificate` **or** `outsourced`. 
created_at: 2025-03-19T14:49:57Z
author_association: COLLABORATOR

PR comments:
user: login: borditamas
created_at: 2025-03-10T21:50:43Z
body: **Remark**: It is so lame and confusing that the http header used for authentication is named as authorization. I know that this is a design flaw in http, but still...

Shouldn't we use a custom header for this purpose instead? Like `authentication` or  `identity-info`
author_association: COLLABORATOR
user: login: borditamas
created_at: 2025-03-10T22:20:14Z
body: Okay now I remember that we decided to go with the authorization header mainly because of Swagger. There is this built in `@SecurityScheme` feature which uses the authorization header.

But according to the clever ones we could add a global required custom header this ways:

```
@Configuration
public class OpenAPIConfig {

    @Bean
    public OpenAPI customOpenAPI() {
        return new OpenAPI()
            .info(new Info()
                .title("My API")
                .version("1.0")
                .description("API with global custom headers")
                .contact(new Contact().name("John Doe").email("john.doe@example.com")))
            .components(new Components()
                .addParameters("X-Custom-Header", new Parameter()
                    .in("header")
                    .name("X-Custom-Header")
                    .description("A global custom header for all requests")
                    .required(false)
                    .schema(new StringSchema())));
    }
}
```
author_association: COLLABORATOR
user: login: borditamas
created_at: 2025-03-10T23:16:15Z
body: Okay so the above mentioned code doesn't work but what is working is to change the [@SecurityScheme](https://github.com/Aitia-IIOT/ah5-common-java-spring/blob/7e797c99ce46b97b9160aa68c1212e2c8dbedcd1/common-utils/src/main/java/eu/arrowhead/common/swagger/DefaultSwaggerConfig.java#L13) annotation to this: 

```
@SecurityScheme(name = "Authentication", type = SecuritySchemeType.APIKEY, in = SecuritySchemeIn.HEADER, paramName = "Authentication" , description = "Header to include identity info")
```

With this change swagger works the same way as before but the header name will be "Authorization". And we can leave the "Bearer" out from now on if we want.
author_association: COLLABORATOR
user: login: borditamas
created_at: 2025-03-18T07:28:32Z
body: @rbocsi Thanks for the review. What is your opinion about the header topic?
author_association: COLLABORATOR
user: login: rbocsi
created_at: 2025-03-18T07:39:10Z
body: I don't like the custom header idea. For me, using a different header would be confusing. Technical concern:
https://stackoverflow.com/questions/42574022/custom-authorization-header/43164958#43164958 (first answer)
author_association: COLLABORATOR
user: login: borditamas
created_at: 2025-03-18T09:28:10Z
body: > I don't like the custom header idea. For me, using a different header would be confusing. Technical concern: https://stackoverflow.com/questions/42574022/custom-authorization-header/43164958#43164958 (first answer)

Alright, I'm convinced so far. This will probably need to be explained many times :D
author_association: COLLABORATOR