I’ve written and rewritten this post too many times … all the way
through Christmas and the New Year. It’s time to post it and get
on to the next … 
It is very cool to see all of the people that are joining this
conversation about Identity. And I do like the “lead” that Kim is
taking in driving towards an actual software solution … actual
implementations. I have a few comments on his Fouth Law of
Identity, however I wanted to throw out this Axiom to address his
request:
I would like to hear more of Scott Lemon’s ideas about how philosophical thinkers can help us figure out ways we can write software that intuits - this is my word and perhaps it is too rhetorical - our identity decisions for us… [Kim Cameron’s Identity Weblog]
I’ll throw out my next Axiom … and then some scenarios on how things might occur:
I posit that identity is exchanged in transactions that occur within a context of trust and authentication.
So what does this mean? It means that we are constantly
exchanging identity information throughout each and every day. Most of
these exchanges are so transparent to us … completely implicit and
automatic. The world around us is filled with “providers” and
“consumers”. We ourselves are both … at the same time. We
have, over the years, also developed a keen sense of “awareness” of the
providers of services that we want … or how to find them. We
have also developed a long list of “trusted sources” of services. This
sets up the basic foundation for an identity transaction, and it’s
context.
I move to a new town, and I
want to rent an apartment. I find some apartments that
meet my requirements, and then visit the apartment complex. They
hand me a rental application, and I fill out all of the
information. I give it back to them … a day later they call me
and indicate that I have been accepted as a tenant. I then visit
the apartments again, sign more papers and get the keys.
In this scenario, what exactly is going on with respect to
identity? This is really no different from the Polycomm and Cell
Phone scenario that Kim has been using.
The rental agreement is actually the interesting transaction to
me. It touches on most of the core aspects of identity
transactions. First, a rental agreement is actually a request for
identity information. More importantly, it is a request for pieces of
my identity along with the
references, or communities, that can be used to “authenticate” that
identity
information. They want to know how much money I make, and also
where I am working. They want to know the last three places that I
lived or rented. They can choose to trust the information I
provide, or more likely they will “verify the authenticity” of that
information with my references.
I have the option of locating
trusted sources and gathering background information on the apartment
complex. The apartment complex gives me a rental application to
gather my background identity information and verifying my
“trustworthiness.” In most cases, I simply “trust” the apartment
complex, and do little to look at their reputation. The apartment
complex uses a process to authenticate the identity information that I
have provided with their own trusted sources.
Some of my information is provided with “implicit” references to the
“definitive authorities” of that information. My Social Security
number, or drivers license state and number. Both of these are
understood to represent information that may be authenticated with
government agencies. Likewise, there are attributes that allow the
apartment complex to do a credit check with various credit
agencies. My job however has to be authenticated with
my employer. So when you truly
look at what any paper job application, loan application, etc.
represents, it’s actually a request for identity information along with
the information necessary to provide a context … to authenticate the
information … if so desired.
It would be great to apply for
the apartment on-line, and have the information automatically filled in
- if it is known and recognized - by identity software running on my
PC. If the identity software recognized field names, it would
fill in the appropriate information from my personal identity store
(Personal Directory?), and if it didn’t recognize the names, then it
would allow me to create global or site-specific aliases for the
fields. In addition, I would be able to review the information
being sent, and even temporarily or permanently change what is being
sent.
This is where I see a lot of value for digital identity software to
solve a real-world problem. Yes, single sign-on is one place, but
the world of paper ‘applications’ that request all sorts of redundant
and mundane information is very inefficient and tedious. On top
of that, most of these paper forms are asking us for the same
information, and a lot of past historical information that we are
expected to memorize! What are your last three addresses?
What are your last three jobs? When was your last tetanus
shot? Who is your insurance company?
If I answer the question once, it seems that my own little personal
identity agent could record my answer … so that the next time I am
asked for that information it would be “pre-populated” in the
form. This is exactly what the browser ‘form filling’ solutions
do … so why not expand this extensively?
Once I have completed the
apartment rental application, I probably would not want to always keep
them up to date with this information forever. However, there are
many cases where I *DO* want to keep someone up to date. When
someone asks for my business card, I ought to be able to send it to
them, and tell my personal identity agent to prompt me if I every
change that information. The prompt would be something simple
like “Scott, you just changed your home address … you asked me to
always notify this one group of people (so I already did!), and you
also asked me to prompt you about this group of people … can you
choose the ones that you want it sent to?”
This is really where we wanted to move with digitalMe … and it is far
from the software doing things automatically without instruction.
It is more that during the various identity transactions that we
experience, the identity software would be accumulating a set of
‘rules’ that we design to determine how future transactions might occur.
So this is almost like taking the simple form filling that we have
today, putting a real identity store behind it, and coupling it with a
‘learning’ rules engine similar to the learning firewalls that are
available today. If we then add support for the various identity
protocols that are growing in momentum we have a very flexible tool
that automates much of the work that we do today in these identity
transactions.
No Tags
