Anyway

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.

Data gov­ernance is the term used for know­ing what hap­pens to the data that is stored, par­tic­u­larly when that data has any PII (per­son­ally iden­ti­fi­able inform­a­tion), which the Open­ID IdP does. Using Open­ID isn’t the reas­on we keep this inform­a­tion; any regis­tra­tion sys­tem keeps at least some inform­a­tion about the people who have accounts on it, even if it’s only a name, email, and pass­word (or open­id iden­ti­fi­er). I thought it might be use­ful to oth­ers to see some of the basic steps that we went through when dis­cuss­ing how to pro­tect that PII, and some of the decisions we made on what data to keep and what not. If you’re set­ting up a regis­tra­tion sys­tem your­self, you may make com­pletely dif­fer­ent decisions, depend­ing on what inform­a­tion you’re keep­ing and what your regis­tra­tion sys­tem is being used for.

Obvi­ously, step 1 is to make someone respons­ible for fig­ur­ing it out. In our case, that per­son was me, with the grand title of “Data Stew­ard” in Sun­’s pro­cess. Yes, there’s a pro­cess to be fol­lowed and check­lists to be filled out, and people whose job it is to help us fig­ure it all out (the Chief Pri­vacy Office with Michelle Dennedy and her team). What you need to do is:

1. fig­ure out what data you need to have, wheth­er for tech­nic­al or policy reasons
2. fig­ure out who will need access to the data
3. fig­ure out how to pre­vent people access­ing the data who don’t need access
4. fig­ure out when you can des­troy the data
5. write the decisions up and make the inform­a­tion available

What data needs to be kept?

In this ser­vice, people can use fake names, but often choose to use their real ones. For com­pli­ance reas­ons, in case there needs to be an invest­ig­a­tion into an alleg­a­tion of wrong-doing by a user, we need to keep the employ­ee ID that was used to sign up for the open­id iden­ti­fi­er. Even after the open­id account is closed, the inform­a­tion is kept for a set peri­od of time to allow any prob­lems to sur­face. Yes, the users are warned about this dur­ing the regis­tra­tion process.

The web serv­er logs are in the Com­mon Log Format, which includes a record of the HTTP GET request from the con­sum­ing site (rely­ing party) ask­ing for authen­tic­a­tion of the open­id iden­ti­fi­er. This HTTP GET request includes the open­id iden­ti­fi­er and the site’s URL, thus allow­ing cor­rel­a­tion of who went where (though not what they did after log­ging in). This hap­pens with every Open­ID Iden­tity Pro­vider that has web serv­er logs, which I would guess is basic­ally all of them, so it’s cer­tainly not a prob­lem that is spe­cif­ic to Sun­’s ser­vice. Every Open­ID IdP could per­form such cor­rel­a­tions about their users. This is not neces­sar­ily a prob­lem, and some people would say that allow­ing people to see that this open­id iden­ti­fi­er was used in dif­fer­ent places allows repu­ta­tions to be built, but it also has pri­vacy implic­a­tions. I might not want my employ­er (or any­one else, for that mat­ter) know­ing what sites I vis­it, how often, and when. So on prin­ciple we mask the data, so that we can see how often a site is vis­ited, but not who’s doing the visiting.

Who needs access to the data?

If there is an alleg­a­tion of wrong­do­ing on the part of a user, then Cor­por­ate Com­pli­ance may need access to the inform­a­tion about whose open­id iden­ti­fi­er it is, and access to the web serv­er logs show­ing wheth­er the user actu­ally did log in to the web site in ques­tion. This data is only passed on after review of the alleg­a­tions by Sun­’s leg­al team.

Apart from that, sup­port per­son­nel need access to the open­id accounts to help people with things like for­got­ten pass­words (if they for­got to set a secret ques­tion), or delet­ing the account on a vol­un­tary basis. The user has to file a sup­port request using Sun­’s intern­al sup­port sys­tem, and the employ­ee ID of the per­son fil­ing the request has to match that of the own­er of the account. 

Engin­eer­ing may need access to some of the files for debug­ging. There is also a script that runs over the web serv­er logs and extracts records of which sites were vis­ited and when, dis­card­ing all inform­a­tion about who the user was who vis­ited that site.

Restrict access

