Wednesday, March 30, 2005

Network Personal Identity

All of the discussion of identity theft and spam and spoofing, coupled with my interest in what I've called a Distributed Virtual Personal Computer (DVPC), lead me to believe that there really is a real need for a Network Personal Identity (NPI). Some people will of course still insist on anonymity, but for people who really do want to store data and access personalized services in a networked environment, a Network Personal Identity is an absolute requirement.

There are lots of ideas and techniques and gimmicks floating around, but maybe it's simply time to step back and try to take a big picture view of the requirements.

Requirement number zero is that we absolutely do not wish to be laying the groundwork for "big brother" or "big business" to further exploit "the common man". The goal is to lower barriers to pursuing freedom and access, not enable control of larger organizational entities. There probably does need to be some form of authorized law enforcement access, but the mehcanism should be sufficient opaque and cumbersome so that it cannot be easily abused.

For starters, I'd say that there is no reason why a Network Personal Identity (NPI) would have to be directly linked to a person's real-world identity. Each of us should be able to exercise our own choice of how much to selectively disclose about our identity. In fact, we each may want to have any number of distinct NPIs to meet different needs and to further enhance our sense of security.

I'm not sure if biometrics are "the answer" or just one ingredient, or even of any value, but it is an area to be considered.

Certainly a NPI should not be stored on a centralized server, and certainly not on any service vendor's server. Rather, there should be a new class of service, the identity service, of which there can be many providers, and which users and vendors of services could mutually validate. In many cases, it shouldn't even be necessary for a vendor or service provider to know anything about your personal details, other than to verify aspects that are relevant to the service being rendered. A user, at their discretion, might opt to disclose details to provide more personalized service, but disclosure should never be a requirement.

I'm not thinking that a NPI would be a fixed identifier (with password), but more of a dynamic id, possibly using an electronic equivalent to a "one-time pad" with each id good for only one transaction and requiring that the software at the user location request the one-time id from a selected identity server, and then a target service would do a one-time validation through the same cluster of identity servers, and then that id would forever be invalid. This is just one idea. I'm sure there are others that may be far superior. My goal is simply to set a minimum threshold for quality and security.

Plenty more thinking is required. This is just a starting point, but having the right jumping off point can make or break any project.

My DVPC concept does in fact need a robust network identity for authentication and validation of access. I suspect that what's good enough for protecting my data on multiple remote DVPC data servers might be good enough for a lot of people and services.

-- Jack Krupansky

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home