WHO_IS_AUTHORITATIVE — Group 21, Code 12
CMAC-authenticated authority answer for a single coin, for a relying workstation.
Design-stage — parameters are a first draft
Field sizes are drafted from raidax/ideas_for_suspect_raida_servers.txt (Addenda 5–7) and are not final or implementation-verified. The body is encrypted per the header ENC_CODE; see below.
Phase I — essential
This command is part of the Phase I minimum needed for a coin to move from root to suspect (and back) and be trusted by a workstation. The relying-party trust anchor.
How it works
This is the question a relying party — for example a merchant's workstation deciding whether to trust a coin — asks the root directly: “for this specific coin, which server is currently the authority?” The answer determines which server the workstation should then ask to authenticate the coin.
The root replies with the authoritative server id, a sequence number, the epoch, and an AES-CMAC computed under a key it shares with that workstation, so the answer is provably genuine and cannot be spoofed by a third party. This is the trust anchor of the whole scheme: because workstations already trust the root, a root-authenticated statement of “the authority is server S” is enough — no public-key signatures or blockchain are needed.
Direction & encryption
- Direction: workstation → root
- ENC_CODE: 0 / 1
Request Body parameters
| Field | Bytes | Description |
|---|---|---|
| CH (challenge) | 16 | Standard challenge / replay protection (per header convention). |
| DN | 1 | Denomination of the coin. |
| SN | 4 | Serial number of the coin. |
| EOF | 2 | Terminator (0x3E3E). |
Response Body parameters
| Field | Bytes | Description |
|---|---|---|
| authority_id | 2 | Authoritative server id (0 = root). |
| seq | 4 | Authority sequence number. |
| epoch | 4 | Epoch of this answer. |
| CMAC | 16 | AES-CMAC under the workstation's shared key. |