Electronic signatures

[Nate Klingenstein]

> You can require signed requests to try ensure that the ForceAuthn is received at the IdP (although Scott tells me there may be ways that is still insufficient, given that Shib SP doesn’t map requests to responses)

You can specify in metadata that authentication requests need to be signed.  You’re reliant on the IdP not lying to you in any of these cases, but this at least eliminates the ability for the end user to tamper with it.

> there’s no guarantee that the authentication instant asserted by the IdP means what you think it means (e.g., it could mean, “yes, the user’s Kerb ticket is still valid”).

We’ve gone in circles on this one before and we could again.  ForceAuthn looks pretty precisely specified to me, for what it’s worth, which is not much in real deployment.

https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

https://spaces.internet2.edu/display/InCFederation/2013/12/08/ForceAuthn+or+Not

> So in this case I mean literally auditing the IdP’s behavior.

I can understand the appeal and the value.  I don’t think there’s a chance in Hades that SP’s will get to audit their IdP’s.  The best you can do is conclusively prove that the IdP was at fault, which signatures can nominally give you.

Consider the experience we had with POPs.