[noasaservice]

Use SAML.

The SP never sees the credentials. The SP only sees a token which includes the username (NameID) and other attributes passed from the IdP through the client.

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...

(Scroll down to the "Single sign-on using SAML in a Web browser" image for a good data flow depiction)

Basically this seems to be a "SAML-IZE EVERYTHING".

[distortedsignal]

But with SAML you're trusting the cert/key pair on the signing end of the connection. If you say "well, we can use the cert provided by the server by getting it over HTTPS every time we need to auth with SAML," then you're trusting the Root CA Cert/Key pair for the TLS connection that underlies the HTTPS protocol. (Source: I've written two SAML SPs.)

With ZT, you basically have to bootstrap trust from the factory. I don't think of ZT as "don't trust anything" - it's more like "trust our supply lines".

Think about the failure modes of ZT: if the NIC, the CPU, the OS, and the bootloader are deemed secure at boot time, there has to be something that starts the bootloader and loads its keys. If you compromise _that_ piece, then you can compromise anything further up the stack and not worry too much about security alerts. The only way to make sure that all machines are secure/uncompromised is to XRay all of the bootloader chips and verify them down to the ~100um level (got this figure by talking to a guy doing grad work @UofM when he was in SV around 2017-2018, I want to say).