diff --git a/CHANGELOG.md b/CHANGELOG.md index 99c55f22..8dec8221 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,6 @@ # Changelog DeviceStatus ## Table of Contents +- [r2.2](#r22) - [r2.1](#r21) - [r1.3](#r13) - [r1.2](#r12) @@ -19,6 +20,133 @@ The below sections record the changes for each API version in each release as fo - for the first release-candidate, all changes since the last public release - for subsequent release-candidate(s), only the delta to the previous release-candidate - for a public release, the consolidated changes since the previous public release +# r2.2 +## Release Notes + +This public release contains the definition and documentation of +* device-roaming-status v1.0.0 +* device-roaming-status-subscriptions v0.7.0 +* device-reachability-status v1.0.0 +* device-reachability-status-subscriptions v0.7.0 +* connected-network-type 0.1.0 +* connected-network-type-subscriptions 0.1.0 + +The API definition(s) are based on +* Commonalities v0.5.0 +* Identity and Consent Management v0.3.0 + +## device-roaming-status v1.0.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-roaming-status.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-roaming-status.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/device-roaming-status.yaml) + +### Added + +### Changed +* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228 +* Update device error model by @fernandopradocabrillo in https://github.com/camaraproject/DeviceStatus/pull/232 + +### Fixed + +### Removed + +## device-roaming-status-subscriptions v0.7.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-roaming-status-subscriptions.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-roaming-status-subscriptions.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/device-roaming-status-subscriptions.yaml) + +### Added + +### Changed +* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228 +* Update documentation with clarification for initialEvent by @bigludo7 in https://github.com/camaraproject/DeviceStatus/pull/237 +* Alignment with Commonalities Subscription Model - APIs Subscription by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/250 +* Change event notification sink format from url to uri by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/260 + +### Fixed +* Fix example for SUBSCRIPTION_ACTIVE by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/231 +* Fix dateTime literals by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/240 + +### Removed +* remove `allOf` in `sinkCredential` by @dfischer-tech in https://github.com/camaraproject/DeviceStatus/pull/226 + +## device-reachability-status v1.0.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-reachability-status.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-reachability-status.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/device-reachability-status.yaml) + +### Added + +### Changed +* rework reachability-status to support reachability with multiple connectivity-types by @maxl2287 in https://github.com/camaraproject/DeviceStatus/pull/221 +* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228 +* Update device error model by @fernandopradocabrillo in https://github.com/camaraproject/DeviceStatus/pull/232 + +### Fixed + +### Removed + +## device-reachability-status-subscriptions v0.7.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-reachability-status-subscriptions.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/device-reachability-status-subscriptions.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/device-reachability-status-subscriptions.yaml) + +### Added + +### Changed +* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228 +* Update documentation with clarification for initialEvent by @bigludo7 in https://github.com/camaraproject/DeviceStatus/pull/237 +* Alignment with Commonalities Subscription Model - APIs Subscription by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/250 +* Change event notification sink format from url to uri by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/260 + +### Fixed +* Fix example for SUBSCRIPTION_ACTIVE by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/231 +* Fix dateTime literals by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/240 + +### Removed +* remove `allOf` in `sinkCredential` by @dfischer-tech in https://github.com/camaraproject/DeviceStatus/pull/226 + +## connected-network-type v0.1.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/connected-network-type.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/connected-network-type.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/connected-network-type.yaml) + +### Added +* Create connected-network-type.yaml by @gmuratk in https://github.com/camaraproject/DeviceStatus/pull/158 + +### Changed + +### Fixed + +### Removed + +## connected-network-type-subscriptions v0.1.0 + +- API definition **with inline documentation**: + - [View it on ReDoc](https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/connected-network-type-subscriptions.yaml&nocors) + - [View it on Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/DeviceStatus/r2.2/code/API_definitions/connected-network-type-subscriptions.yaml) + - OpenAPI [YAML spec file](https://github.com/camaraproject/DeviceStatus/blob/r2.2/code/API_definitions/connected-network-type-subscriptions.yaml) + +### Added +* Create connected-network-type-subscriptions.yaml by @VijayKesharwani in https://github.com/camaraproject/DeviceStatus/pull/171 + +### Changed + +### Fixed + +### Removed + +**Full Changelog**: https://github.com/camaraproject/DeviceStatus/compare/r1.3...r2.2 # r2.1 ## Release Notes diff --git a/README.md b/README.md index bdc08c84..52a3cba0 100644 --- a/README.md +++ b/README.md @@ -5,9 +5,13 @@ + # DeviceStatus -Repository to describe, develop, document and test the DeviceStatus APIs +Incubating API Repository to evolve and maintain the definitions and documentation of DeviceStatus Service API(s) within the Sub Project [Device Status](https://lf-camaraproject.atlassian.net/wiki/x/6wApBQ) + +* API Repository wiki page: https://lf-camaraproject.atlassian.net/wiki/x/AgDe +* Sub Project home page: https://lf-camaraproject.atlassian.net/wiki/x/fzLe ## Scope * Service APIs for “Device Status” (see [APIBacklog.md](https://github.com/camaraproject/APIBacklog/blob/main/documentation/APIbacklog.md)) @@ -15,8 +19,9 @@ Repository to describe, develop, document and test the DeviceStatus APIs - check if a device is reachable or is not connected to the network - check if a device is roaming, and in which country - receive notifications if the connectivity or roaming status of the device changes -* Describe, develop, document and test the APIs (with 1-2 Telcos) -* Started: July 2022 +* Describe, develop, document and test the APIs (with 1-2 Telcos) +* Started: July 2022 +* Incubating stage since: February 2025 ## Release Information diff --git a/code/API_definitions/connected-network-type-subscriptions.yaml b/code/API_definitions/connected-network-type-subscriptions.yaml index d300f008..201de1eb 100644 --- a/code/API_definitions/connected-network-type-subscriptions.yaml +++ b/code/API_definitions/connected-network-type-subscriptions.yaml @@ -67,11 +67,12 @@ info: # Further info and support ## Authorization and authentication - 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 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. + The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. - 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. + The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. + + In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. ## Identifying the device from the access token @@ -102,14 +103,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 0.1.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at Camara url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/connected-network-type-subscriptions/vwip" + - url: "{apiRoot}/connected-network-type-subscriptions/v0.1" variables: apiRoot: default: http://localhost:9091 @@ -670,7 +671,7 @@ components: SubscriptionId: type: string - description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#122-event-notification). + description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/r2.3/documentation/API-design-guidelines.md#122-event-notification). example: qs15-h556-rt89-1298 Device: diff --git a/code/API_definitions/connected-network-type.yaml b/code/API_definitions/connected-network-type.yaml index 0bbb59bd..43ea6866 100644 --- a/code/API_definitions/connected-network-type.yaml +++ b/code/API_definitions/connected-network-type.yaml @@ -51,7 +51,7 @@ info: The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. - The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the provider of the application consuming the API and the operator's API exposure platform, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. + The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. @@ -73,14 +73,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 0.1.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/connected-network-type/vwip" + - url: "{apiRoot}/connected-network-type/v0.1" variables: apiRoot: default: http://localhost:9091 diff --git a/code/API_definitions/device-reachability-status-subscriptions.yaml b/code/API_definitions/device-reachability-status-subscriptions.yaml index d1812d52..144dc3d4 100644 --- a/code/API_definitions/device-reachability-status-subscriptions.yaml +++ b/code/API_definitions/device-reachability-status-subscriptions.yaml @@ -111,14 +111,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 0.7.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/device-reachability-status-subscriptions/vwip" + - url: "{apiRoot}/device-reachability-status-subscriptions/v0.7" variables: apiRoot: default: http://localhost:9091 @@ -764,7 +764,7 @@ components: SubscriptionId: type: string - description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#122-event-notification). + description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/r2.3/documentation/API-design-guidelines.md#122-event-notification). example: qs15-h556-rt89-1298 CloudEvent: diff --git a/code/API_definitions/device-reachability-status.yaml b/code/API_definitions/device-reachability-status.yaml index 24cf17d8..0e489210 100644 --- a/code/API_definitions/device-reachability-status.yaml +++ b/code/API_definitions/device-reachability-status.yaml @@ -47,7 +47,7 @@ info: The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. - The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the provider of the application consuming the API and the operator's API exposure platform, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. + The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. @@ -70,14 +70,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 1.0.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/device-reachability-status/vwip" + - url: "{apiRoot}/device-reachability-status/v1" variables: apiRoot: default: http://localhost:9091 diff --git a/code/API_definitions/device-roaming-status-subscriptions.yaml b/code/API_definitions/device-roaming-status-subscriptions.yaml index 0ed6e436..df34b924 100644 --- a/code/API_definitions/device-roaming-status-subscriptions.yaml +++ b/code/API_definitions/device-roaming-status-subscriptions.yaml @@ -96,11 +96,11 @@ info: ## Authorization and authentication - 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. + The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity 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. + The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst 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. + In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. ## Identifying the device from the access token @@ -131,14 +131,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 0.7.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/device-roaming-status-subscriptions/vwip" + - url: "{apiRoot}/device-roaming-status-subscriptions/v0.7" variables: apiRoot: default: http://localhost:9091 @@ -821,7 +821,7 @@ components: SubscriptionId: type: string - description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#122-event-notification). + description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](https://github.com/camaraproject/Commonalities/blob/r2.3/documentation/API-design-guidelines.md#122-event-notification). example: qs15-h556-rt89-1298 CloudEvent: diff --git a/code/API_definitions/device-roaming-status.yaml b/code/API_definitions/device-roaming-status.yaml index 62c783a7..7a0153d2 100644 --- a/code/API_definitions/device-roaming-status.yaml +++ b/code/API_definitions/device-roaming-status.yaml @@ -55,7 +55,7 @@ info: The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile. - The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the provider of the application consuming the API and the operator's API exposure platform, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. + The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation. In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design. @@ -78,14 +78,14 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: 1.0.0 x-camara-commonalities: 0.5 externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/DeviceStatus servers: - - url: "{apiRoot}/device-roaming-status/vwip" + - url: "{apiRoot}/device-roaming-status/v1" variables: apiRoot: default: http://localhost:9091 diff --git a/code/Test_definitions/connected-network-type-subscriptions.feature b/code/Test_definitions/connected-network-type-subscriptions.feature index 251233b9..bc183aca 100644 --- a/code/Test_definitions/connected-network-type-subscriptions.feature +++ b/code/Test_definitions/connected-network-type-subscriptions.feature @@ -1,5 +1,5 @@ @Connected_Network_Type_Subscription -Feature: CAMARA Connected Network Type Subscriptions API, vwip - Operations createConnectedNetworkTypeSubscription, retrieveConnectedNetworkTypeSubscriptionList, retrieveConnectedNetworkTypeSubscription and deleteConnectedNetworkTypeSubscription +Feature: CAMARA Connected Network Type Subscriptions API, v0.1.0 - Operations createConnectedNetworkTypeSubscription, retrieveConnectedNetworkTypeSubscriptionList, retrieveConnectedNetworkTypeSubscription and deleteConnectedNetworkTypeSubscription # Input to be provided by the implementation to the tester # @@ -15,7 +15,7 @@ Feature: CAMARA Connected Network Type Subscriptions API, vwip - Operations crea # References to OAS spec schemas refer to schemas specifies in connected-network-type-subscriptions.yaml Background: Connected Network Type Subscriptions setup - Given the resource "{apiroot}/connected-network-type-subscriptions/vwip" as base-url + Given the resource "{apiroot}/connected-network-type-subscriptions/v0.1" as base-url And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/connected-network-type.feature b/code/Test_definitions/connected-network-type.feature index 10a8d35a..e149a3cf 100644 --- a/code/Test_definitions/connected-network-type.feature +++ b/code/Test_definitions/connected-network-type.feature @@ -1,5 +1,5 @@ @Connected_Network_Type -Feature: CAMARA Connected Network Type API, vwip - Operation getConnectedNetworkType +Feature: CAMARA Connected Network Type API, v0.1.0 - Operation getConnectedNetworkType # Input to be provided by the implementation to the tester # # Implementation indications: @@ -13,7 +13,7 @@ Feature: CAMARA Connected Network Type API, vwip - Operation getConnectedNetwork # References to OAS spec schemas refer to schemas specifies in connected-network-type.yaml Background: Common Connected Network Type setup - Given the resource "{api-root}/connected-network-type/vwip/retrieve" set as base-url + Given the resource "{api-root}/connected-network-type/v0.1/retrieve" set as base-url And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/device-reachability-status-subscriptions.feature b/code/Test_definitions/device-reachability-status-subscriptions.feature index f8af2e0a..ffa28c26 100644 --- a/code/Test_definitions/device-reachability-status-subscriptions.feature +++ b/code/Test_definitions/device-reachability-status-subscriptions.feature @@ -1,5 +1,5 @@ @Device_Reachability_Status_Subscription -Feature: Device Reachability Status Subscriptions API, vwip - Operations createDeviceReachabilityStatusSubscription, retrieveDeviceReachabilityStatusSubscriptionList, retrieveDeviceReachabilityStatusSubscription and deleteDeviceReachabilityStatusSubscription +Feature: Device Reachability Status Subscriptions API, v0.7.0 - Operations createDeviceReachabilityStatusSubscription, retrieveDeviceReachabilityStatusSubscriptionList, retrieveDeviceReachabilityStatusSubscription and deleteDeviceReachabilityStatusSubscription # Input to be provided by the implementation to the tester # @@ -15,7 +15,7 @@ Feature: Device Reachability Status Subscriptions API, vwip - Operations createD # References to OAS spec schemas refer to schemas specifies in device-reachability-status-subscriptions.yaml Background: Common Device Reachability Status Subscriptions setup - Given the resource "{apiroot}/device-reachability-status-subscriptions/vwip" as base-url + Given the resource "{apiroot}/device-reachability-status-subscriptions/v0.7" as base-url And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/device-reachability-status.feature b/code/Test_definitions/device-reachability-status.feature index fb1620e6..77192bb4 100644 --- a/code/Test_definitions/device-reachability-status.feature +++ b/code/Test_definitions/device-reachability-status.feature @@ -1,5 +1,5 @@ @Device_Reachability_Status -Feature: CAMARA Device reachability status API, vwip - Operation getReachabilityStatus +Feature: CAMARA Device reachability status API, v1.0.0 - Operation getReachabilityStatus # Input to be provided by the implementation to the tester # # Implementation indications: @@ -12,7 +12,7 @@ Feature: CAMARA Device reachability status API, vwip - Operation getReachability # References to OAS spec schemas refer to schemas specifies in device-reachability-status.yaml Background: Common getReachabilityStatus setup - Given the resource "{api-root}/device-reachability-status/vwip/retrieve" set as base-url + Given the resource "{api-root}/device-reachability-status/v1/retrieve" set as base-url And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/device-roaming-status-subscriptions.feature b/code/Test_definitions/device-roaming-status-subscriptions.feature index 79595184..545e15cf 100644 --- a/code/Test_definitions/device-roaming-status-subscriptions.feature +++ b/code/Test_definitions/device-roaming-status-subscriptions.feature @@ -1,5 +1,5 @@ @Device_Status_Roaming_Subscription -Feature: Device Roaming Status Subscriptions API, vwip - Operations createDeviceRoamingStatusSubscription, retrieveDeviceRoamingStatusSubscriptionList, retrieveDeviceRoamingStatusSubscription and deleteDeviceRoamingStatusSubscription +Feature: Device Roaming Status Subscriptions API, v0.7.0 - Operations createDeviceRoamingStatusSubscription, retrieveDeviceRoamingStatusSubscriptionList, retrieveDeviceRoamingStatusSubscription and deleteDeviceRoamingStatusSubscription # Input to be provided by the implementation to the tester # @@ -14,7 +14,7 @@ Feature: Device Roaming Status Subscriptions API, vwip - Operations createDevice # References to OAS spec schemas refer to schemas specified in device-roaming-status-subscriptions.yaml Background: Common Device Roaming Status Subscriptions setup - Given the resource "{apiroot}/device-roaming-status-subscriptions/vwip" as base-url + Given the resource "{apiroot}/device-roaming-status-subscriptions/v0.7" as base-url And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/device-roaming-status.feature b/code/Test_definitions/device-roaming-status.feature index 5b9ebb92..176493f7 100644 --- a/code/Test_definitions/device-roaming-status.feature +++ b/code/Test_definitions/device-roaming-status.feature @@ -1,5 +1,5 @@ @Device_Roaming_Status -Feature: CAMARA Device Roaming Status API, vwip - Operation getRoamingStatus +Feature: CAMARA Device Roaming Status API, v1.0.0 - Operation getRoamingStatus # Input to be provided by the implementation to the tester # # Implementation indications: @@ -12,7 +12,7 @@ Feature: CAMARA Device Roaming Status API, vwip - Operation getRoamingStatus # References to OAS spec schemas refer to schemas specifies in device-roaming-status.yaml Background: Common getRoamingStatus setup - Given the resource "{api-root}/device-roaming-status/vwip/retrieve" set as base-url + Given the resource "{api-root}/device-roaming-status/v1/retrieve" set as base-url And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/documentation/API_documentation/connected-network-type-API-Readiness-Checklist.md b/documentation/API_documentation/connected-network-type-API-Readiness-Checklist.md index ce965d56..d1779626 100644 --- a/documentation/API_documentation/connected-network-type-API-Readiness-Checklist.md +++ b/documentation/API_documentation/connected-network-type-API-Readiness-Checklist.md @@ -1,20 +1,20 @@ # API Readiness Checklist -Checklist for connected-network-type 0.1.0-rc.1 in r2.1. +Checklist for connected-network-type 0.1.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/connected-network-type.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/connected-network-type.yaml](/code/API_definitions/connected-network-type.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | | 6 | User stories | O | O | O | M | N | | -| 7 | Basic API test cases & documentation | O | M | M | M | N | /code/Test_definitions/connected-network-type.feature | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/connected-network-type.feature](/code/Test_definitions/connected-network-type.feature) | | 8 | Enhanced API test cases & documentation | O | O | O | M | N | | | 9 | Test result statement | O | O | O | M | N | | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | | 12 | Previous public release was certified | O | O | O | M | N | | Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_documentation/connected-network-type-subscriptions-API-Readiness-Checklist.md b/documentation/API_documentation/connected-network-type-subscriptions-API-Readiness-Checklist.md index 4db363d9..7941985f 100644 --- a/documentation/API_documentation/connected-network-type-subscriptions-API-Readiness-Checklist.md +++ b/documentation/API_documentation/connected-network-type-subscriptions-API-Readiness-Checklist.md @@ -1,20 +1,20 @@ # API Readiness Checklist -Checklist for connected-network-type-subscriptions 0.1.0-rc.1 in r2.1. +Checklist for connected-network-type-subscriptions 0.1.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/connected-network-type-subscriptions.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/connected-network-type-subscriptions.yaml](/code/API_definitions/connected-network-type-subscriptions.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | | 6 | User stories | O | O | O | M | N | | -| 7 | Basic API test cases & documentation | O | M | M | M | N | /code/Test_definitions/connected-network-type-subscriptions.feature | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/connected-network-type-subscriptions.feature](/code/Test_definitions/connected-network-type-subscriptions.feature) | | 8 | Enhanced API test cases & documentation | O | O | O | M | N | | | 9 | Test result statement | O | O | O | M | N | | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | | 12 | Previous public release was certified | O | O | O | M | N | | Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_documentation/device-reachability-status-API-Readiness-Checklist.md b/documentation/API_documentation/device-reachability-status-API-Readiness-Checklist.md index b66d0f7b..48efe460 100644 --- a/documentation/API_documentation/device-reachability-status-API-Readiness-Checklist.md +++ b/documentation/API_documentation/device-reachability-status-API-Readiness-Checklist.md @@ -1,22 +1,23 @@ # API Readiness Checklist -Checklist for device-reachability-status 1.0.0-rc.1 in r2.1. +Checklist for device-reachability-status 1.0.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/device-reachability-status.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/device-reachability-status.yaml](/code/API_definitions/device-reachability-status.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | -| 6 | User stories | O | O | O | M | N | In progress, will be merged after RC1 | -| 7 | Basic API test cases & documentation | O | M | M | M | Y | /code/Test_definitions/device-reachability-status.feature | -| 8 | Enhanced API test cases & documentation | O | O | O | M | N | In progress, will be merged after RC1 | -| 9 | Test result statement | O | O | O | M | N | In progress, will be merged after RC1 | +| 6 | User stories | O | O | O | M | Y | [/documentation/API_documentation/device-reachability-status-User-Story.md](/documentation/API_documentation/device-reachability-status-User-Story.md) | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/device-reachability-status.feature](/code/Test_definitions/device-reachability-status.feature) | +| 8 | Enhanced API test cases & documentation | O | O | O | M | Y | [/code/Test_definitions/device-reachability-status.feature](/code/Test_definitions/device-reachability-status.feature) | +| 9 | Test result statement | O | O | O | M | Y | [see issue #258](https://github.com/camaraproject/DeviceStatus/issues/258) | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | -| 12 | Previous public release was certified | O | O | O | M | Y | | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | +| 12 | Previous public release was certified | O | O | O | M | Y | see (1) | +(1) GSMA certified implementations of previous version by multiple operators (source: https://open-gateway.gsma.com/map as of 2025-03-11) Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_documentation/device-reachability-status-User-Story.md b/documentation/API_documentation/device-reachability-status-User-Story.md new file mode 100644 index 00000000..758aff37 --- /dev/null +++ b/documentation/API_documentation/device-reachability-status-User-Story.md @@ -0,0 +1,20 @@ +# Device Reachability Status User Story + +| Item | Description | Support Qualifier | +|---------------------------|-------------|-------------------| +| Summary | As an enterprise application developer, I want to query the reachability status of a user's device, so that I can determine whether the device is reachable via SMS, data (mobile internet), or both, enabling better communication or service management decisions based on real-time device availability. | M | +| Roles, Actor(s) and scope | **Roles:** Customer:Developer
**Actors:** Application service providers (ASP), hyperscalers, application developers.
**Scope:** Order To Activate (OTA) - Get connectivity status of a device | M | +| NF Requirements | - | O | +| Pre-conditions | - The customer:developer has been successfully onboarded to the API platform of the service provider
- The customer application has requested and received an access token with the required scope for the API | M | +| Begins when | The customer application server makes a POST request to retrieve the reachability status of a user's device | M | +| Ends when | The service provider returns the reachability status of the device with a timestamp when the status information was updated. In case of the device is reachable, additionally, the type of the connectivity (data, sms or both) is returned as well. | | +| Post-conditions | - | M | +| Exceptions | Several exceptions might occur during the API operations:
- Unauthorized: Invalid credentials (e.g., expired access token).
- Incorrect input data (e.g., malformed phone number).
- Not found: The phone number is not associated with a CSP customer account | M | + +# Linking a user story to API design + +Once we have the user story, the next step is to clarify the **data journey** in the context of the target and source systems we are integrating: +- Think about triggers for workflows: how and when does data need to be moved between the application and the service? +- Think about dependencies of data objects: does the data in underlying objects need to be regularly kept in sync with another system? +- Think about any parameters the user might need to configure or change. This is particularly important when building self-serve integrations for non-technical end users. +- Think about privacy by design: does any data represent sensitive information, and how can this be safely shared/stored according to regulation (e.g., anonymisation, tokenisation, zero-trust principles) diff --git a/documentation/API_documentation/device-reachability-status-subscriptions-API-Readiness-Checklist.md b/documentation/API_documentation/device-reachability-status-subscriptions-API-Readiness-Checklist.md index af51fe48..afbe8302 100644 --- a/documentation/API_documentation/device-reachability-status-subscriptions-API-Readiness-Checklist.md +++ b/documentation/API_documentation/device-reachability-status-subscriptions-API-Readiness-Checklist.md @@ -1,20 +1,20 @@ # API Readiness Checklist -Checklist for device-reachability-status-subscriptions 0.7.0-rc.1 in r2.1. +Checklist for device-reachability-status-subscriptions 0.7.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/device-reachability-status-subscriptions.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/device-reachability-status-subscriptions.yaml](/code/API_definitions/device-reachability-status-subscriptions.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | | 6 | User stories | O | O | O | M | N | | -| 7 | Basic API test cases & documentation | O | M | M | M | Y | /code/Test_definitions/device-reachability-status-subscriptions.feature | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/device-reachability-status-subscriptions.feature](/code/Test_definitions/device-reachability-status-subscriptions.feature) | | 8 | Enhanced API test cases & documentation | O | O | O | M | N | | | 9 | Test result statement | O | O | O | M | N | | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | | 12 | Previous public release was certified | O | O | O | M | N | | Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_documentation/device-roaming-status-API-Readiness-Checklist.md b/documentation/API_documentation/device-roaming-status-API-Readiness-Checklist.md index 87210291..db31fcd7 100644 --- a/documentation/API_documentation/device-roaming-status-API-Readiness-Checklist.md +++ b/documentation/API_documentation/device-roaming-status-API-Readiness-Checklist.md @@ -1,21 +1,23 @@ # API Readiness Checklist -Checklist for device-roaming-status 1.0.0-rc.1 in r2.1. +Checklist for device-roaming-status 1.0.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/device-roaming-status.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/device-roaming-status.yaml](/code/API_definitions/device-roaming-status.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | -| 6 | User stories | O | O | O | M | N | In progress, will be merged after RC1 | -| 7 | Basic API test cases & documentation | O | M | M | M | Y | /code/Test_definitions/device-roaming-status.feature | -| 8 | Enhanced API test cases & documentation | O | O | O | M | N | In progress, will be merged after RC1 | -| 9 | Test result statement | O | O | O | M | N | In progress, will be merged after RC1 | +| 6 | User stories | O | O | O | M | Y | [/documentation/API_documentation/device-roaming-status-User-Story.md](/documentation/API_documentation/device-roaming-status-User-Story.md) | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/device-roaming-status.feature](/code/Test_definitions/device-roaming-status.feature) | +| 8 | Enhanced API test cases & documentation | O | O | O | M | Y | [/code/Test_definitions/device-roaming-status.feature](/code/Test_definitions/device-roaming-status.feature) | +| 9 | Test result statement | O | O | O | M | Y | [see issue #258](https://github.com/camaraproject/DeviceStatus/issues/258) | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | -| 12 | Previous public release was certified | O | O | O | M | Y | | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | +| 12 | Previous public release was certified | O | O | O | M | Y | see (1) | + +(1) GSMA certified implementations of previous version by multiple operators (source: https://open-gateway.gsma.com/map as of 2025-03-11) Note: the checklists of a public API version and of its preceding release-candidate API version can be the same. diff --git a/documentation/API_documentation/device-roaming-status-User-Story.md b/documentation/API_documentation/device-roaming-status-User-Story.md new file mode 100644 index 00000000..f3c0c1c7 --- /dev/null +++ b/documentation/API_documentation/device-roaming-status-User-Story.md @@ -0,0 +1,21 @@ +# Device Roaming Status User Story + +| Item | Description | Support Qualifier | +|---------------------------|-------------|-------------------| +| Summary | As an enterprise application developer, I want to query the roaming status of a user's device, so that I can determine whether a device is in a foreign network and in which country it is located. This API can be used to identify fraud, ensure regulatory compliance, or enforce territorial restrictions on video and audio content. | M | +| Roles, Actor(s) and scope | **Roles:** Customer:Developer
**Actors:** Application service providers (ASP), hyperscalers, application developers.
**Scope:** Order To Activate (OTA) - Get roaming status of a device | M | +| NF Requirements | - | O | +| Pre-conditions | - The customer:developer has been successfully onboarded to the API platform of the service provider
- The customer application has requested and received an access token with the required scope for the API | M | +| Begins when | The customer application server makes a POST request to retrieve the roaming status of a user's device | M | +| Ends when | The service provider returns the roaming status of the device with a timestamp when the status information was updated. In case of a roaming situation also the roaming country name and code shall be returned. | | +| Post-conditions | - | M | +| Exceptions | Several exceptions might occur during the API operations:
- Unauthorized: Invalid credentials (e.g., expired access token).
- Incorrect input data (e.g., malformed phone number).
- Not found: The phone number is not associated with a CSP customer account | M | + +# Linking a user story to API design + +Once we have the user story, the next step is to clarify the **data journey** in the context of the target and source systems we are integrating: +- Think about triggers for workflows: how and when does data need to be moved between the application and the service? +- Think about dependencies of data objects: does the data in underlying objects need to be regularly kept in sync with another system? +- Think about any parameters the user might need to configure or change. This is particularly important when building self-serve integrations for non-technical end users. +- Think about privacy by design: does any data represent sensitive information, and how can this be safely shared/stored according to regulation (e.g., anonymisation, tokenisation, zero-trust principles) + diff --git a/documentation/API_documentation/device-roaming-status-subscriptions-API-Readiness-Checklist.md b/documentation/API_documentation/device-roaming-status-subscriptions-API-Readiness-Checklist.md index 12159d6e..853d62e4 100644 --- a/documentation/API_documentation/device-roaming-status-subscriptions-API-Readiness-Checklist.md +++ b/documentation/API_documentation/device-roaming-status-subscriptions-API-Readiness-Checklist.md @@ -1,20 +1,20 @@ # API Readiness Checklist -Checklist for device-roaming-status-subscriptions 0.7.0-rc.1 in r2.1. +Checklist for device-roaming-status-subscriptions 0.7.0 in r2.2. | Nr | API release assets | alpha | release-candidate | initial
public | stable
public | Status | Reference information | |----|----------------------------------------------|:-----:|:-----------------:|:-------:|:------:|:----:|:----:| -| 1 | API definition | M | M | M | M | Y | /code/API_definitions/device-roaming-status-subscriptions.yaml | -| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | r2.2 | -| 3 | Guidelines from ICM applied | O | M | M | M | Y | r2.2 | +| 1 | API definition | M | M | M | M | Y | [/code/API_definitions/device-roaming-status-subscriptions.yaml](/code/API_definitions/device-roaming-status-subscriptions.yaml) | +| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/Commonalities/releases/tag/r2.3) | +| 3 | Guidelines from ICM applied | O | M | M | M | Y | [r2.3](https://github.com/camaraproject/IdentityAndConsentManagement/releases/tag/r2.3) | | 4 | API versioning convention applied | M | M | M | M | Y | | | 5 | API documentation | M | M | M | M | Y | inline in YAML | | 6 | User stories | O | O | O | M | N | | -| 7 | Basic API test cases & documentation | O | M | M | M | Y | /code/Test_definitions/device-roaming-status-subscriptions.feature | +| 7 | Basic API test cases & documentation | O | M | M | M | Y | [/code/Test_definitions/device-roaming-status-subscriptions.feature](/code/Test_definitions/device-roaming-status-subscriptions.feature) | | 8 | Enhanced API test cases & documentation | O | O | O | M | N | | | 9 | Test result statement | O | O | O | M | N | | | 10 | API release numbering convention applied | M | M | M | M | Y | | -| 11 | Change log updated | M | M | M | M | Y | /CHANGELOG.md | +| 11 | Change log updated | M | M | M | M | Y | [/CHANGELOG.md](/CHANGELOG.md) | | 12 | Previous public release was certified | O | O | O | M | N | | Note: the checklists of a public API version and of its preceding release-candidate API version can be the same.