DeviceSecret key is required by protocol v2.0

[qsdigor]

Field deviceSecret is required from protocol version 2.0 or even 1.2 but it was not implemented so far.

As we implement protocol 2.0 various tests have failed indicating deviceSecret key is missing.

In Java SDK, deviceSecret is present in LocalDevice class which is part of the Android build.
As deviceSecret is required by API, tests fail in the core library as well as android ones.

We have multiple solutions for this problem:

• Add deviceSecret to DeviceDetails class. This will solve the issue as LocalDevice is extending DeviceDetails and will be able to set that field just as before. Spec change about DeviceDetails will be required as well.
• We can create LocalDeviceBase class in core and extend it in Java and Android build with their implementation.
• Remove or move failing tests to Android build only. This option will depend on the android build and won't cover all use cases which is not preferred.

[paddybyers]

The apparent java regression has surfaced a problem with the current spec.

The original idea, and what is in the spec today, is that:

• DeviceDetails encapsulates the details of registerable devices, such as push transport/recipient details, for the purposes of the push admin API (which allows clients to interrogate device details and list registered devices);
• LocalDevice extends DeviceDetails, and additionally includes device identity credentials that are only known to that target device specifically (deviceSecret and deviceIdentityToken). These are used when a client on that device performs operations with push-subscribe rights, to authenticate the device identity to the server.

However, there is a problem with this, which is that we also support a flow where the registration of devices can be performed not by the device itself but by a custom registrar, and a custom registrar has to use the push admin API to do this. As a result, the registrar must be able to populate the device identity credentials, and for that to be possible (as the API is declared right now) those attributes need to exist in DeviceDetails.

The whole thing is messy because other users of the push admin API shouldn't be able to discover device identity credentials (even with push-admin rights) and so those details are removed always in admin API responses that get or list registered device details.

ably-js declares the device identity attributes in DeviceDetails: https://github.com/ably/ably-js/blob/main/src/common/lib/types/devicedetails.ts#L43.

So really the original idea I think is still the correct one - push admin clients shouldn't get to specify, or discover, device identity credentials - but the custom registrar requirement messes this up and this needs to be rethought (or removed). The question is what we do about this right now - do we update this java library to align with ably-js and others and include the device identity attributes in DeviceDetails, or make a much bigger change to fix the broken API with respect to custom registrars?

[qsdigor]

I have implemented this change in the protocol 2.0 branch as it is a part of it.

[deanna-lad]

The corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2713

[sacOO7]

This is fixed serverside as a part of https://github.com/ably/realtime/pull/5394. It was part of the slack discussion https://ably-real-time.slack.com/archives/C030C5YLY/p1700741804479899?thread_ts=1699279152.506959&cid=C030C5YLY.
So, no loner needed as such as a part of protocol 2.0

[sacOO7]

Not needed as a part of protocol 2.0