Anyway

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 whether to let Sun employ­ees use fake or fic­ti­tious names, or whether to force the use of real names in what the OpenID 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 OpenID 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 OpenID “fullname”.

There are two com­pet­ing prin­ciples at work here, and mak­ing a decision as to whether to allow fake names and non-identity-revealing openid 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 whenever pos­sible. Since the OpenID ser­vice that we’re provid­ing is an opt-in, per­sonal ser­vice that Sun employ­ees do not need to use for any Sun busi­ness pro­cesses, there is no busi­ness reason 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 openid iden­ti­fi­ers). Even in the case of some store giv­ing a dis­count to a Sun employee, the store needs to know where to ship the item and which credit card to charge it to, but the OpenID IdP doesn’t need to know any of that inform­a­tion. The IdP veri­fies only that the user is a Sun employee, 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 shouldn’t use an openid iden­ti­fier 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 openid iden­ti­fier that might lead people to believe the user is someone they’re not. Since Sun is provid­ing the OpenID ser­vice, people might think that Sun is also guar­an­tee­ing the vera­city of inform­a­tion about the user other than the mere fact that they work for Sun (we’re not, Sun veri­fies only that the user is a Sun employee, 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 openid iden­ti­fier that doesn’t say any­thing about them. The OpenID IdP stores the inform­a­tion about which Sun employee signed up for that openid iden­ti­fier, so in the event of a prob­lem, we can trace it back. When a Sun employee leaves the com­pany, the openid 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 openid iden­ti­fier, 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 server logs for 6 months; since these con­tain the records of which openid iden­ti­fier 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 another 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 openid iden­ti­fier is stored for com­pli­ance reas­ons. Telling the user that we know who they are and what their openid iden­ti­fier 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 reason why that should be any dif­fer­ent for Sun employ­ees using the OpenID 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­claimer 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-centricity, Trust: Tech­no­logy or Prac­tice?.