Josh, thanks for posting! See my comments inline -Hans > ... > Other relevant issues: > > ... > * Any technology that prevents phishing will require > user-agent support or else will fundamentally change the flow > of OpenID (prevent relying-party-initiated sign-in)
Is that entirely true? There is a flow in the OpenID protocol that is hardly ever used, the association flow, that can be used. > Proposed Change > =============== > > Add a single, required, boolean field to the authentication > response that specifies whether or not the method the OP used > to authenticate the user is phishable. The specification will > have to provide guidelines on what properties an > authentication mechanism needs to have in order to be > "non-phishable." The field is just meant to indicate that the > authentication mechanism that was used is not a standard > "secret entered into a Web form." The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. > Benefits > -------- > > The proposal is trivial implement, it acknowledges that But it's not trivial to deploy! Since the proposed solution fundamentally changes the basic authentication payload, every single implementation would have to change. > Drawbacks > --------- > > It may be tricky to define what is meant by "non-phishable." And any such definition would probably change over time, too. > ... My overall problem is that I don't see how your proposal really solves phishing. Am I crazy? (It has happened before ;) Perhaps you're only concerned with the OP/RP relation? Your proposal is based on the OP adding an extra field into its authentication response, but in a phishing scenario, this OP would never even be involved in the authentication step. Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. This information may contain the phishing strength field you define above, but it can also contain something like a security profiles. (Yes, here I go again ;) It just seems to make sense to do it this way. 1. OPs that want to remain like today, can do so by accepting non-associationed authentication requests, or by not requiring the meta-information in the association request. 2. OPs that want to provide a stronger user story would require the assoc step + meta-info. The OP now becomes its own gate keeper: only good enough RP's will have acceptable profiles (perhaps cryptographically signed by a 'trusted 3rd party', or asserted via other reputational mechanisms), and therefore these RPs are the only ones that can authenticate. 3. in the same vein, the RP would only redirect to acceptable OPs. The RP decides what is an acceptable OP just as the OP decides what is an acceptable RP. 4. the user would still be out in the cold unless it is impossible to log in as a side-effect of an authentication step (as previously discussed on the list). Perhaps that entire 'log in when authenticating' flow should be stricken from the spec unless user's explicitly desires that behavior via some mechanism (like added params to the URL -- ugly, or a checkbox next to the URL input field -- questionable). Anyway, just my thoughts. Hans _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
