OpenID

http://5px45jjgc6k0.roads-uae.org/

OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do-with a URI (also called a URL or web address). Since URIs are at the very core of Web architecture, they provide a solid foundation for user-centric identity.

This is a decentralized identity system, but one that's actually decentralized and doesn't entirely crumble if one company turns evil or goes out of business.

One of the benefits of OpenID, is that you are able to have some way to identify a casual poster by an outside source - for example, if a debian developer wanted to comment on TWikiOnDebian, they could do so without needing to register a throwaway identity on TWiki.org. Or, using the Registration Extension, it can be used to identify a TWiki account with a users website / blog, and pre-fill in the TWikiRegistration information (or even sync from there if it changes?).

Keep in mind that OpenID was developed to create an informal identity linking possibility between blogs. When you're commenting on someone's blog post, its rather odd to have to create YetAnother account (that you'll loose or forget about) and to have to think of YetAnother password that you're willing to share with the world.

There is also SXIP (http://468466ugr2f0.roads-uae.org/)

Discussion

A Security Practitioners view

These are my obervations from the POV of someone professionalyy and daily involved in corporate security policy and managenent (i.e. I'm not a pen-tester). I'm not going to address the techncial innards, just the "managent overview". Take this as if a client asked me if his firm should adopt one of these to manage his telecommuting workers.

OpenID

This does require several servers to talk to each other during sign on, so is relatively sensitive to outages. Gratuitous dependencies, I'd say. (See more ranting about that below.)

• Only has provision for logging you in automatically, but does not ensure your identity in a general fashion.

• Has no provision for expiration dates or group associations, so can't accomodate roles. Unless you set up a very specific "home server" where this is also set up. In which case why are you considering using this facility?

In short, it's not really an identity server, and they say so. It's most certinly not a trust system, which is needed to address issues of corporate telecommuting management and even WikiSpam.

SXIP

I was taken aback by getting a warning about expired SSL cert when opening how-sxip-works.pdf. That's not a good sign for a company that bases its business on trust and security, is it?

Skimming the above document, I see "Member" sites (any clients, I would suppose), "Home sites" (TWiki.org, I guess), "Network Root" site (SXIP?) and finally the user browser. Whoa.

This is one fragile house of cards. Everything has to be online and ready. Everyone has to interface. And this is what I don't like about gratuitous use of "service oriented architectures". They're great when you must do things in online "realtime" (note below) distributed transactions, but they're a great big iron ball around your ankle in the sense that everything has to work all the time, else you're screwed.

As a general principle, if you can do operations in an asynchronous, disconnected, fashion, you're way ahead in ease of implementation, resilience, scalability, and functionality. And security, btw. (Exactly how, is an excercise for another opportunity.)

When I look at a design and see two Internet servers talking to each other, synchronously, I'm worried. When I see three, I run away screaming. Too fragile. Too many opportunities for things like spoofing attacks.

Additionally, SXIP is meant for browsers. Fine in itself, but if you have an unsupported browser, or you want to do your operation through email, then what?

I'm not even sure it can handle expiration dates (maybe it can), or trusted, but anonymous, entities (I really don't think it can).

Finally, it's a commercial third party, and as we all know, they come and they go and they're not for free. Would the TWiki project and other (voluntary, open source) efforts be prepared to enter into commercial agreements with vendors?

-- AntonAylward - 13 Oct 2005

SvenDowideit is working on an OpenIDUserContrib for TWiki that will make TWiki able to be either a Consumer (remove&delegate TWikiRegistration and User handling) and a Server (Registered TWikiUsers automatically get an OpenID identity served by the TWiki System).

The first is awkward, as the only definatly unique identifier is a URL (which makes twiki render usernames poorly), so the final solution may need to be tied to some core changes - like AddTWikiAdminUser.

The main issue revolves around the hardcoding of WIKINAME to have to be a TWikiTopic (see the logged in user link at the top of every page)

-- SvenDowideit - 07 Feb 2007

FYI Only: According to this news OpenID is suddenly about to become far more popular - and perhaps a lot more important.

-- MichaelCorbett - 20 Jan 2008

Now that the User mapping refactoring in TWiki 4.2.0 is done, I have released the first OpenID Consumer Contrib for TWiki - OpenIDUserContrib.

-- SvenDowideit - 12 Feb 2008

Great! For combined login options we could add a tab to the login panel for OpenID.

-- ArthurClemens - 12 Feb 2008

OpenID is sexy. Cool that TWiki supports it already.

-- MartinSeibert - 13 Feb 2008

Please note that OpenIdRpContrib (supports OpenID 1.1 and 2.0) has superseded OpenIDUserContrib (supports only OpenID 1.1).

-- IanKluft - 2010-04-28