WiKID Strong Authentication and Laws of Identity

Last week, I blogged about the flexibility of WiKID. Today, I want to apply that thinking to Kim Cameron’s Laws of Identity. How does WiKID’s flexibility support the Laws? Obviously, WiKID would only be a part of the identity system – the authentication piece. The question is how does WiKID enable this metatsystem to comply with the laws.

1. User Control and Consent

Technical identity systems must only reveal information identifying a user with the user's consent.
No one is as pivotal to the success of the identity metasystem as the individual who uses it. The system must first of all appeal by means of convenience and simplicity. But to endure, it must earn the user's trust above all.

WiKID can’t help too much with the policies that create trust, but it is very simple to use and a convenient way to manage multiple credentials.

2. Minimal Disclosure for a Constrained Use

The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.

There is not much here that applies to WiKID, except that WiKID can support multiple authentication relationships in a single domain. Hardware tokens cannot do that, so they will promote federated identity services which users will have to trust not to violate this law. It’s better not to have the temptation.

3. Justifiable Parties

Digital identity systems must be designed so the disclosure of identifying information is limited to parties
having a necessary and justifiable place in a given identity relationship.

The identity system must make its user aware of the party or parties with whom she is interacting while sharing information.

The justification requirements apply both to the subject who is disclosing information and the relying party who depends on it. Our experience with Microsoft Passport is instructive in this regard. Internet users saw Passport as a convenient way to gain access to MSN sites, and those sites were happily using Passport—to the tune of over a billion interactions per day. However, it did not make sense to most non-MSN sites for Microsoft to be involved in their customer relationships. Nor were users clamoring for a single Microsoft identity service to be aware of all their Internet activities. As a result, Passport failed in its mission of being an identity system for the Internet.

WiKID brings something to the table here – because a single WiKID token client can support with multiple independent servers across multiple parties, there is no need for a single identity provider like Passport. Of course, WiKID can support and greatly increase the security of a federated identity system.

4. Directed Identity

A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

Bluetooth and other wireless technologies have not so far conformed to the Law of Directed Identity. They use public beacons for private entities. This explains the consumer backlash innovators in these areas are currently wrestling with.

Public key certificates have the same problem when used to identify individuals in contexts where privacy is an issue. It may be more than coincidental that certificates have so far been widely used when in conformance with this law (i.e., in identifying public Web sites) and generally ignored when it comes to identifying private individuals.

This law is very insightful, in my opinion, and WiKID’s model works well within it. WiKID stores no personal information in the client or the server, except a username. The server may rely on personal contextual information to establish the relationship, but it is not stored in WiKID’s client or server. For example, WiKID provides an intranet application for the automatic validation of users based on trusted LAN credentials. Essentially, the trust assertion of the LAN credentials is transferred to WiKID in this process (I hope I’m using my “Laws of Identity” verbiage correct here). A vendor to that company could choose to trust those credentials via an assertion from that employer (either using WiKID’s protocol or using SAML, for example). The same user can set up a domain with their online bank using some other trusted method. There is no personal information stored in that domain either and it is directed solely at the bank. There is no cross-over between the employer and the bank.

5. Pluralism of Operators and Technologies

A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.

The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve, and self-organize.

Our focus right now at WiKID is adding more network clients to support a plethora of services, platforms and languages. Additionally, there are plenty of ways to extend WiKID across enterprises and services, such as via federation or via cross-credentialing (i.e., you can use a WiKID one-time passcode from service X to establish a relationship with service Y). Finally, we offer WiKID in both open source/free and commercial versions making it economically viable for logging into both your blog, your corporate VPN and your online bank.

6. Human Integration

The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.

The question is how to achieve very high levels of reliability in the communication between the system and its human users. In large part, this can be measured objectively through user testing.

We have focused a great deal on ease-of-use for the end user (as well as for the administrator). We also need to draw a strong comparison between the WiKID token client and PIN and a bank ATM card and PIN. We want users to understand the need for securing their token and PIN.

7. Consistent Experience Across Contexts

The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

To make this possible, we must "thingify" digital identities—make them into "things" the user can see on the desktop, add and delete, select and share. (We have chosen to "localize" the more venerable word "reify".) How usable would today's computers be had we not invented icons and lists that consistently represent folders and documents? We must do the same with digital identities.

I’m not sure I agree that this is necessary, but in a way, WiKID does this. I have a domain in the WiKID client called “WiKID Corporate” which I use to get access to our corporate resources. I don’t know why I would ever “share” this. That would seem to be a potential violation of Law 4.