A civic integration sends tenant identifiers and access tokens to an API over the network. How do end-to-end encryption principles apply to that API hop?
Select an answer to reveal the explanation.
Short Explanation
If the postcard is readable on every mail truck, the token is gone—HTTPS/TLS is how the API payload stays confidential on the hop. Base64 is wrapping paper, not a lock.
Full Explanation
End-to-end encryption principles for API hops mean confidentiality (and integrity) of requests and responses on the path to the intended server. When a civic integration sends tenant identifiers and access tokens over the network, it must use HTTPS/TLS so bodies and headers are not readable or silently altered by on-path observers. Tokens in particular must never ride cleartext HTTP across municipal or transit networks.
Base64-encoding the JSON body on HTTP fails because Base64 is reversible encoding, not encryption—any intermediary can decode tokens instantly. Disabling TLS and relying on obscurity of nonstandard TCP ports fails confidentiality; ports are not secrets. Encrypting only the HTTP method line and leaving the body in cleartext fails the principle: the sensitive identifiers and tokens live in the body and headers TLS is meant to protect.
Exam caveat: TLS to the correct hostname (certificate verification) matters as much as “having TLS”; pinning or private CAs may apply in controlled civic environments. TLS is the API answer—not MACsec or IPsec—unless the stem explicitly shifts layers.
Operational check: capture traffic on a lab span and confirm the integration’s API hop shows TLS records rather than plaintext JSON tokens, with certificate name matching the configured API host.