Only a few people have access to the accounts; sup­port, engin­eer­ing, and me as data gov­ernance stew­ard. That access is con­trolled through oper­at­ing-sys­tem access con­trol. The same applies to the logs and every­one who has access has gone through train­ing to ensure they know the pri­vacy con­di­tions apply­ing to the use of the inform­a­tion (i.e., used only for debug­ging or sup­port once the user­’s iden­tity is veri­fied, as above).

As a side-note, to log in to my account on the machines, I have to log in to Sun­’s intern­al net­work, ssh from there to the machine I want to access and then log in with my stand­ard Sun cre­den­tials fol­lowed by a one-time pass­word that uses a chal­lenge-response mech­an­ism with a secret pass­phrase. Then I need to su to the appro­pri­ate user account, using yet anoth­er pass­word (of course).

Des­troy­ing Data

Once an account has been deac­tiv­ated, either because the employ­ee left Sun, or because they asked for it to be deleted, it remains inact­ive for 6 months. Once that time has passed, the account is deleted. The web serv­er logs are deleted auto­mat­ic­ally after 6 months. This time was chosen as it seemed to meet both the pri­vacy prin­ciples (delete as soon as pos­sible) and the cor­por­ate com­pli­ance prin­ciples (keep around for a reas­on­able length of time, just in case it’s needed).

Doc­u­ment­ing

Once it was all figured out, and reviewed by the pri­vacy spe­cial­ists in Sun, doc­u­ment­ing it was the easy part (just like writ­ing stand­ards, really, com­ing to the con­sensus is the dif­fi­cult bit). So we have inform­a­tion in the dis­claim­er that people need to agree to when they sign up for an account, the user policy, the FAQ, and the more form­al check­lists etc are avail­able from the Sun-intern­al pro­ject site. And people can always ask me, or email one of the mail­ing lists we have, if they have any questions.

This is the first of a series of posts on Sun Microsys­tem’s OpenID@Work ser­vice, which is an Open­ID Iden­tity Pro­vider avail­able for use by Sun employees.

[Update: I was asked what the pur­pose of these post­ings is — it’s simply to share our exper­i­ences in the hope that they’re help­ful to others.]

I was part of the team that put up the Open­ID Iden­tity Pro­vider. I wrote a lot of the pages, revamped Sun­’s default style sheet to work with the HTML I wanted on the pages, and took part in all the dis­cus­sions about policies and secur­ity. I’m also the “data stew­ard” for the IdP, respons­ible for ensur­ing that our policies regard­ing data pri­vacy are car­ried out. Giv­en that range of tasks in the pro­ject, it’s no sur­prise that when we div­vied up the areas for blog­ging, I picked the policy ques­tions, and oth­er people on the team will blog about oth­er areas. We’ll be cross-link­ing to each oth­ers’ posts, of course. For example, here’s Gerry­’s intro­duc­tion.

One of the good things about work­ing for Sun is that there are a lot of people with rel­ev­ant expert­ise, who also under­stand the need to be flex­ible. We spent a lot of time dis­cuss­ing the user policy with the people in the Chief Pri­vacy Office (who also let me write it in lan­guage people can under­stand), we had secur­ity experts review not only the deploy­ment but also the Open­ID spe­cific­a­tion (they’ll be blog­ging more on those aspects them­selves), and on the tech­nic­al side many people went out of their way to help. As an example, I spent most of one week­end try­ing to fig­ure out a weird MIME type prob­lem with the web serv­er with Murthy Chint­alapati (aka cvr), him email­ing “try this”, me email­ing back “nope, did­n’t work” until we even­tu­ally solved the prob­lem. In this series I’m going to be talk­ing about a few of the issues we dis­cussed, and how we resolved them. This is not to say we came up with per­fect solu­tions, or that they are neces­sar­ily applic­able to oth­er com­pan­ies or cir­cum­stances, but at the very least they will give you things to think about if you’re con­sid­er­ing a sim­il­ar project. 

We were heav­ily influ­enced by Sun­’s exper­i­ence with blog­ging, to the extent that many of our dis­cus­sions about “should we do this” were answered by “blogs.sun.com did it suc­cess­fully and here’s how”. The sim­il­ar­ity between the user policy doc­u­ments is no coin­cid­ence, for example.

If you’re look­ing for tech­nic­al doc­u­ment­a­tion on Sun­’s Open­ID sys­tem, try Hubert Le Van Gong’s infra­struc­ture descrip­tion and Open­ID @ Work — Archi­tec­ture.