[OpenID] TransparencyCamp and OpenID (U)

[Peter Williams]

I've been playing with dynamic SAML metadata modes recently. Instead of reading a signed XRDS file, peers dynamically  sign SAML metadata files. A SAML metadata file is only XML, and has extensions:  one of which could include an XRD or 2 (and thus get signed XRD off the ground). You can look at the SAML endpoints as funky XRD services, all expressed in their own markup.

The best thing that ever happened to SAML2 was openid - as [most of] the SAML crowd have largely got off their ultra high horse and been forced to match openid in simplicity and effectiveness (or be made irrelevant).





From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Chris Messina
Sent: Thursday, March 12, 2009 3:59 PM
To: Johannes Ernst
Cc: OpenID List
Subject: Re: [OpenID] TransparencyCamp and OpenID (U)

On Thu, Mar 12, 2009 at 4:37 PM, Johannes Ernst <jernst+openid.net<http://openid.net>@netmesh.us<http://netmesh.us>> wrote:

On Mar 12, 2009, at 9:46, Ben Laurie wrote:
I agree that all of SAML is way too large a pill to swallow but
there's no reason subsets that are usable cannot be defined, and,
indeed, have been.

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.

+1.

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.

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.

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.

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.

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?"

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.

To Johannes point: are we capturing these needed improvements anywhere, and if not, can we begin to?

Chris


--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com<http://factoryjoe.com> # diso-project.org<http://diso-project.org>
citizenagency.com<http://citizenagency.com> # vidoop.com<http://vidoop.com>
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090312/1a1639d4/attachment-0002.htm>