Arqit SKA-Platform SDKs Release v24.06

What’s new?

Policy update control

The rate at which client devices poll for new policies and settings can be controlled centrally via the console.

This feature is applied via a policy and can be applied to individual devices or groups via ‘Organisational Units’ on the 'Devices' page.

The feature is controlled by a policy type: ‘Default Device Behaviour Policy'.

After the period set in the policy, devices will poll the server to check if any settings have changed.

For implementation guidance, see the developer guide Partner Portal | SDK Downloads | Documentation.

For further information on managing policies and applying them to devices, see https://arqit-customer.atlassian.net/wiki/spaces/SKAP/pages/2916361/Tenant+Console+Admin+guide#Policies.

Automatic re-provisioning

In the event that a device is recovered via the administration console, applications are able to automatically re-provision and continue key negotiation without any manual intervention^1..

For implementation guidance, see the developer guide Partner Portal | SDK Downloads | Documentation.

Registration configuration

Devices can register a device to a specific Organisational Unit (OU) within the tenant by including the OU UID on registration.

The intention of this feature is to allow Commissioning engineers (within the consuming organisation) to subject the device (or groups of devices) to specific policy sets immediately upon registration, rather than the default policies, giving flexibility of control across the estate.

To do this, the Commissioning engineer would need to look up the UID of the desired OU via the admin console, before feeding it into the app instance prior to registration.

What’s changed?

• Completed deprecation of asynchronous methods of authentication and key negotiation in the C++ SDK.

• Updates to the Developer guide and readme files.

Bug fixes

• QCS-121 (SDKs) Fixed an issue whereby running the C++ example app more than once, would cause an ‘already provisioned’ error to be incorrectly displayed.

Known Issues

• QC-2901 (SDKs) Python SDK does not currently support Python v3.11.  Support will be added in a future release. SDK developers are advised to use v3.10 of Python in the interim.

• QCS-146 (SDKs) Users are unable to pass the deregister argument when using the C++ example apps.

• QCS-158 (SDKs) When peering via MQTT using the Python SDK, the receiver device UID value is replaced with the MQTT broker device UID.

Compatibility

Other SKA SDK versions

The core functions of apps built on these SDKs should work with applications incorporating any previous versions of the SDK since v23.07. SDKs are interoperable, i.e. apps built on the Python SDK should be able to negotiate keys with those built on the the Kotlin/Java SDK.

SKA(PI)™

Core functions will work against all SKA(PI) versions since v23.07. The new functions in this release will not work against the current supported SKA(PI) version (v24.02). SKA(PI) customers are recommended to upgrade to or remain on SDKs v24.02 until the next PI release (further guidance will follow when this version is cut and released).

SDK feature matrix (SDKs v24.06)

Some features are not yet available across the suite of SDKs, these are captured in the table below.

1. Devices based on older versions of the SDKs placed into this state will need to be manually re-provisioned. It is not advisable to place any such devices into this state unless there is a manual provisioning mechanism built in.

2. Registration configuration is in the C++ SDKs, but is not yet in the example applications.