[OpenID] Backwards Compatibility

[Peter Williams]

Hmm. Now I object.

That presupposes (yet again) that only well known OPs are of any consequence.

What SSL taught us is that what really matters is the a half billion SSL domains that hardly anyone knows about (they are almost all wifi routers, with a self-signed cert for https admin)

All depends on what the mission of openid is. 10 giant megaOPs, or the little guy (of which there  are a lot).



From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Tuesday, March 17, 2009 2:52 PM
To: Allen Tom
Cc: general at openid.net
Subject: Re: [OpenID] Backwards Compatibility

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<mailto: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<mailto: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<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general at openid.net<mailto: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/5f7218e9/attachment-0002.htm>