On identity systems for network spaces

Identifying users/entities in network spaces is a challenging problem: how do you propagate identities through a decentralised network? How do you maintain strong notions of identity?

In researching object capability systems, I've been trying to keep an eye on how systems identify the relevant entities. In "A Security Kernel Based on the Lambda Calculus" [1], I couldn't figure out how Scheme- or W7 actually determined the identity of Bart, Marge, or Lisa; it seemed assumed that their identity was handled some other way. Similarly, the paper "A Secure Identity-Based Capability System" [2], another paper I ran across during my research into ocap systems, seems to defer the identity problem to an "access control server" whose mechanisms are not discussed.

In the realm of web services, there have been several attempts at providing identity via such systems as OpenID [3]. One of the OpenID providers I've used identifies me through a USB hardware token (a YubiKey [4]), but this approach doesn't work for mobile devices (neither my phone nor my iPad has a USB port). It would seem that this provides as strong a notion of identity as the trust services place in my OpenID provider. If they have full trust, there's a strong notion of identity via the cryptographic capabilities of this token.

Other network services have a much weaker notion of identity. On this mailing list, I'm identified only by the text string that is my email address.

There's also the problem of user trust in the identity system. I don't actually have assurance that either the OpenID service or Google haven't acted on my behalf elsewhere, as I don't have any view on logging data and can only see what access logs they provide.

It's also important to separate identity from the authentication mechanism. OAuth is an example of an authentication provider: it's identity is based on the identity mechanism of the service using it. On Twitter, OAuth permits access to my account, which is identified by my username and password.

Maybe an ideal identity service provides a strong notion of identity across network spaces. Maybe instead there is no secure, one-size-fits-all identity mechanism relevant to multiple network spaces.

A first step in this regard is perhaps to identify what a useful, secure identity system provides. I propose the following properties:

1. There is a strong notion of identity: likely, some form of cryptographic security (e.g. via digital signatures) that strongly ties an identity to an actual identity. My YubiKey might tie my identity to me; my TPM might tie an identity to my laptop.

2. Either the system is self-hosted, in which the user has full control over the service and can inspect the source code, or there is some form of secure auditability (perhaps by a Merkle tree of signatures on log events [5], so long as the user can trust that log events are being generated on each identification).

3. The service should be federated. To borrow the users from "A Security Kernel Based on the Lambda Calculus", Bart might self host the identity service while Lisa uses a third party-hosted service. Marge should still be able to obtain strong assurances of both of their identities. It seems most useful if there is a common language of identity.

This definition doesn't preclude properties of pseudonymity (where Bart is a pseudonym for some user such that the Bart identity cannot be tied to other identities that the user may have), but strong identity will always be at odds with full anonymity.

References

[1]There's a web version of this paper at http://mumble.net/~jar/pubs/secureos/secureos.html; I've typeset a version here.
[2]http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.1785
[3]http://openid.net/
[4]https://www.yubico.com/products/yubikey-hardware/yubikey-2/
[5]I've built an implementation of auditable security logs; the source code is at https://github.com/kisom/auditlog. Secure audit logs have four properties: immutability, they signify a chain of events, a notion of provenance is required, and an audit log must be cryptographically certifiable.