Hi,
This is a really minor thing I just spotted due to leaving my browser
open on the relevant part of the spec and coming back to it later. :)
The normalization table in appendix A.1 lists several examples of the
normalization of URIs. The last few examples are as follows:
http://exampl
Just a suggestion which may be impractical due to URL size limit:
Instead of requiring a boolean in the response, how about adding an:
optional, general purpose, comma separated list of identifiers
with support for custom and maybe signed identifiers as well.
For example:
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 no
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
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 PROTECT
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
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 Of
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
11 matches
Mail list logo