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. 


specs mailing list

Reply via email to