The WebSocket examples in docs/getting-started.md and docs/transports.md emphasize passing a bearer token to WebSocketClientTransport.connectAsync, but ARCP runtime authentication is performed from session.hello.payload.auth, not from the WebSocket upgrade header. The docs/getting-started.md example then constructs new ArcpClient(transport, ArcpClientOptions.defaults), which sends AuthScheme.None, so a reader can believe the token authenticated the session while the ARCP principal is anonymous. The XML comment on WebSocketClientTransport.connectAsync in src/Arcp.Client/Transport/WebSocket.fs is also confusing because it says the runtime adapter authenticates against the parsed IPrincipal rather than re-reading the header, but the SDK path shown does not map that header into AuthPayload.
Fix prompt: revise the WebSocket transport documentation so it clearly distinguishes HTTP upgrade headers from ARCP session authentication. In docs/getting-started.md, docs/transports.md, and the connectAsync XML comment, show the bearer token being supplied to ArcpClientOptions.Auth = AuthScheme.Bearer token whenever the runtime expects ARCP bearer auth, and describe the upgrade header as optional host-level metadata rather than the session-auth source. Add a short note that using ArcpClientOptions.defaults sends auth.scheme = "none" and should only be used with runtimes that explicitly allow anonymous sessions.
The WebSocket examples in
docs/getting-started.mdanddocs/transports.mdemphasize passing a bearer token toWebSocketClientTransport.connectAsync, but ARCP runtime authentication is performed fromsession.hello.payload.auth, not from the WebSocket upgrade header. Thedocs/getting-started.mdexample then constructsnew ArcpClient(transport, ArcpClientOptions.defaults), which sendsAuthScheme.None, so a reader can believe the token authenticated the session while the ARCP principal is anonymous. The XML comment onWebSocketClientTransport.connectAsyncinsrc/Arcp.Client/Transport/WebSocket.fsis also confusing because it says the runtime adapter authenticates against the parsedIPrincipalrather than re-reading the header, but the SDK path shown does not map that header intoAuthPayload.Fix prompt: revise the WebSocket transport documentation so it clearly distinguishes HTTP upgrade headers from ARCP session authentication. In
docs/getting-started.md,docs/transports.md, and theconnectAsyncXML comment, show the bearer token being supplied toArcpClientOptions.Auth = AuthScheme.Bearer tokenwhenever the runtime expects ARCP bearer auth, and describe the upgrade header as optional host-level metadata rather than the session-auth source. Add a short note that usingArcpClientOptions.defaultssendsauth.scheme = "none"and should only be used with runtimes that explicitly allow anonymous sessions.