Proposal: An anti-phishing compromise

[john kemp]

Recordon, David wrote:
> 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.?.

If you were to define a URI for common "authentication method" values,
could this value not be returned, simply, in the protocol?

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

Agreed. If AQE is not mandated, however, I think that the original idea
of allowing the OP to make a statement about the authentication method
in the actual protocol is still a good one.

If you start with a simple URI, returned directly in the protocol, can
this not be linked to the equivalent statement in the AQE specification?

- John

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