{"id":473,"date":"2006-06-11T14:21:13","date_gmt":"2006-06-11T22:21:13","guid":{"rendered":"\/?p=473"},"modified":"2006-06-11T14:41:04","modified_gmt":"2006-06-11T22:41:04","slug":"guidance-and-test-plan-for-relying-parties","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=473","title":{"rendered":"GUIDANCE AND TEST PLAN FOR RELYING PARTIES"},"content":{"rendered":"<p>I got a note recently from federation master Mike Beach &#8211; a man with a great deal of experience in terms of how users react to security:<\/p>\n<blockquote><p>Is it just me or does your site have an invalid cert.&nbsp; When I attempt to<br \/>\nlogin using my new Infocard in IE7 I get the infamous &#8220;warning, go back, do<br \/>\nnot enter, danger ahead&#8221; and things go all red (really more pink).<\/p>\n<p>Given the primary drivers of Infocard are to save us from all the web evils<br \/>\nof today it would seem this is contrary reinforcement when I must ignore all<br \/>\nthe security warnings to log in.<\/p><\/blockquote>\n<p>I thought, &#8220;That&#39;s weird.&nbsp; I don&#39;t get that problem.&#8221;&nbsp;&nbsp;&#8211; you know, the&nbsp;ancestral &#8220;That&#39;s funny.&nbsp;&nbsp;It doesn&#39;t happen on&nbsp;MY box.&#8221;&nbsp; But of course it really was happening to Mike, so I wrote back and asked if&nbsp;he could send some screenshots.&nbsp; It turned out this wasn&#39;t necessary&nbsp;&#8211; he had already figured out the problem.<\/p>\n<p>He had been visiting identityblog using this URL:&nbsp; <a href=\"https:\/\/www.identityblog.com\/\">https:\/\/www.identityblog.com\/<\/a>.&nbsp;&nbsp;<\/p>\n<p>When he&nbsp;clicked on&nbsp;<strong>Login<\/strong>&nbsp;he was redirected to <a href=\"https:\/\/identityblog.com\/wp-login.php\">https:\/\/identityblog.com\/wp-login.php<\/a>.&nbsp;&nbsp;<\/p>\n<p>But my certificate is&nbsp;limited to&nbsp;<a href=\"https:\/\/www.identityblog.com\/\">https:\/\/www.identityblog.com\/<\/a>.&nbsp; Therefore&nbsp;IE (correctly) saw Mike&#39;s&nbsp;<a href=\"https:\/\/www.identityblog.com\/\">identityblog.com<\/a> and the certificate&#39;s <a href=\"https:\/\/www.identityblog.com\/\">www.identityblog.com<\/a> as being different &#8211; resulting in the redish bar.&nbsp;&nbsp;It looked like this:<\/p>\n<p><img src=\"\/wp-content\/images\/2006\/06\/cert-error.jpg\" \/>&nbsp;<\/p>\n<p>That&#39;s enough to confuse anyone.&nbsp; So clearly, redirecting to something&nbsp;that isn&#39;t consistent&nbsp;with&nbsp;your certificate is a no-no.&nbsp; I was setting up an experience that would undermine&nbsp;my user&#39;s understanding of what was happening to her, breaking law six.&nbsp; I should have been checking and redirecting to <a href=\"https:\/\/www.identityblog.com\/\">www.identityblog.com<\/a> even if the user didn&#39;t supply the &#8220;www&#8221;.&nbsp; Strangely, I had done the <strong>Dashboard<\/strong> link correctly &#8211; it was only the <strong>Login<\/strong> link that had the error.<\/p>\n<p>All of which goes to show there are a set of gotchas that we have to nail down in terms of establishing <strong>prescriptive guidance<\/strong> for how a site should deal with these issues in order to be consistent.&nbsp; We need a checklist &#8211; or better still, a <strong>test plan<\/strong>.&nbsp;&nbsp;A wiki would be a good way to elaborate this.<\/p>\n<p>Another big takeaway is that an identity 2.0 relying party has an obligation to make sure&nbsp;it doesn&#39;t do things that send mixed signals (in my case, nice InfoCard experience but big red warning bar in IE).&nbsp; Everyone has to co-operate with the goal of not confusing the user.<\/p>\n<p>It&#39;s worth pointing out that none of this is&nbsp;primarily an InfoCard problem.&nbsp; The same&nbsp;considerations apply to any use of https.&nbsp; But in the InfCard case we want to make sure we have the deployment practices nailed down to a higher level than has previously been the case.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>An identity 2.0 relying party has an obligation to make sure it doesn&#39;t do things that send mixed signals about the user experience <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,2,3,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/473"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=473"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/473\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=473"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=473"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=473"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}