Assurance

["Cantor, Scott" <>]

Just to add a piece of context from a SAML perspective, when those of us
working on SAML and Liberty analyzed various threat models, one of the key
issues was whether an attacker was presumed to be between the client and
*one of the IdP or RP* or *both the IdP and RP*.

The former is something you can defend against within the protocol and
there are various things that are done because of that threat model, the
assumption being that the attacker is operating a malicious site that is
"close" to one of the IdP or RP but not sitting at the client.

But the key leg is the one between client and IdP, and if you can't
strongly authenticate that, a number of things break down, and there
aren't a lot of things you can do to get back to sound footing. That's
where you really have to move to non-phishable credentials (i.e., client
certifiates), provided you don't botch the TLS server application [1].

With a browser, the only means of server authentication is, umm, well,
there isn't one, it's the user.

When you move to some other client (e.g. ECP, Moonshot, an OAuth client),
then you have the opportunity to do better, and it's really important that
we don't replicate the same broken model and focus very aggressively on
that trust model, because the user cannot be the trust model.

-- Scott

[1] https://secure-resumption.com/