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.

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

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.