<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">With InCommon now offering personal signing certificates</span></div></blockquote></div><br class=""><div class="">Sorry, I neglected to reply to this part. It’s a great observation.</div><div class=""><br class=""></div><div class="">Everyone thinks of two-factor authentication being performed and enforced by the IdP, but you allude to the SP being able to do it. I’ve seen it used sparingly in production, but if the SP is in a position where it can or needs to credential users, it’s an option.</div><div class=""><br class=""></div><div class="">It becomes an even more interesting option when combined with holder-of-key SAML assertions that can bind the assertion minted by the IdP to the same keypair that can be presented to the SP.</div><div class=""><br class=""></div><div class=""><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.html" class="">http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.html</a></div><div class=""><br class=""></div><div class="">This is a potential deployment trend for higher-risk implementations that I’ve followed closely, but I’ve seen limited traction.</div></body></html>