EDIT: In case it's not clear: I'm talking about employee facing software inside an organization where you might have some kind of single sign on system or a distributed account system (like IPA or LDAP.)
EDIT: In case it's not clear: I'm talking about employee facing software inside an organization where you might have some kind of single sign on system or a distributed account system (like IPA or LDAP.)
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".
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).
There is a Wikipedia article on 'Key ceremony'[0] that seems to indicate an in-real-life shared secret creation and or sharing event.
For example, don't use the same password on your Etrade account that you use on your bank account.