The Binding Test: One Rule, Three Planes

The connected-vehicle study can now be judged with one cross-plane question: after a backend accepts a vehicle identity, does it authorize that identity for the exact resource named in the request? Applying that question to MQTT topics, HTTPS objects, and SMS commands creates a practical test. It also keeps three distinctions intact: a local seed prerequisite is not the same as remote victim impact, a valid request is not the same as an authorized request, and a measured count is not automatically a fleet estimate.

One invariant, three resource forms

The invariant is simple: the authenticated principal must be bound to the target resource before the system allows the operation. What changes from one plane to another is the form of that resource and the component that can enforce the decision.

On MQTT, the target is a topic namespace, subscription, or command scope associated with a vehicle. The backend may maintain a long-lived session, but that persistence does not make the session owner of every topic it can name. A vehicle session should remain within the namespace authorized for that vehicle. If the session is authenticated as Vehicle A and the topic belongs to Vehicle B, the broker or its authorization service should deny the operation.

On HTTPS, the target is an object, record, media asset, or other resource named in an individual request. The same identity-to-resource rule must be applied each time the request identifies an object. A valid token or session can be reused to make a new request, but it cannot turn a new object identifier into an automatically authorized one. The API must decide whether the principal may access that object, and any downstream storage service must preserve the same scope when it serves the content.

On SMS fallback, the target is a vehicle and a management action. The receiving side needs confidence about the sender, the message’s freshness and integrity, and the vehicle for which the action is intended. A message can be well formed and still be unauthorized if it is accepted from the wrong origin or if its contents are not bound to the receiving vehicle. The fallback path is therefore subject to the same invariant even though its delivery and state model differ from MQTT and HTTPS.

flowchart LR I["Authenticated vehicle identity"] --> P{"Target-specific policy check"} M["MQTT topic or command scope"] --> P H["HTTPS object or record"] --> P S["SMS command and target vehicle"] --> P P --> A["Allow when identity and target match"] P --> D["Deny or block out-of-scope effect"]

The diagram is deliberately less specific than any one protocol implementation. It shows the shared decision without pretending that an MQTT ACL, an API ownership check, and an SMS sender check are the same mechanism.