Year: 2007

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.

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

Prob­ably the biggest dis­cus­sion we had in the entire policy dis­cus­sion was wheth­er to let Sun employ­ees use fake or fic­ti­tious names, or wheth­er to force the use of real names in what the Open­ID simple regis­tra­tion exten­sion calls the fullname. The policy dis­cus­sion has value out­side of the nar­row scope of an Open­ID IdP, and the dis­cus­sions we had reflect the import­ance of the issue for any sort of iden­tity man­age­ment system.

Note on ter­min­o­logy: in this post, I’ll use the term “name” to mean the Open­ID “full­name”.

There are two com­pet­ing prin­ciples at work here, and mak­ing a decision as to wheth­er to allow fake names and non-iden­tity-reveal­ing open­id iden­ti­fi­ers depends on which is con­sidered more import­ant. The argu­ment for allow­ing fic­ti­tious names is based on pri­vacy, and the prin­ciple that any time you can allow the user to retain pri­vacy, you should. Stor­ing Per­son­ally Iden­ti­fi­able Inform­a­tion (PII) should be avoided whenev­er pos­sible. Since the Open­ID ser­vice that we’re provid­ing is an opt-in, per­son­al ser­vice that Sun employ­ees do not need to use for any Sun busi­ness pro­cesses, there is no busi­ness reas­on that requires the use of their real names (audit­ing accesses to cer­tain files, for example, would require know­ing the user­’s real name, so these pro­cesses can­’t use these open­id iden­ti­fi­ers). Even in the case of some store giv­ing a dis­count to a Sun employ­ee, the store needs to know where to ship the item and which cred­it card to charge it to, but the Open­ID IdP does­n’t need to know any of that inform­a­tion. The IdP veri­fies only that the user is a Sun employ­ee, noth­ing more. So the pri­vacy advoc­ates are in favour of allow­ing fake names, email addresses that aren’t Sun addresses, and stor­ing as little inform­a­tion as pos­sible. Of course, if someone wants to be really private, they should­n’t use an open­id iden­ti­fi­er from Sun, as that divulges the piece of inform­a­tion that they are a Sun employee.

The case against allow­ing the use of fake names is a secur­ity and liab­il­ity one. If someone can use a fake name, that means they can also use someone else’s name or an open­id iden­ti­fi­er that might lead people to believe the user is someone they’re not. Since Sun is provid­ing the Open­ID ser­vice, people might think that Sun is also guar­an­tee­ing the vera­city of inform­a­tion about the user oth­er than the mere fact that they work for Sun (we’re not, Sun veri­fies only that the user is a Sun employ­ee, noth­ing else). Such imper­son­a­tion could cause repu­ta­tion dam­age that could take some time to repair, par­tic­u­larly if the user does some­thing stu­pid or illegal.

The solu­tion we came up with was a com­prom­ise. Users can choose a fake name, a non-Sun email address, and an open­id iden­ti­fi­er that does­n’t say any­thing about them. The Open­ID IdP stores the inform­a­tion about which Sun employ­ee signed up for that open­id iden­ti­fi­er, so in the event of a prob­lem, we can trace it back. When a Sun employ­ee leaves the com­pany, the open­id account is made inact­ive. It’s deleted after 6 months. This way there’s a time gap if someone else wishes to use the same open­id iden­ti­fi­er, and 6 months is a reas­on­able amount of time to keep such records in case there’s a prob­lem. We also keep the web serv­er logs for 6 months; since these con­tain the records of which open­id iden­ti­fi­er vis­ited which site (though not where they went or what they did once there) these are only vis­ible for com­pli­ance reas­ons (I’ll talk more about the data gov­ernance in anoth­er post). And finally, the user policy states spe­cific­ally that imper­son­a­tion is not allowed, and that inform­a­tion about who signed up for each open­id iden­ti­fi­er is stored for com­pli­ance reas­ons. Telling the user that we know who they are and what their open­id iden­ti­fi­er is may help pre­vent prob­lems, at least that’s the hope.

If the policy is abused, then we may have to change it, but so far we don’t know of any prob­lems. Sun­’s exper­i­ence with blog­gers has shown that people do take their respons­ib­il­it­ies as Sun employ­ees ser­i­ously, and are care­ful what they say and how they say it, and we saw no reas­on why that should be any dif­fer­ent for Sun employ­ees using the Open­ID ser­vice. Of course, there’s no way of mak­ing sure that people really do read the policy, just like there’s no way to make people read the licences for soft­ware pack­ages that they install, but at least the inform­a­tion is avail­able for those who care to look. And to sign up for an account they have to agree to a dis­claim­er that con­tains the most import­ant parts of the policy as well, so there’s some hope that they will read it.

A related post is Yvonne Wilson’s User-cent­ri­city, Trust: Tech­no­logy or Prac­tice?.