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
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
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 t
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
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
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
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
Dick Hardt wrote:
>>
>> But why deprecate support for redirects? I'd (still) like to see OpenID
>> implementations that do support browsers without JS turned on .
>
>
> As stated a number of times, because the payload is not big enough with
> GET redirects. It is with JS POST redirects.
>
> Open
Dick Hardt wrote:
>
> On 18-Nov-06, at 1:56 PM, John Kemp wrote:
>
>>> It is mentioned that the two methods may be composed, but I still don't
>>> see how the POST form submission can be automated (without JavaScript).
>>> Have I missed that part?
>
Johnny Bufu wrote:
>
>> My point is still that in general, implementations should be tolerant of
>> limited user-agents, and that means supporting functionality that
>> doesn't require JS.
>
> JS is not required; this is stated in the third paragraph of the
> 'Abstract' section.
>
> The 'HTML FO
/saml-bindings-2.0-os.pdf
(PDF)
Johnny Bufu wrote:
> On 17-Nov-06, at 7:17 PM, John Kemp wrote:
>
>>> - According to the HTTP RFC, user agents receiving a 3XX redirect in
>>> response to a POST request MUST NOT automatically redirect the
>>> request.
>>>
Dick Hardt wrote:
>>>
>>> Supporting payloads larger then 2K is a requirement.
>>
>> I guess I don't understand what this 2K limit is (and this is not
>> mentioned in the spec) - are you talking about limits on the URL size
>> when doing an HTTP GET?
>
> yes
>
>> If so, why not use POST instead?
Dick Hardt wrote:
> On 16-Nov-06, at 11:41 PM, Matt Pelletier wrote:
>> On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote:
>>
>>> Hi John
>>>
>>> So that a message can be more then 2K of data.
>>>
>>
>> Is it possible to update the language so 1) we don't deprecate HTTP
>> redirects and 2) the form red
l
this way. Can you perhaps illuminate the reasoning?
Cheers,
- John
Dick Hardt wrote:
> Hi John
>
> Would you provide examples of those browsers? Testing we did 2 years
> again indicated the JS redirect worked on all the platforms we tested on.
>
> -- Dick
>
> On
Hi,
Sorry I'm just reading this, but I just wanted to put in a point very
much in favour of NOT deprecating support for HTTP redirects in OpenID 2.0.
I'll note that requiring the user to press a 'submit' button to "push"
seems like a dodgy UI strategy. So then you require JavaScript to
produce a
ing for here: "authentication authority".
> This is not quite synonymous with "identity provider" in
> SAML-land, but it's close -- much the way that "relying party" and
> "service provider" are often close to the same thing. I'm n
penID, the identifier is often
(but doesn't have to be) created by the user.
Regards,
- John
Pete Rowley wrote:
> John Kemp wrote:
>> Drummond Reed wrote:
>>
>>> And it doesn't stop there. OpenID also supports OPs that
>>> ***have zero control over the user
Eve L. Maler wrote:
> On balance I prefer "identity provider" because
> it's intuitive in an English sense, it's used in several technology
> contexts (not just SAML and OpenID), and it avoids a terminological
> "branding" that would otherwise seem to suggest a conceptual
> divergence that does
Dick Hardt wrote:
>
> On 7-Nov-06, at 7:59 AM, John Kemp wrote:
>>
>> I don't believe that trust is a differentiator between SAML
>> specifications and OpenID Authentication specifications.
>>
>> It is AFAICT, in both cases, simply out of scope.
>
Dick Hardt wrote:
>
> On 6-Nov-06, at 11:46 AM, Recordon, David wrote:
>
>> I see both sides of this discussion. I think John is correct that the
>> role of an OP really is not that different than that of SAML's IdP. The
>> difference comes down to the trust model. I certainly think reputation
out giving a
converged message to users, developers, and purchasers of these
technologies.
Regards,
- John
>
> =Drummond
>
> -Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Recordon, David
> Sent: Monday, November 06, 2006 11:46 AM
&
Dick Hardt wrote:
>> It would be nice to see a clear definition of an OP in order to
>> determine the exact differences between such an entity and an IdP, but,
>> in the absence of such, some questions:
>>
>> Dick Hardt wrote:
>>> Thanks David! ;-)
>>>
>>> Patrick, as you point out, Identity Provi
Hi Dick,
It would be nice to see a clear definition of an OP in order to
determine the exact differences between such an entity and an IdP, but,
in the absence of such, some questions:
Dick Hardt wrote:
> Thanks David! ;-)
>
> Patrick, as you point out, Identity Provider is a well understood
>
Hello,
I think you need the ability for a user to change his identifier at the
RP (as George notes below) and also at the IdP. In addition, it should
be possible for the IdP to providing OpenID "forwarding" if the user
leaves for another IdP (perhaps the user will even pay for a forwarding
service
25 matches
Mail list logo
