Changes in descriptions and coments

code/API_definitions/geofencing-subscriptions.yaml

@@ -6,7 +6,7 @@ info:
 
     # Introduction
 
-    With this API, customers can create subscriptions for their devices to receive notifications when a device enters or exits a specified area.
+    With this API, API consumers can create subscriptions for their devices to receive notifications when a device enters or exits a specified area.
 
     The area provided in the request is described by a circle determined by coordinates (latitude and longitude) and an accuracy defined by the radius.
 
@@ -65,7 +65,7 @@ info:
 
     The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
 
-    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
+    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the API Provider, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
 
     It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
 

code/API_definitions/location-retrieval.yaml

@@ -6,12 +6,12 @@ info:
 
     # Introduction
 
-    With this API, customers can retrieve the area where a certain user device is localized.
+    With this API, API consumers can retrieve the area where a certain user device is localized.
     The area provided in the response could be described:
     -  by a circle determined by coordinates (latitude and longitude) and a radius.
     -  by a simple polygon delimited by segments connecting consecutively an array of coordinates (points). The last point connects to the first point to delimit a closed shape bounded with straight sides.
 
-    The retrieved shape depends on the network conditions at the subscriber's location and any of the supported shapes could be received.
+    The retrieved shape depends on the network conditions at the device's location and any of the supported shapes could be received.
 
     The requester could optionally ask for a freshness of the localization information by providing a `maxAge` ("I want a location not older than 600 seconds").
 
@@ -56,7 +56,7 @@ info:
 
     The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
 
-    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
+    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the API Provider, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
 
     It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
 

code/API_definitions/location-verification.yaml

@@ -2,11 +2,11 @@ openapi: 3.0.3
 info:
   title: Device Location Verification
   description: |
-    This API provides the customer with the ability to verify the location of a device.
+    This API provides the consumer with the ability to verify the location of a device.
 
     # Introduction
 
-    Customers are able to verify whether the location of certain user device is within the area specified. Currently the only area supported as input is a circle determined by a set of coordinates (latitude and longitude) and some expected accuracy (radius).
+    API consumers are able to verify whether the location of certain user device is within the area specified. Currently the only area supported as input is a circle determined by a set of coordinates (latitude and longitude) and some expected accuracy (radius).
 
     The verification result depends on the network's ability and accuracy to locate the device at the requested area.
 
@@ -49,7 +49,7 @@ info:
 
     The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
 
-    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
+    Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the API Provider, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
 
     It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
 

code/Test_definitions/location-retrieval.feature

@@ -9,7 +9,7 @@ Feature: CAMARA Device location retrieval  API, v0.3 - Operation retrieveLocatio
   # * A device object identifying a device commercialized by the implementation for which the service is not applicable
   # * A device object which location cannot be provided during test by the network.
   #
-  # References to OAS spec schemas refer to schemas specifies in location-retrieval.yaml, version 0.2.0
+  # References to OAS spec schemas refer to schemas specifies in location-retrieval.yaml
 
   Background: Common retrieveLocation setup
     Given the resource "/location-retrieval/v0.3/retrieve"                                                              |

code/Test_definitions/location-verification.feature

@@ -9,7 +9,7 @@ Feature: CAMARA Device location verification API, v1.0 - Operation verifyLocatio
   # * The known location of the testing devices
   # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any
   #
-  # References to OAS spec schemas refer to schemas specifies in location-verification.yaml, version 0.2.0
+  # References to OAS spec schemas refer to schemas specifies in location-verification.yaml
 
   Background: Common verifyLocation setup
     Given the resource "/location-verification/v1/verify"                                                              |