Anyway

I’ve now fin­ished my cur­rent batch of post­ings about Sun­’s Open­ID IdP. Here’s a list­ing of the rel­ev­ant post­ings that the team has made. I’ll add new post­ings to this list as they’re pub­lished, or as I find them.

Pur­pose and Policies

• my Sun’s Open­ID IdP: Introduction
• my Sun’s Open­ID IdP: Busi­ness Purpose
• my Sun’s Open­ID IdP: Data Governance
• my Sun’s Open­ID IdP: Real vs Fake
• my Sun’s Open­ID IdP: Trust

Archi­tec­ture

• Hubert Le Van Gong’s Open­ID @ Work — Architecture
• Hubert Le Van Gong’s Open­ID @ Work — Infra­struc­ture Description

Deploy­ment

• Yvonne Wilson’s User-cent­ri­city, Trust: Tech­no­logy or Practice?
• Eve Maler­’s Sun Open­ID IdP: pro­tocol and imple­ment­a­tion review

Part of a series on Sun­’s OpenID@Work ini­ti­at­ive; see the intro­duc­tion for more context.

Trust is always an issue on the web. People don’t usu­ally even think about it, but they trust the DNS serv­er to point their browser at the right web site when they click on a link, they trust the web serv­er to serve up the right page, they trust their online bank to not broad­cast their cred­it card num­bers to the world, etc. etc. We as end-users can­’t do any­thing about most of those, but there are some things that we can do, such as not giv­ing bank­ing details to sites that don’t look like our bank’s, or only giv­ing out our social insur­ance num­bers when we really have to. Know­ing some of the issues and poten­tial prob­lems is import­ant — you want to veri­fy as much as pos­sible wheth­er your trust in the site is jus­ti­fied. So you don’t click on links in emails that don’t quite look right, and you check wheth­er the little “locked” sign is present (assum­ing your browser has­n’t been hacked). Lots of people don’t trust inter­net sys­tems with their per­son­al data at all, decid­ing that the advant­ages of online inter­ac­tions are out­weighed by the poten­tial dam­age if some­thing goes wrong (there’s that risk assess­ment again that I talked about in the Busi­ness Pur­pose post­ing of this series).

So what’s this got to do with Open­ID? Quite a lot, actually.

Open­ID is an untrus­ted pro­tocol, at least for ver­sion 1.1, which is the one we deployed on the Open­ID IdP, and it’s likely to be true for ver­sion 2.0 as well, although that isn’t fin­ished yet. As the Open­ID web site says: This is not a trust sys­tem.. Among oth­er things, you don’t know any­thing about the site you’re log­ging into, it might be genu­ine, it might be a phish­ing site, it might be some oth­er rogue site. And there’s no way cur­rently for the Iden­tity Pro­vider to know. In oth­er words, just because you can log into it with your open­id iden­ti­fi­er, does­n’t mean any­thing about what that site might do with any data or inform­a­tion you might give it. Which is one good reas­on why Sun­’s Open­ID IdP does not hand over inform­a­tion from the user­’s account to the con­sum­ing site (rely­ing party) unless the user agrees to it. You’re the per­son log­ging in, you can decide wheth­er to trust that site with any inform­a­tion, wheth­er that’s your open­id iden­ti­fi­er, or your name (pos­sibly fake) or email address. And Sun­’s sys­tem does­n’t ask for or store your date of birth, so if some site wants it (why would always be the right ques­tion to ask), feel free to answer cor­rectly or with some com­pletely ran­dom date (in fact, many pri­vacy advoc­ates say you should nev­er tell any web site your real date of birth if there’s any way of leg­ally avoid­ing it). Even hand­ing over your open­id iden­ti­fi­er to some site can cause prob­lems, if they then use it for pur­poses you did­n’t expect and don’t agree to. Since this is an opt-in sys­tem for per­son­al use, Sun would­n’t bear any liab­il­ity if you did fall prey to a phish­er or oth­er rogue while using your Sun open­id identifier.

The upshot of this is that Open­ID should­n’t be used for what are called high-value trans­ac­tions, at least in its cur­rent incarn­a­tion. High-value trans­ac­tions are things such as log­ging in to your bank­ing sys­tem, or releas­ing sens­it­ive per­son­al inform­a­tion such as your med­ic­al his­tory. Typ­ing “open­id phish­ing” or “open­id attacks” into your favour­ite search engine will give you some idea of the sorts of attacks that are cur­rently pos­sible. Some of these will be rel­at­ively easy to mit­ig­ate, and some aren’t really worth mit­ig­at­ing for the sorts of use cases that Open­ID was designed for, as they would make the res­ult­ing pro­tocol much harder to imple­ment and deploy. And let’s face it, the idea behind Open­ID was to have some­thing easy and light­weight to deploy that meets some, but not all, authen­tic­a­tion use cases.

Related art­icles include Steven Nel­son’s So you wan­nabe an Open­ID pro­vider?, Eve Maler­’s A Tinc­ture of Trust, and Yvonne Wilson’s Trus­ted Sources of Inform­a­tion. Simon Wil­lis­on has a slightly dif­fer­ent take in Design­ing for a secur­ity breach. And if you want a more form­al defin­i­tion of trust and some of the issues around it, try Trust Mod­el­ing for Secur­ity Archi­tec­ture Devel­op­ment.