[OpenID] Backwards Compatibility

[Andrew Arnott]

Of course.  But perhaps the useful question could phrased "are there any OPs
that don't support HTTPS that people would cry about not working any more?"
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Tue, Mar 17, 2009 at 2:28 PM, Allen Tom <atom at yahoo-inc.com> wrote:

>  I'd like to remove the requirement for SSL enabled OPs to support DH. Are
> there any OPs that don't support HTTPS?
>
> Allen
>
>
>
> Andrew Arnott wrote:
>
> Why remove DH key exchange?  Wouldn't the remove the capability for arbitrary
> RPs and OPs to establish an association unless the OP supported SSL? Key
> word is arbitrary.  I'd hate to lose the ability to securely exchange a
> secret with an OP that doesn't expose an SSL OP endpoint.
>  DNS poisoning attacks are possible without SSL, I know.  But sniffing a
> password in plaintext is so much easier than poisoning someone's DNS server,
> especially if said DNS server has mitigations against poisoning already. So
> it seems there are legitimate uses for OPs without SSL support, but that
> goes completely away without DH.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>
> On Mon, Mar 16, 2009 at 10:48 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>
>> +1
>>
>> I'd be very happy to see 1.1 clearly deprecated, and in an ideal world,
>>  existing 2.0 implementations would already 2.1 compliant.
>>
>> If anything, I'd like to see things removed from 2.0, such as the DH key
>> exchange.
>>
>> The 2.1 spec should mostly clarify ambiguous portions of the 2.0 spec,
>> especially wrt to delegation and directed identity.
>>
>> Allen
>>
>>
>>
>> Martin Atkins wrote:
>>
>>> David Recordon wrote:
>>>
>>>> Hey Carsten,
>>>> I agree with you.  It's time to make sure that 1.1 is clearly deprecated
>>>> and that everyone implements 2.1 once it is completed.
>>>>
>>>>
>>> Is there some compelling reason not to make 2.1 a superset of how 2.0 is
>>> implemented today? (That is to say, not a superset of the spec as written,
>>> but a superset of the parts of it that are implemented and the errata.)
>>>
>>> I think in an ideal world every existing, well-behaved 2.0 implementation
>>> would already be a fully-compliant 2.1 implementation. This implies a
>>> research-driven approach involving the studying of existing implementations;
>>> there should be a high barrier to specifying anything that disagrees with an
>>> existing, well-behaved implementation.
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090317/6b34845b/attachment-0002.htm>