Part of a series on Sun’s OpenID@Work initiative; see the introduction for more context.
Probably the biggest discussion we had in the entire policy discussion was whether to let Sun employees use fake or fictitious names, or whether to force the use of real names in what the OpenID simple registration extension calls the fullname. The policy discussion has value outside of the narrow scope of an OpenID IdP, and the discussions we had reflect the importance of the issue for any sort of identity management system.
Note on terminology: in this post, I’ll use the term “name” to mean the OpenID “fullname”.
There are two competing principles at work here, and making a decision as to whether to allow fake names and non-identity-revealing openid identifiers depends on which is considered more important. The argument for allowing fictitious names is based on privacy, and the principle that any time you can allow the user to retain privacy, you should. Storing Personally Identifiable Information (PII) should be avoided whenever possible. Since the OpenID service that we’re providing is an opt-in, personal service that Sun employees do not need to use for any Sun business processes, there is no business reason that requires the use of their real names (auditing accesses to certain files, for example, would require knowing the user’s real name, so these processes can’t use these openid identifiers). Even in the case of some store giving a discount 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 information. The IdP verifies only that the user is a Sun employee, nothing more. So the privacy advocates are in favour of allowing fake names, email addresses that aren’t Sun addresses, and storing as little information as possible. Of course, if someone wants to be really private, they shouldn’t use an openid identifier from Sun, as that divulges the piece of information that they are a Sun employee.
The case against allowing the use of fake names is a security and liability one. If someone can use a fake name, that means they can also use someone else’s name or an openid identifier that might lead people to believe the user is someone they’re not. Since Sun is providing the OpenID service, people might think that Sun is also guaranteeing the veracity of information about the user other than the mere fact that they work for Sun (we’re not, Sun verifies only that the user is a Sun employee, nothing else). Such impersonation could cause reputation damage that could take some time to repair, particularly if the user does something stupid or illegal.
The solution we came up with was a compromise. Users can choose a fake name, a non-Sun email address, and an openid identifier that doesn’t say anything about them. The OpenID IdP stores the information about which Sun employee signed up for that openid identifier, so in the event of a problem, we can trace it back. When a Sun employee leaves the company, the openid account is made inactive. It’s deleted after 6 months. This way there’s a time gap if someone else wishes to use the same openid identifier, and 6 months is a reasonable amount of time to keep such records in case there’s a problem. We also keep the web server logs for 6 months; since these contain the records of which openid identifier visited which site (though not where they went or what they did once there) these are only visible for compliance reasons (I’ll talk more about the data governance in another post). And finally, the user policy states specifically that impersonation is not allowed, and that information about who signed up for each openid identifier is stored for compliance reasons. Telling the user that we know who they are and what their openid identifier is may help prevent problems, 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 problems. Sun’s experience with bloggers has shown that people do take their responsibilities as Sun employees seriously, and are careful what they say and how they say it, and we saw no reason why that should be any different for Sun employees using the OpenID service. Of course, there’s no way of making sure that people really do read the policy, just like there’s no way to make people read the licences for software packages that they install, but at least the information is available for those who care to look. And to sign up for an account they have to agree to a disclaimer that contains the most important 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: Technology or Practice?.