<div class="gmail_quote">On Thu, Mar 12, 2009 at 4:37 PM, Johannes Ernst <span dir="ltr"><jernst+<a href="http://openid.net">openid.net</a>@<a href="http://netmesh.us">netmesh.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Mar 12, 2009, at 9:46, Ben Laurie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree that all of SAML is way too large a pill to swallow but<br>
there's no reason subsets that are usable cannot be defined, and,<br>
indeed, have been.<br>
</blockquote>
<br></div>
I would love it if somebody was actually starting a working group (in Apache they would call it "incubate") that would propose all the gory details of a "more secure" form of OpenID that still fits into the decentralized, discovery-based OpenID architecture. Only then can we tell what may or may not be the better approach.<br>
</blockquote></div><div><br></div>+1.<div><br></div><div>I'm not the person to do it, simply because I don't have the background, but I'm really no longer interested in the discussion that "OpenID isn't good enough for high-value transactions". Tell that to the Japanese who are already pushing payments over/with OpenID.</div>
<div><br></div><div>If it's got security issues, as Johannes said, we should collect a list of them as issues and go about finding suitable solutions, best practices or explanations for WONTFIX-type resolutions.</div>
<div><br></div><div>The reality is, people will use OpenID in all kinds of cases that we can't be able to anticipate; SAML (again, from what I hear — being mostly SAML ignorant) is that SAML requires sysadmins to maintain and more and more organizations want to move away from that kind of model. </div>
<div><br></div><div>HTTP succeeds because (among many, many other reasons) you can jack up your service to things like S3 once you realize that you're not really saving any money as a small to mid-sized organization running a server farm. The same thing applies to user authentication and security over time, where it'd be nice to have a fairly straight-forward, interoperable protocol for doing authentication. From what I've heard, I don't question the sophistication or technological pedigree of SAML; it's just that when I hear people say that OpenID isn't secure enough, it's like saying we should all switch to RDF because it's OMG-so-much-better.</div>
<div><br></div><div>I don't doubt that either are, if your primary concerns in life are centered around the problems that these technologies solve; but for folks for whom security isn't necessarily their only responsibility, and they no longer have an IT department or staff to manage a SAML solution and look to OpenID as a potential answer — saying that OpenID isn't secure enough doesn't seem to be an answer to the question "well, then what do I use?"</div>
<div><br></div><div>How do we get from where we are today to a point where OpenID really does solve a large number of security problems — if only because it hopefully means fewer passwords in use overall — and fewer unique accounts to maintain? Look, let's take another look at this: it isn't just "is OpenID by itself secure?" It's: "given how OpenID changes the makeup of and behavior in the overall ecosystem, are we now more secure than we were before?" In general, I think the answer is yes, though of course good security necessitates vigilance and constant improvement.</div>
<div><br></div><div>To Johannes point: are we capturing these needed improvements anywhere, and if not, can we begin to?</div><div><br></div><div>Chris<br><br clear="all"><br>-- <br>Chris Messina<br>Citizen-Participant &<br>
Open Web Advocate-at-Large<br><br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br><a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>