Run native-token conformance on every UTS leg by splitting the clients

TokenRequestTest's two clients now sit on opposite sides of the seam,
matching how native tokens are really used: the minting client — the
createTokenRequest surface under test — goes through the door on every
leg, so the server leg exercises token minting through the server
package; the consuming client models the device the token was minted
for and is always a plain core client, since a client may not
authenticate itself with a native token while declaring the server side
(realtime rejects that with 40167, and the native token format cannot
carry the required signed claim).

Nothing is skipped on any leg any more, so assumeSideSupportsTokenAuth
is deleted.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: 2 people

uts/README.md

@@ -813,12 +813,20 @@ Unlike ably-js's UTS there is no `device` mode: `io.ably.pubsub:device` is an An
 so its door cannot run on the JVM this suite uses. Its stamping contract is covered by the
 instrumentation tests in the `device` module (`emulate.yml`).
 
-**Token-auth tests are skipped on the server leg.** Realtime rejects a token-authenticated
-connection that declares the server side through the agent entry alone (error 40167: the side
-must come from a signed `x-ably-clientType` token claim — PDR-091 deferred decision D2, not yet
-implemented anywhere the test infra can reach). Tests whose clients use token auth call
-`assumeSideSupportsTokenAuth()` and are reported as skipped, not failed, in server mode. When D2
-lands, mint the claim in the test infra and delete the assumption.
+**Token auth on the server leg.** Realtime rejects a token-authenticated connection that
+declares the server side through the agent entry alone (error 40167: on token auth the side
+must come from a signed `x-ably-clientType` token claim). The suite handles this per token
+format, with nothing skipped:
+
+- **JWTs** can carry the claim already: tests that authenticate the client under test with a
+  token mint one via `AblyJwt` (HS256, JDK crypto), adding `x-ably-clientType=server` on the
+  server leg (see `AuthReauthTest`).
+- **Native tokens** cannot carry the claim yet, so a client may not authenticate *itself* with
+  one while declaring the server side. `TokenRequestTest` therefore splits its clients across
+  the seam, matching how the feature is really used: the **minting** client (the
+  `createTokenRequest` surface under test) goes through the door on every leg, and the
+  **consuming** client — modelling the device the token was minted for — is always a plain
+  core client.
 
 Notes:
 - `ProxyManager` **advises** running proxy suites single-fork (`maxParallelForks = 1`) because they

uts/src/test/kotlin/io/ably/lib/uts/infra/integration/AblyJwt.kt

@@ -11,9 +11,10 @@ import javax.crypto.spec.SecretKeySpec
  * notably `x-ably-clientType=server`: on token auth the realtime service accepts a
  * server-side declaration only from that signed claim (a `-server` agent entry alone is
  * rejected with error 40167), and the native token format cannot carry the claim yet. So a
