The server and DNS configuration you need for a subdomain is identical to what you need for separate domain. Possibly slightly more to manage if you are using the "naked" domain because of the DNS issue with not supporting CNAME records on the naked domain.
If you already have a wildcard SSL certificate for the subdomain a separate domain might be more work because you need a new cert and you don't if you stick with a subdomain.
The most work is actually buying the domain.
Then again, this is government we are talking about so buying a $10 domain is probaly three weeks worth of paperwork.
There are security implications galore, mostly due to the same-origin policy. Books can and have been written about web security; if you're writing webapps, you need to read one.
One method works, one doesn't.
But keep on telling people to read a book, for all the good it will do.
It's not that bad.
It is slightly annoying that the procurement rules don't let sysadmins buy multi-year domain registrations---not even for .gov domains.
Ultimately, there's nothing stopping a federal employee or contractor from buying another domain except ignorance of good infosec practices. Even a .gov domain isn't all that expensive---$400/year is a drop in the bucket of federal spending.
https://www.gpo.gov/fdsys/pkg/CFR-2010-title41-vol3/xml/CFR-...
Dev: "Can I have a domain?" Me: "Sure" 10 minutes later done
In government I imagine you need a procurement order which needs to be approved. And my anecdotal experience has been that the dev teams don't always take high priority in those queues.
I'm sure it's not as hard as I made it out to be but it is certainly not as straight forward as many of us are used to.
I regularly need to host internal applications accessible by other staff and often just do so from my machine during the daytime and send them updated IP addresses/ports where they can access them... boss didn't even think it was possible...
Yeah. I imagine the government processes are pretty convoluted.
Some of the tools are temporary mind you, and it's much quicker to run the temp tool on my machine through the local network for a couple of weeks than to spend a few days waiting on resource allocation and then getting it shut down afterward.
Some of them are scheduled to be merged into larger projects that will seek out the necessary permanent resources... in time.
And things always take their time. It's my first excursion into such a large company and it is boggling at times. Things that would be small flaws in a smaller business are magnified 10, or 100x.
https://www.fcc.gov/ecfs/public-api-docs.html#Full-Filing-St...
Unfortunately, these "temporary" file uploads end up accessible from the main FCC domain (i.e. fcc.gov), unlike e.g., Google (e.g., "googleusercontent.com" vs. "google.com"). In Google's case, the separate domain helps distinguish the content as unofficial.
It's understandable why it was originally engineered this way, since it's probably easier to create a subdomain under fcc.gov rather than to get an unrelated domain, but that's why we ended up here!