2007 11:42 PM
> To: Granqvist, Hans
> Cc: OpenID specs list
> Subject: Re: Proposal: 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 w
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 instea
o go use 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, Dav
2007 12:01 AM
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 a
e: Proposal: 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 s
Recordon, David <[EMAIL PROTECTED]> schrieb/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 authent
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 to advertise if it supports a specific security
profile.
2) It would be future proof
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
>> au
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", rathe
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, beca
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
Johnny Bufu wrote:
> 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
>> re
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
Johnny Bufu wrote:
>
> On 2-Feb-07, at 12:04 PM, john kemp wrote:
>> Johnny Bufu wrote:
If the OP has stolen the user's credentials, it can just say
"phishable
= no" and pass its assertion regarding those credentials to the RP.
>>>
>>> And the RP (being now a legitimate one), will p
On 2-Feb-07, at 12:04 PM, john kemp wrote:
> Johnny Bufu wrote:
>>> If the OP has stolen the user's credentials, it can just say
>>> "phishable
>>> = no" and pass its assertion regarding those credentials to the RP.
>>
>> And the RP (being now a legitimate one), will perform verification on
>> the
Johnny Bufu wrote:
...
>>
>> If the OP has stolen the user's credentials, it can just say
>> "phishable
>> = no" and pass its assertion regarding those credentials to the RP.
>
> And the RP (being now a legitimate one), will perform verification on
> the assertion and will fail as it is not
On 2-Feb-07, at 11:22 AM, john kemp wrote:
> 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 ste
On 2-Feb-07, at 11:10 AM, George Fletcher wrote:
> That depends completely on what the authentication mechanism and
> even one time use tokens can be phish'd and used to compromise
> accounts. For example, the rogue site gets the SecurId and then
> immediately logs in on its own using the s
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 want
That depends completely on
what the authentication mechanism and even one time use tokens can be
phish'd and used to compromise accounts. For example, the rogue site
gets the SecurId and then immediately logs in on its own using the
supplied credentials. Those credentials establish a session
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
d
-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 C
+1
Phishing should have it's own entry in the security considerations
section.
Thanks,
George
john kemp wrote:
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 sectio
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
should
>
> -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 wro
> --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
>
> Gr
s actually 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:
>>
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
to:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
> Sent: Thursday, February 01, 2007 4:42 PM
> To: OpenID specs list
> Subject: Proposal: An anti-phishing compromise
>
> Hello,
>
> I've written up a proposal for an addition to the OpenID
> Authentication 2.0 specification that
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 f
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?
On 2/1/07, Paul Madsen <[EMAIL PROTECTED]> wrote:
> 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
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
au
On
Behalf Of Josh Hoyt
Sent: Thursday, February 01, 2007 1:42 PM
To: OpenID specs list
Subject: Proposal: An anti-phishing compromise
Hello,
I've written up a proposal for an addition to the OpenID Authentication
2.0 specification that addresses the phishing problem.
I've had some off-l
Hello,
I've written up a proposal for an addition to the OpenID
Authentication 2.0 specification that addresses the phishing problem.
I've had some off-list discussion of it, and I think it may strike the
right balance. Please provide feedback.
Josh
Background
==
We have had a lot of go
35 matches
Mail list logo