- * JWT is the one way a token-authenticated client can declare the server side, and JWT-based
- * tests can run on the server UTS leg while native-token tests remain skipped (see
- * assumeSideSupportsTokenAuth).
+ * JWT is the one way a token-authenticated client can declare the server side, which lets
+ * JWT-based tests run on the server UTS leg. (Native-token tests instead keep their
+ * token-consuming client on the core constructors, modelling the device the token was minted
+ * for — see TokenRequestTest.)
  */
 object AblyJwt {
     /**

uts/src/test/kotlin/io/ably/lib/uts/infra/unit/ClientFactories.kt

@@ -37,24 +37,6 @@ class ClientOptionsBuilder : DebugOptions("appId.keyId:keySecret") {
  */
 val utsSide: String = System.getProperty("uts.side").let { if (it.isNullOrEmpty()) "core" else it }
 
-/**
- * Call at the top of any test whose client authenticates with a native Ably token.
- *
- * Realtime rejects a token-authenticated connection that declares the server side through the
- * agent entry alone: error 40167, "a connection or request may only declare itself as a server
- * via a signed x-ably-clientType token claim". The native Ably token format cannot carry that
- * claim yet, so until the platform supports it, native-token conformance runs on the core leg
- * only and is skipped (not failed) on the server leg. Key-auth tests are unaffected — on
- * API-key auth the agent entry is the accepted declaration — and JWT-based tests can carry the
- * claim already (see AblyJwt), so they run on every leg instead of calling this.
- */
-fun assumeSideSupportsTokenAuth() = org.junit.jupiter.api.Assumptions.assumeTrue(
-    utsSide == "core",
-    "native-token conformance is skipped on the '$utsSide' leg: realtime requires a signed " +
-        "x-ably-clientType token claim (40167) to declare the server side on token auth, " +
-        "and the native token format cannot carry that claim yet",
-)
-
 fun TestRealtimeClient(block: ClientOptionsBuilder.() -> Unit): AblyRealtime {
     val options = ClientOptionsBuilder().apply(block)
     return when (utsSide) {

uts/src/test/kotlin/io/ably/lib/uts/integration/standard/realtime/TokenRequestTest.kt

@@ -1,11 +1,11 @@
 package io.ably.lib.uts.integration.standard.realtime
 
+import io.ably.lib.realtime.AblyRealtime
 import io.ably.lib.realtime.ConnectionState
 import io.ably.lib.rest.Auth
 import io.ably.lib.uts.infra.awaitState
 import io.ably.lib.uts.infra.integration.SandboxApp
-import io.ably.lib.uts.infra.unit.assumeSideSupportsTokenAuth
-import io.ably.lib.uts.infra.unit.TestRealtimeClient
+import io.ably.lib.uts.infra.unit.ClientOptionsBuilder
 import io.ably.lib.uts.infra.unit.TestRestClient
 import kotlinx.coroutines.runBlocking
 import kotlinx.coroutines.test.runTest
@@ -30,6 +30,14 @@ import kotlin.time.Duration.Companion.seconds
  * server. A REST client signs the TokenRequest; a separate realtime client exchanges it (through
  * its `authCallback`) for a token and connects, proving the server accepted it.
  *
+ * The two clients deliberately sit on different sides of the seam. The **minting** client — the
+ * RSA9 surface under test — goes through [TestRestClient], so on the server UTS leg it exercises
+ * `createTokenRequest` through the server door, the shape a real server has: mint native tokens
+ * for others. The **consuming** client models the device those tokens are minted for, so it is
+ * always a plain core client: a client may not authenticate *itself* with a native token while
+ * declaring the server side (realtime rejects that with 40167 — on token auth the side must come
+ * from the signed x-ably-clientType claim, which the native token format cannot carry).
+ *
  * Spec points: RSA9, RSA9a, RSA9g. Source spec: `realtime/integration/auth/token_request_test.md`.
  */
 @TestInstance(TestInstance.Lifecycle.PER_CLASS)
@@ -47,21 +55,24 @@ class TokenRequestTest {
         if (::app.isInitialized) app.delete()
     }
 
+    /** The token-consuming client — a plain core client on every leg; see the class doc. */
+    private fun tokenConsumingClient(block: ClientOptionsBuilder.() -> Unit): AblyRealtime =
+        AblyRealtime(ClientOptionsBuilder().apply(block))
+
     /**
      * @UTS realtime/integration/RSA9a/token-request-server-accepted-0
      * @UTS realtime/integration/RSA9g/token-request-server-accepted-0
      */
     @Test
     fun `RSA9a, RSA9g - createTokenRequest produces server-accepted token`() = runTest {
-        assumeSideSupportsTokenAuth()
         // Client A signs TokenRequests locally with the API key (no network).
         val creator = TestRestClient {
             key = app.defaultKey
             restHost = SandboxApp.sandboxHost
         }
 
         // Client B connects using a TokenRequest produced by client A.
-        val client = TestRealtimeClient {
+        val client = tokenConsumingClient {
             authCallback = Auth.TokenCallback { params -> creator.auth.createTokenRequest(params, null) }
             realtimeHost = SandboxApp.sandboxHost
             restHost = SandboxApp.sandboxHost
@@ -87,7 +98,6 @@ class TokenRequestTest {
      */
     @Test
     fun `RSA9 - createTokenRequest with clientId`() = runTest {
-        assumeSideSupportsTokenAuth()
         val testClientId = "token-request-client-" + UUID.randomUUID()
 
         val creator = TestRestClient {
@@ -97,7 +107,7 @@ class TokenRequestTest {
 
         // The TokenRequest is signed with the specific clientId, producing a token that
         // authenticates the client with that identity.
-        val client = TestRealtimeClient {
+        val client = tokenConsumingClient {
             authCallback = Auth.TokenCallback { params ->
                 params.clientId = testClientId
                 creator.auth.createTokenRequest(params, null)