Proposal: An anti-phishing compromise

[Recordon, David]

I think we all agree that talking about the method used is far more
useful, though with this proposal we're really trying to balance it with
simplicity in the authentication protocol itself.  Maybe it is better to
phrase the discussion around if the user provided a secret (password) to
the OP or not to authenticate versus talking about phishing directly.?.

I'd hope that this parameter in the auth spec really helps bring the
discussion around to the Assertion Quality Extension and that it be
implemented to provide the more robust metadata such as what type of
authentication was actually preformed.

--David 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of john kemp
Sent: Thursday, February 01, 2007 7:13 PM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise

Granqvist, Hans wrote:

>> 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.

Agreed. A statement as to the "phishability" or not seems to be too
vague to be useful. A simple statement of the authentication method used
would seem to give the same effect, while providing potentially useful
information (assuming the RP trusts statements from the OP at all.)

> 
> 
>> Benefits
>> --------

...

> 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.

How does the association step between OP and RP change the relationship
between the OP and the user (agent)?

I thought the attack we were considering is when a rogue RP directs the
user agent to a rogue OP, who then steals the user's credentials? How is
that affected by the rogue RP and rogue OP "associating"?

- John
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs