You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+128Lines changed: 128 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,6 @@
1
1
# Changelog DeviceStatus
2
2
## Table of Contents
3
+
-[r2.2](#r22)
3
4
-[r2.1](#r21)
4
5
-[r1.3](#r13)
5
6
-[r1.2](#r12)
@@ -19,6 +20,133 @@ The below sections record the changes for each API version in each release as fo
19
20
- for the first release-candidate, all changes since the last public release
20
21
- for subsequent release-candidate(s), only the delta to the previous release-candidate
21
22
- for a public release, the consolidated changes since the previous public release
23
+
# r2.2
24
+
## Release Notes
25
+
26
+
This public release contains the definition and documentation of
27
+
* device-roaming-status v1.0.0
28
+
* device-roaming-status-subscriptions v0.7.0
29
+
* device-reachability-status v1.0.0
30
+
* device-reachability-status-subscriptions v0.7.0
31
+
* connected-network-type 0.1.0
32
+
* connected-network-type-subscriptions 0.1.0
33
+
34
+
The API definition(s) are based on
35
+
* Commonalities v0.5.0
36
+
* Identity and Consent Management v0.3.0
37
+
38
+
## device-roaming-status v1.0.0
39
+
40
+
- API definition **with inline documentation**:
41
+
-[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)
42
+
-[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)
* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228
49
+
* Update device error model by @fernandopradocabrillo in https://github.com/camaraproject/DeviceStatus/pull/232
50
+
51
+
### Fixed
52
+
53
+
### Removed
54
+
55
+
## device-roaming-status-subscriptions v0.7.0
56
+
57
+
- API definition **with inline documentation**:
58
+
-[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)
59
+
-[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)
* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228
66
+
* Update documentation with clarification for initialEvent by @bigludo7 in https://github.com/camaraproject/DeviceStatus/pull/237
67
+
* Alignment with Commonalities Subscription Model - APIs Subscription by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/250
68
+
* Change event notification sink format from url to uri by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/260
69
+
70
+
### Fixed
71
+
* Fix example for SUBSCRIPTION_ACTIVE by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/231
72
+
* Fix dateTime literals by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/240
73
+
74
+
### Removed
75
+
* remove `allOf` in `sinkCredential` by @dfischer-tech in https://github.com/camaraproject/DeviceStatus/pull/226
76
+
77
+
## device-reachability-status v1.0.0
78
+
79
+
- API definition **with inline documentation**:
80
+
-[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)
81
+
-[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)
* rework reachability-status to support reachability with multiple connectivity-types by @maxl2287 in https://github.com/camaraproject/DeviceStatus/pull/221
88
+
* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228
89
+
* Update device error model by @fernandopradocabrillo in https://github.com/camaraproject/DeviceStatus/pull/232
-[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)
99
+
-[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)
* Update documentation with handling of access token and multi-SIM scenarios by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/228
106
+
* Update documentation with clarification for initialEvent by @bigludo7 in https://github.com/camaraproject/DeviceStatus/pull/237
107
+
* Alignment with Commonalities Subscription Model - APIs Subscription by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/250
108
+
* Change event notification sink format from url to uri by @eric-murray in https://github.com/camaraproject/DeviceStatus/pull/260
109
+
110
+
### Fixed
111
+
* Fix example for SUBSCRIPTION_ACTIVE by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/231
112
+
* Fix dateTime literals by @sachinvodafone in https://github.com/camaraproject/DeviceStatus/pull/240
113
+
114
+
### Removed
115
+
* remove `allOf` in `sinkCredential` by @dfischer-tech in https://github.com/camaraproject/DeviceStatus/pull/226
116
+
117
+
## connected-network-type v0.1.0
118
+
119
+
- API definition **with inline documentation**:
120
+
-[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)
121
+
-[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)
* Create connected-network-type.yaml by @gmuratk in https://github.com/camaraproject/DeviceStatus/pull/158
126
+
127
+
### Changed
128
+
129
+
### Fixed
130
+
131
+
### Removed
132
+
133
+
## connected-network-type-subscriptions v0.1.0
134
+
135
+
- API definition **with inline documentation**:
136
+
-[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)
137
+
-[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)
<ahref="https://github.com/camaraproject/Governance/blob/main/ProjectStructureAndRoles.md"title="Incubating API Repository"><imgsrc="https://img.shields.io/badge/Incubating%20API%20Repository-green?style=plastic"></a>
8
9
9
10
# DeviceStatus
10
-
Repository to describe, develop, document and test the DeviceStatus APIs
11
+
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)
12
+
13
+
* API Repository wiki page: https://lf-camaraproject.atlassian.net/wiki/x/AgDe
14
+
* Sub Project home page: https://lf-camaraproject.atlassian.net/wiki/x/fzLe
11
15
12
16
## Scope
13
17
* Service APIs for “Device Status” (see [APIBacklog.md](https://github.com/camaraproject/APIBacklog/blob/main/documentation/APIbacklog.md))
14
18
* It provides the API consumer with the ability to:
15
19
- check if a device is reachable or is not connected to the network
16
20
- check if a device is roaming, and in which country
17
21
- receive notifications if the connectivity or roaming status of the device changes
18
-
* Describe, develop, document and test the APIs (with 1-2 Telcos)
19
-
* Started: July 2022
22
+
* Describe, develop, document and test the APIs (with 1-2 Telcos)
Copy file name to clipboardExpand all lines: code/API_definitions/connected-network-type-subscriptions.yaml
+7-6Lines changed: 7 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -67,11 +67,12 @@ info:
67
67
# Further info and support
68
68
69
69
## Authorization and authentication
70
-
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.
71
70
72
-
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.
71
+
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.
73
72
74
-
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.
73
+
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.
74
+
75
+
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.
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).
696
+
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).
Copy file name to clipboardExpand all lines: code/API_definitions/connected-network-type.yaml
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ info:
51
51
52
52
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.
53
53
54
-
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.
54
+
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.
55
55
56
56
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.
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).
789
+
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).
Copy file name to clipboardExpand all lines: code/API_definitions/device-reachability-status.yaml
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ info:
47
47
48
48
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.
49
49
50
-
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.
50
+
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.
51
51
52
52
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.
0 commit comments