{"id":816,"date":"2007-06-24T11:31:57","date_gmt":"2007-06-24T19:31:57","guid":{"rendered":"\/?p=816"},"modified":"2007-06-25T22:13:03","modified_gmt":"2007-06-26T06:13:03","slug":"no-saml-bashing-intended-here","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=816","title":{"rendered":"No SAML bashing intended here"},"content":{"rendered":"<p><a href=\"http:\/\/conorcahill.blogspot.com\/\">Conor Cahill (Conor&#39;s Web log of Esoterica)<\/a> responds to my discussion about SAML protocol and linkability in a piece called <a href=\"http:\/\/conorcahill.blogspot.com\/2007\/06\/saml-bashing.html\">SAML bashing<\/a> &#8211; which is, by the way,&nbsp;absolutely NOT my intent.&nbsp; I&#39;m simply trying to understand how SAML relates to linkability, as I am doing for all the other&nbsp;major identity technologies.&nbsp;&nbsp;I can&#39;t take up all the&nbsp;points he raises at this point in the flow, but encourage the reader to look at&nbsp;his piece&#8230;&nbsp;<em> <\/em><\/p>\n<p>Conor&nbsp;mentions the emerging ideas for a SAML 2.0&nbsp;Enabled Client\/Proxy.&nbsp; I want to make it clear I wasn&#39;t&nbsp;analysing&nbsp;these proposals.&nbsp; I was&nbsp;analysing&nbsp;SAML <em>as&nbsp;everyone knows it today <\/em>&#8211;&nbsp;using the &#8220;http redirect&#8221; and&nbsp;&#8220;post&#8221; modes&nbsp;that have&nbsp;been widely deployed in portals all over the world, and don&#39;t require changes to the browser.<\/p>\n<p style=\"margin-left: 30px\"><a href=\"https:\/\/www.identityblog.com\/\"><font color=\"#776644\">Kim <\/font><\/a><a href=\"\/?p=815\"><font color=\"#776644\">writes about SAML&#39;s use of redirection protocols.<\/font><\/a>. To start with, he forgets to mention a few important facts as part of his discussion:&nbsp;<\/p>\n<ul>\n<li>SAML defines a <a href=\"http:\/\/docs.oasis-open.org\/security\/saml\/v2.0\/saml-profiles-2.0-os.pdf\"><font color=\"#336688\">profile for an Enabled Client\/Proxy (ECP)<\/font><\/a> which is an evolution of the Liberty Alliance&#39;s LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).<\/li>\n<li>The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.<\/li>\n<\/ul>\n<p style=\"margin-left: 30px\">That said, there are still several statements in Kim&#39;s analysis that I feel obligated to respond to. These include:<\/p>\n<p style=\"margin-left: 60px\">Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on &#8211; trust us.\u00e2\u20ac\u009d)<\/p>\n<p style=\"margin-left: 30px\">First off, the user only see&#39;s nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don&#39;t want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace&#39;s implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.<\/p>\n<p style=\"margin-left: 30px\">Secondly, the analogy is way off base, trying to make this seem like I&#39;m bing pick-pocketed by someone I don&#39;t know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of &#8220;I give one of my providers permission to reach into my bank account and withdraw money to pay my bill&#8221;. I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.<\/p>\n<p style=\"margin-left: 30px\">[<a href=\"http:\/\/conorcahill.blogspot.com\/2007\/06\/saml-bashing.html\">Much more here&#8230;]<\/a><\/p>\n<p>I think Conor is misunderstanding my intentions.&nbsp; I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor&#39;s points b) and c) above would likely apply.&nbsp; But we are looking at linkability precisely to judge the threats in the case&nbsp;where parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.)&nbsp; So arguing that the identity provider will behave properly has nothing to do with what I am exploring:&nbsp; risk.&nbsp; I&#39;ll try to build Conor&#39;s concerns into my ongoing discussion.<\/p>\n<p>In terms of Conor&#39;s point about letting his telephone company deduct directly from his bank account, that&#39;s a use case that &#8220;rings true&#8221;, but there are few companies to which I would want to give this ability.&nbsp; That&#39;s my point.&nbsp; We need a spectrum of technologies to handle different use cases and risk profiles.<\/p>\n<p><em>[Update:&nbsp; Conor&nbsp;later relents a bit&nbsp;in <\/em><a href=\"http:\/\/conorcahill.blogspot.com\/2007\/06\/perhaps-not-so-much-bashing.html\"><em>Perhaps not so much Bashing<\/em><\/a><em>, bringing up a number of points I&nbsp;hope to make part of this exposition.]&nbsp;<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>We are looking at linkability precisely to judge the threats in the case that parties to identity transactions are NOT completely trustworthy&#8230;<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,17,10,8,38,11],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/816"}],"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=816"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/816\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=816"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=816"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=816"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}