The public message catalog and state documentation model a four-message challenge flow, but the client and runtime do not implement it. SessionChallenge and SessionAuthenticate are public message types at lib/src/main/kotlin/dev/arcp/messages/Session.kt:152 and lib/src/main/kotlin/dev/arcp/messages/Session.kt:162. SessionState.Authenticating at lib/src/main/kotlin/dev/arcp/runtime/SessionState.kt:20 is documented as awaiting challenge resolution, but it is unused. ARCPClient.open at lib/src/main/kotlin/dev/arcp/client/ARCPClient.kt:45 sends SessionOpen and treats the first reply as accepted, unauthenticated, or rejected, so a peer that sends SessionChallenge is reported as an unexpected handshake reply. ARCPRuntime.authenticate at lib/src/main/kotlin/dev/arcp/runtime/ARCPRuntime.kt:650 verifies credentials directly from SessionOpen and never emits a challenge.
Fix prompt: Either implement the advertised challenge flow or narrow the API and documentation to the direct-credential handshake that exists today. If implementing it, add a client-side challenge responder, move runtime state through SessionState.Authenticating, emit SessionChallenge when a configured auth scheme needs nonce proof, accept a correlated SessionAuthenticate, and test against signed JWT challenge behavior. If deferring it, make SessionChallenge handling return an explicit UNIMPLEMENTED path and update the conformance and guide docs to say challenge handshakes are not yet supported.
The public message catalog and state documentation model a four-message challenge flow, but the client and runtime do not implement it.
SessionChallengeandSessionAuthenticateare public message types atlib/src/main/kotlin/dev/arcp/messages/Session.kt:152andlib/src/main/kotlin/dev/arcp/messages/Session.kt:162.SessionState.Authenticatingatlib/src/main/kotlin/dev/arcp/runtime/SessionState.kt:20is documented as awaiting challenge resolution, but it is unused.ARCPClient.openatlib/src/main/kotlin/dev/arcp/client/ARCPClient.kt:45sendsSessionOpenand treats the first reply as accepted, unauthenticated, or rejected, so a peer that sendsSessionChallengeis reported as an unexpected handshake reply.ARCPRuntime.authenticateatlib/src/main/kotlin/dev/arcp/runtime/ARCPRuntime.kt:650verifies credentials directly fromSessionOpenand never emits a challenge.Fix prompt: Either implement the advertised challenge flow or narrow the API and documentation to the direct-credential handshake that exists today. If implementing it, add a client-side challenge responder, move runtime state through
SessionState.Authenticating, emitSessionChallengewhen a configured auth scheme needs nonce proof, accept a correlatedSessionAuthenticate, and test against signed JWT challenge behavior. If deferring it, makeSessionChallengehandling return an explicitUNIMPLEMENTEDpath and update the conformance and guide docs to say challenge handshakes are not yet supported.