<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">I like the idea of URIs for
common "authentication methods"... but I'm still not sure how this
helps with the phishing problem. As you pointed out John, the issue is
a rogue RP redirecting to a rogue OP. So the rogue OP just steals the
credentials and returns whatever it wants. If there is no solution
based on the other constraints for the protocol (no client side code,
RP initiated, etc), it just needs to get documented very clearly in the
security considerations section. Currently, issues around phishing are
only lightly mentioned in section 15.<br>
</font><font face="Helvetica, Arial, sans-serif"></font><font face="Helvetica, Arial, sans-serif"><br>
Thanks,<br>
George<br>
</font><br>
john kemp wrote:
<blockquote cite="mid45C33EA1.3070503@mac.com" type="cite">
<pre wrap="">Recordon, David wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.?.
</pre>
</blockquote>
<pre wrap=""><!---->
If you were to define a URI for common "authentication method" values,
could this value not be returned, simply, in the protocol?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
<blockquote type="cite">
<pre wrap="">--David
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:specs-bounces@openid.net">specs-bounces@openid.net</a> [<a class="moz-txt-link-freetext" href="mailto:specs-bounces@openid.net">mailto:specs-bounces@openid.net</a>] 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:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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."
</pre>
</blockquote>
<pre wrap="">The receiver should decide what is 'non-phishable', not the sender, so
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">it would be better if the OP just states what mechanism was used,
perhaps.
</pre>
</blockquote>
<pre wrap="">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.)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Benefits
--------
</pre>
</blockquote>
</blockquote>
<pre wrap="">...
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">this step can include an exchange of meta-information between OP and
RP.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:specs@openid.net">specs@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@openid.net">specs@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
</body>
</html>