Recordon, David wrote:
I agree that things like age should be in an extension, though I think
this single piece of data is useful in the core protocol. I'm sure the
exact definition of phishing resistant will come back to bite us in
sometime in the future, but lets deal with it then instead
mandated by the spec but every
worthwhile OP
does it.
My $0.02.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Sunday, February 04, 2007 11:42 PM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: Proposal: An anti
: An anti-phishing compromise
On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote:
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
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise
Hi Josh
A few comments:
1) I think this should be an extension following previous arguments that
AuthN Age should be an extension. (AuthN Age would be another good item
in this extension) This allows an OP
a better OP. An OP
lying only hurts its users.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Friday, February 02, 2007 5:01 AM
To: specs@openid.net
Subject: Re: Proposal: An anti-phishing compromise
Recordon, David [EMAIL
On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote:
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
PROTECTED] 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
Hi Josh,
In addition to the protocol parameter that you have proposed, I'd hope
that we can add something like what you wrote below as part of the
security considerations section of the OpenID 2.0 Auth specification, as
this text seems to capture quite succinctly the issues that RPs and OPs
On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
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.
In this case, the
Johnny Bufu wrote:
On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
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.
In
On 2-Feb-07, at 12:25 PM, john kemp wrote:
If the authentication mechanism is phishable, a good OP is
supposed to
say phishable=yes. Otherwise it is cheating the user's trust.
Yes, RPs will just have to trust assertions from an OP. But with
all due
respect, I just don't see how the
On 2/2/07, john kemp [EMAIL PROTECTED] wrote:
Don't get me wrong - I think it's a good idea for the OP to make a
statement about the authentication method used (although I would prefer
it to say something like
authn_method=urn:openid:2.0:aqe:method:password, rather than
phishable=yes). That
On 2-Feb-07, at 1:53 PM, Josh Hoyt wrote:
Therefore, I think that the authentication mechanism is (or
at least can be) independent from whether the authentication channel
is phishable.
.. or, pushing it a bit further, I could ask/configure my OP to
always issue phishable=no for me, because
Josh Hoyt wrote:
On 2/2/07, john kemp [EMAIL PROTECTED] wrote:
Don't get me wrong - I think it's a good idea for the OP to make a
statement about the authentication method used (although I would prefer
it to say something like
authn_method=urn:openid:2.0:aqe:method:password, rather than
I'm in support of this idea. I think a single parameter in the OP's
response will pave the path to integrate solutions to the phishing
problem and scales up to the AQE extension as it is re-worked.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Hi Josh, do I understand correctly that the motivation for your proposal
is not 'fix' the phish problem, but to simply hilite it so that RPs will
begin to put pressure on their OPs to move to something beyond passwords?
If this is the case, perhaps allowing an SP to add it to its request for
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?
sorry, trying to straddle worlds/terminology
OpenID SAML
RP == SP (Service Provider)
OP == IDP (Identity Provider)
Josh Hoyt wrote:
On 2/1/07, Paul Madsen [EMAIL PROTECTED] wrote:
Hi Josh, do I understand correctly that the motivation for
I think that it is an excellent idea since it allows us to have it both ways.
We can continue to offer backwards compatibility with legacy infrastructure
without compromising the strength of the strongest schemes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
preformed.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
20 matches
Mail list logo
