Securely grab minion ID in pillar top file template?

I found this SLS file in a pillar top.sls targeting example:

top.sls:

base:'*':    - hostspecificsls

hostspecificsls:

# See https://groups.google.com/forum/#!topic/salt-users/UWfP6bMe6F8{% include 'hosts/'+ salt['grains.get']('fqdn') +'.sls' ignore missing %}

This strikes me as distinctly insecure, as it runs counter to one of the Salt Best Practices:

Don't use grains for matching in your pillar top file for any sensitive pillars.

Why is this insecure? Well, grains are evaluated on the minion, so if a minion is sufficiently compromised, it can return whatever an attacker wishes for an arbitrary grain call. A compromised minion might claim to be an SSL (or VPN!) terminator to get at private key material, for example.

Fortunately, there's a (theoretical) solution; use the minion ID. Minion IDs are unique, and they're verified on the master cryptographically.

Except I can't find how to get at the minion ID without depending on grains. Remember, the grains are executed on the minion, so even if the Salt master knows at the transport layer what the minion ID is, if you query for the minion ID via grains, you're asking the minion for the ID, not the master.

So how can I get at the master's concept of the minion ID from Jinja on the master?