Most current sites take it upon them to administer a user account for their
users. This brings along a lot of jumping through hoops, both for the user
and the service. The InternetWide Architecture resolves the problems that we
have gotten stuck into.
The present situation
When you want to use a server, you usually go to its website. And when that website wants to store data just for you, it will ask you to create an account on that server. You are asked to pick a username, a password, perhaps click on a link in an email, and you're done. You think.
First, the username; why must you pick a unique name? Because the data attached to that username should not be mixed with that of others. But isn't it a nuisance to have a different username for different services? This is aggrevated when you use these services to communicate with friends; each needs to learn of a new identity for you over each of those mechanisms.
Then, the password; this is an insecure mechanism to access online services. This is especially true when you share the same password (and username) accross a number of services. Basically, you are allowing them to login to each other's sites. A more technical drawback of passwords is that they are often the same over long periods of time, and that they are not sufficiently secure. Patches can be made with clever client-side tricks, but they are mere patches, and won't live up to the level of security of a proper cryptographic solution.
Then, the email address; you usually need to supply this as a method to recover a forgotten or lost password. Providing such a general form of communication also means that "service announcements" can be sent to you, which you may not be interested in when they take the form of advertisements. In general, you would rather not provide your email address to each service you try. Also, the habit of checking an email address by sending a link to click on for confirmation is a manual, silly mechanism of establishing your online presence; we can do much better than that.
A useful property about an email address is that it is not subject to clashes, like usernames are. So an alternative scheme is popular, where a complete email address is used as a username.
The wrong way forward
These disadvantages are clear to most end users, and services are popping up to resolve them. Unfortunately, this is far from perfect.
Large networks that provide "free" services to end users are starting to offer a login service to other sites; their present popularity indeed makes sites accept such forms of login.
Users however, should think twice before using such facilities. The login services are given full access privilege to the account data, because those login services cast the decision on whether it is you or not; combine this with the practical situation on today's Internet where such "free" services have an unsatisfiable hunger for data, and gradually worsen the privacy of their offerings, and a path is created to offer evermore well-structured data to those "free" login services.
Bring Your Own Identity
There is nothing innately wrong about a site that confirms your online identity, and indeed this resolves many of the disadvantages of the user/password/email scheme, but the identity provider must be under control of its users. This will usually imply that some modest payment is required for the service, in return for which the interest of assaulting end user privacy is reduced. Furthermore, it is vital that such forms of identity are related to domain names or perhaps your phone number, so it can have the distributed nature that makes the Internet so much stronger than the centric nature that most "free" services try to establish.
We relate the BYOID scheme within the InternetWide Architecture to domain hosting parties; in fact, we propose to split domain hosting into two components:
- identity provider
- service provider
The idea is that one's online identity can be managed and controlled, users and groups created, and so on. Identities can take on various forms:
user@domain.name, so users underneat a domain namedomain.name, so domain names1234567890, namely phone numbers (through ENUM)
With BYOID, you can use these identifiers when you are accessing remote sites. This is not dissimilar to the idea of using your email address, except for a few things:
- your identity does not have to support email or other communications
- you are not using passwords, but strong cryptography
As an end user, you won't just be better protected, but in addition you will benefit from Single Sign-On, meaning that you logon once a day or so, to be able to access services without further need to enter passwords. It's all a matter of proper architecture.
Go Top