/*
* Ably Platform Auth REST API
*
* The subset of the Ably **platform** REST API used for authentication and token lifecycle: requesting Ably Tokens, revoking them, and reading server time. This is a *separate* API from the Ably Chat REST API (`openapi/ably-chat-rest.yaml`, path prefix `/chat/v4`) — token issuance and revocation live on the platform host under `/keys/...`, not under `/chat/_*`. ## Scope & provenance Ably publishes an authoritative platform spec, [`ably/open-specs`](https://github.com/ably/open-specs) `platform-v1.yaml`, which covers the full generic pub/sub REST API (`/channels`, `/push`, `/keys`, `/stats`, `/time`). **This document is deliberately narrow**: it models only the endpoints this project's authentication story ([ADR-0012](../docs/adr/0012-token-issuance-permissions.md), [SPEC §13](../docs/SPEC.md)) touches — `POST /keys/{keyName}/requestToken`, `POST /keys/{keyName}/revokeTokens`, and `GET /time`. Field-level details are cross-checked against `platform-v1.yaml`, the Ably auth docs, and the `ably-js` auth implementation (see [`../docs/research/2026-07-24-ably-chat-auth-permissions.md`](../docs/research/2026-07-24-ably-chat-auth-permissions.md)). ## Relationship to the Chat client `ably-chat-rs` is a Chat REST client; it does not itself sign TokenRequests or call `/keys/...` (ADR-0012 Tier 4). This spec documents the platform endpoints a *token server* (or the official `ably` crate) uses to mint the Bearer credentials that are then handed to the Chat client. Capability documents carried by these tokens are described in SPEC §13, not here.
*
* The version of the OpenAPI document: 1.0.0
*
* Generated by: https://openapi-generator.tech
*/
use crate::models;
use serde::{Deserialize, Serialize};
/// TokenRequest : A **signed** token request. The `mac` is HMAC-SHA256 (base64) over the newline-joined fields `keyName`, `ttl`, `capability`, `clientId`, `timestamp`, `nonce` (each followed by a newline, empty fields included) using the API key secret. A signed request needs no `Authorization` header.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TokenRequest {
/// The API key name (`appId.keyId`) that signed this request.
#[serde(rename = "keyName")]
pub key_name: String,
/// Requested time-to-live in milliseconds.
#[serde(rename = "ttl", skip_serializing_if = "Option::is_none")]
pub ttl: Option<i64>,
/// A capability document as a JSON **string** (a stringified object mapping resource-name patterns to arrays of operations, e.g. `{\"my-room\":[\"publish\",\"history\"]}`). For a signed `TokenRequest` this string must be canonicalized (resource keys and operation arrays sorted, no whitespace) because it is part of the HMAC-signed text. See SPEC §13.
#[serde(rename = "capability", skip_serializing_if = "Option::is_none")]
pub capability: Option<String>,
/// The identity to bind the token to.
#[serde(rename = "clientId", skip_serializing_if = "Option::is_none")]
pub client_id: Option<String>,
/// Milliseconds since the Unix epoch when the request was created. Must be within ~2 minutes of Ably server time (see `GET /time`).
#[serde(rename = "timestamp")]
pub timestamp: i64,
/// An opaque, cryptographically-random string of at least 16 characters, unique per request (replay protection).
#[serde(rename = "nonce")]
pub nonce: String,
/// Base64 HMAC-SHA256 signature over the canonical request text.
#[serde(rename = "mac")]
pub mac: String,
}
impl TokenRequest {
/// A **signed** token request. The `mac` is HMAC-SHA256 (base64) over the newline-joined fields `keyName`, `ttl`, `capability`, `clientId`, `timestamp`, `nonce` (each followed by a newline, empty fields included) using the API key secret. A signed request needs no `Authorization` header.
pub fn new(key_name: String, timestamp: i64, nonce: String, mac: String) -> TokenRequest {
TokenRequest {
key_name,
ttl: None,
capability: None,
client_id: None,
timestamp,
nonce,
mac,
}
}
}