We live in a time that identities can be stolen, abused and revoked.
That mostly applies to our online identity. It is part of the
architecture of ARPA2 to provide the best possible control over our
online identities.
Many of us have a lot of identities stuck to us. Our names, social security numbers, phone numbers are examples of offline identities; our email address and a lot of account names with various websites are examples of our online identities. It's a rather confusing bunch for most of us.
ARPA2 intends to simplify one part of it, and complicate another, both with the intention of improving our control over identities. We do limit our architecture to online identities.
One identity is easier
The first thought is that it is silly to have another identity in any place you visit. Why does every website need to assign you with another username? This is especially daunting because "your" name may already be taken, and usually there is a password policy that is more silly than secure. And let's not forget about the difficult-to-read pictures from which we need to parse words or numbers while creating those identities. It's a bloody mess.
Compare this to the following idea: You have one identity, and each place that you visit allows you to bring that identity. Online structures exist so that the visited place can validate that the identity is correct, and if you are using a Single Sign-On system, you can access that new system because you already logged in when you started your day.
This is close to achievable these days. Realm crossover is a bit tricky, but can be resolved in a reasonable amount of time. And Single SignOn is trivial; the Kerberos system has done this since somewhere in the 70s, and it has since then seeped into almost all the pores of the Internet!
The identity can be of the predictable form john@example.com, which looks
like an email address (and may or may not be one in reality). This format
of identity is usable with pretty much all the protocols on the Internet,
and that means there is a form to bring your own -- as long as you can
prove that example.com, the domain-name part of the identity, approves
your subordinate identity for john.
This is similar to the email-based system that we have now: "we sent you a link to verify your email address, please click to confirm" -- but it really is different. Rather than needing this manual trick and depending on the existence of an email address for the given identity, it is possible to use domain-name properties to validate the identity and approve you without manual intervention. It's easier, quicker, more secure for the relying party and you cannot be contacted if you don't want ot.
You no longer have to be faceless.com/#!john but instead you can have your
own domain name -- or your family can have one, or your company, or group of
friends. That's the part after the @ sign; anything in front you can pick
since you have full control over the domain name and its namespace.
Being of two minds / Having two faces
The problem with a single identity is that it is very straightforward to trace your online behaviour. In fact, your behaviour will be a bit scattered if it involves multiple of your activities.
Both for the clarity of your online conduct and for your ability to separate roles that you play in life, the ARPA2 architecture therefore proposes the use of different identities. You can have one for the grocery store, another for the school teacher, and yet another for your family. All these reflect another aspect of your life, covered by a separate identity.
This may seem odd, after arguing the advantages of having one identity, but there is a difference -- one identity is useful to have across all the technical communications facilities that you are using, but it is useful to be able to separate your tasks or roles in life. Note only does it help you to sort your online presence better, it also helps others to get a coherent picture of you.
For this reason, the ARPA2 architecture aims at lightly created identities that include support for all the normal mechanisms that make them useful to establish your online presence.
Many authorisation systems work in this direction as well; they summarise personal identities to groups or roles, and use that to judge whether you are permitted to order a piece of work to be done. We will turn to this in several future articles.
Sub-domains
Given that domains give us total control over our online presence, and that the ARPA2 architecture will let us create as many users as we wish, it is becoming more and more interesting to own a domain name.
Another form of identity underneath a domain name is a subdomain; for example,
the name other.example.com is a subdomain of example.com and can be
managed on its own terms. We intend to exploit this, by given the owner of
example.com the choice whether to keep the other subdomain, or perhaps
delegate it to another party who controls it on their own. They other party
is dependent on the owner of the domain as a whole, but is otherwise free
to manage his identity, which should suffice in most trust-based relations.
Sub-users
Another form of sub-identity that we are considering is a sub-user. Imagine
that john@example.com is a board member; he could be addressable in that
position with a variation on his identity that is different, but in a way
that is clearly recognisable for humans and machines. We intend to use a
plus sign for this purposes, so in this case john+board@example.com
would mention john+board as a sub-user of john.
We imagine that this could be helpful during access control definitions.
Perhaps anyone can send email to john@example.com but only a limited group
(namely, the board and secretaries) would have access to
john+board@example.com. The former address could have another treatment,
may be redirected to a secretary, and so on. The same address might also
be used as an instant email list, addressing all who are whitelisted on the
access control list.
This last point is under consideration. If you have opinions, then please ventilate them!
Phone numbers
Since we are considering domain names as identities, we should probaly also rake up our mentioning of ENUM of a few days ago.
Phone numbers can be treated as online identities, just like domain names and users at domain names. As far as we are concerned, the main aspect of any hosting package is the management of online identity, in all its forms.
Go Top