The sandbox publishes test keys and only its supported endpoints. The full example below describes
the target discovery contract; session, name-index, OAuth and MCP fields are not currently emitted.
Its example keys are fixtures, not the deployed trust store. Always fetch the live JWKS from the
pinned issuer. Sandbox launch and immediate rotation do not demonstrate the protocol’s required
30-day key prepublication or full TLP conformance.
Discovery document
Cache the document for its
Cache-Control max-age. A platform that finds a talent through another
license server reads that server’s document the same way. See Discovery in
the Standard for how a platform finds the license server for a talent.
JWKS
The JWKS athttps://app.reflections.ai/.well-known/jwks.json holds the public keys for every
authorization token, session token and receipt. Each key is an EC P-256 key used for ES256
signatures. The endpoint reference is
Retrieve the signing keys.
The
rfl-2026-10-docs3 key in this example verifies the example authorization token, session token and
receipt in the API reference, so you can test a verifier against them.
Rotation
- The target protocol requires a new key to be published 30 days before it signs anything. Refreshing on the
Cache-Controlmax-age is enough to have it before its first use. - Retired keys stay published, so old receipts keep verifying. In the example,
rfl-2026-04-docs3no longer signs but still verifies what it signed. - A
kidis never reused. - Cache the JWKS for its max-age. When a token or receipt names a
kidyou do not have, refetch the JWKS once; if thekidis still missing, reject it. - In live mode, reject tokens signed by a
rfl-test-key.
Related
Authorization token
Verify a token with these keys.
Discovery in the Standard
How a platform finds the license server for a talent.