<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Jul 5, 2007, at 11:18 AM, Evan Prodromou wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On Thu, 2007-05-07 at 14:12 +0300, Martin Paljak wrote:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">You can't enforce the way applications are built or organizations <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">work. You can't dictate the way OpenID is used. RP decides what is <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">good, why is good and how is good enough for it to operate and <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">there's nothing others can do.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I agree. The above argument is successfully used in the email world of antispam DNSBLs.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I've found that one of the great entry points for OpenID is two-way or</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">multi-way closed trust systems. The big use case for many administrators</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">seems to be letting users from another "partner" site log into their own</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">site, and vice versa. Only after this relationship is established do</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">some admins enable more open trust relationships.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE></DIV><BR><DIV>I am working on web-of-trust whitelisting, and will keep this in mind as a common starting point.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So far I have the following proposal. Please accept my apologies for any terminology inconsistencies with existing work. I am still getting up to speed and have not read all the specs yet.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="text-align: center;"><B>OpenID WhiteListing (OWL) Project</B></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(The world is not black and white, so I may add more nuance to the concept of a whitelist; perhaps it should be more value-neutrally called a "claimlist".)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This project, as a v0.1 straw man prototype, produces three whitelists.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Please consider these whitelists to be Platonic forms which may see one or more embodiments, provided by different operators, and used by different people in different ways.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="text-align: center;"><B>OWL-OP</B></DIV><DIV style="text-align: center;"><I>A whitelist of OpenID Providers.</I></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A Relying Party may choose to distinguish EUs associated with a listed OP.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="text-align: center;"><B>OWL-RLY</B></DIV><DIV style="text-align: center;"><I>A whitelist of OpenId Relying Parties.</I></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>At present, the login process involves two speedbumps.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Speedbump 1: "Oops, you're not logged in to your OP. Please login now."</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Speedbump 2: "Now that you're logged in to the OP, do you want to trust this RP?"</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Speedbump 1 is addressed by extending OP session longevity as much as possible.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Speedbump 2 may be addressed by OWL-RLY.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If an RP is on the list, an OpenID Provider may choose to bypass it and just proceed with a "yes" assumption.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I hereby name the bypass operation "YARLY".</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>An OpenID Provider can offer its End-Users a menu of which whitelists to trust, with defaults preset in the spirit of libertarian paternalism. Tinfoilhat types can uncheck all. Our grandmothers can check all. Tinfoilhat grandmothers are considered an edge case.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-style-span">For people with no sense of humour, OWL-RLY is aliased identically to <B>OWL-RP</B>.</SPAN></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="text-align: center;"><B>OWL-EU</B></DIV><DIV style="text-align: center;"><I>A whitelist of OpenID End-Users.</I></DIV><DIV style="text-align: center;"><BR class="khtml-block-placeholder"></DIV><DIV>RPs can use this whitelist where increased granularity is needed. The analogous case is when both legitimate and phishing websites are hosted on Geocities.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The corresponding OBL-EU may be used as a signaling mechanism to inform OPs that their EUs have been naughty.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="text-align: center;"><B>Implications for User Experience and Phishing</B></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If the ORLY / YARLY paradigm gains adoption, and if end-users stay logged in to their OPs >98% of the time, then the typical use case will bypass both the login speedbump and the "allow?" speedbump. We may then observe a reduction in phishing scenarios, as end-users will be alerted by the very unexpectedness of the login speedbump.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I make the assumption that to combat phishing it is important to marginalize the appearance of any speedbump at all. If users become accustomed to clicking through Speedbump 2, I assert that they will be less alert when presented with a phish of Speedbump 1.</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>