ably_auth_openapi/models/
token_details.rs

1/*
2 * Ably Platform Auth REST API
3 *
4 * 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. 
5 *
6 * The version of the OpenAPI document: 1.0.0
7 * 
8 * Generated by: https://openapi-generator.tech
9 */
10
11use crate::models;
12use serde::{Deserialize, Serialize};
13
14/// TokenDetails : An issued Ably Token. The `token` string is presented as a Bearer credential.
15#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
16pub struct TokenDetails {
17    /// The token string, sent as `Authorization: Bearer <token>`.
18    #[serde(rename = "token")]
19    pub token: String,
20    /// The API key name the token was issued from.
21    #[serde(rename = "keyName", skip_serializing_if = "Option::is_none")]
22    pub key_name: Option<String>,
23    /// Milliseconds since the Unix epoch at which the token was issued.
24    #[serde(rename = "issued", skip_serializing_if = "Option::is_none")]
25    pub issued: Option<i64>,
26    /// Milliseconds since the Unix epoch at which the token expires.
27    #[serde(rename = "expires", skip_serializing_if = "Option::is_none")]
28    pub expires: Option<i64>,
29    /// 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. 
30    #[serde(rename = "capability", skip_serializing_if = "Option::is_none")]
31    pub capability: Option<String>,
32    /// The identity bound to the token, if any.
33    #[serde(rename = "clientId", skip_serializing_if = "Option::is_none")]
34    pub client_id: Option<String>,
35}
36
37impl TokenDetails {
38    /// An issued Ably Token. The `token` string is presented as a Bearer credential.
39    pub fn new(token: String) -> TokenDetails {
40        TokenDetails {
41            token,
42            key_name: None,
43            issued: None,
44            expires: None,
45            capability: None,
46            client_id: None,
47        }
48    }
49}
50
ably_auth_openapi/models/token_details.rs

ably_auth_openapi/models/
token_details.rs
