<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The DIY ethic of OpenID is also one of its main strengths, as as
Johannes pointed out, there are plenty of scenarios where someone might
want to run an OP without HTTPS. For instance, I'm not willing to pay
the price to support HTTPS on my own personal domain.<br>
<br>
As I mentioned earlier, I only brought up DH because I felt that it
could be something that could be removed from the core spec, with the
goal of making the spec lighter. Given the discussion so far, it looks
like there are good reasons for keeping DH in the spec.<br>
<br>
Allen<br>
<br>
<br>
Andrew Arnott wrote:
<blockquote
cite="mid:216e54900903191139n5ca5e87bkaed0cd2bff348e4f@mail.gmail.com"
type="cite">Well, the spec allows for session types to be implemented
that are not defined in the spec. If DH is ever removed from the
OpenID spec, I hope the spec can reference another DH spec that keeps
it alive as a spec that people can optionally implement.
<div><br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire<br>
<br>
<br>
<div class="gmail_quote">2009/3/19 Allen Tom <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">If we consider OAuth's secret
exchange mechanism for HMAC-SHA1 sigs,<br>
<ul>
<li>OAuth Service Providers usually issue a Consumer Secret to
the
developer, without any input from the developer. (hopefully via HTTPS)<br>
</li>
<li>OAuth Request Token and Access Token secrets are issued by
the
Service Provider to the Consumer (also, hopefully via HTTPS), without
any input from the Consumer</li>
</ul>
Returning cleartext secrets via HTTPS would be consistent with OAuth.<br>
<br>
Although DH on top of SSL is safer than cleartext and SSL, is the
overhead of having the spec discuss DH worth it? If the OP is unable to
generate a strong secret on its own, or if the transport layer between
the RP and OP cannot be secured using HTTPS, then arguably the entire
system has issues.<br>
<br>
I only mention DH, not because I have an issue with DH, but because one
of OpenID's most desirable traits is its relative simplicity. The spec
is pretty straightforward, and it's not all that hard to implement.
Sites that want a richer (and more complicated) SSO protocol standard
have alternatives that are already in production and are widely used.<br>
<font color="#888888"><br>
Allen</font>
<div class="im"><br>
<br>
Ben Laurie wrote:<br>
<blockquote type="cite">
<pre>Ah. I see.
So, I am going to be lazy, because I have not checked the spec, but
its considered good practice when establishing a shared secret for
both sides to contribute to that secret. Is that true for the
cleartext secret?
</pre>
</blockquote>
</div>
</div>
<br>
_______________________________________________<br>
general mailing list<br>
<a moz-do-not-send="true" href="mailto:general@openid.net">general@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>