Here are some comments on the Laws by Bob Wyman, co-founder and CTO of pubsub.com.
I strongly support Hubert Le Van Gong‘s concern about the confusion between the “provision of identity versus the provision of attributes.” In fact, I go further to say that I am concerned that your Laws and the many discussions around them seem to be constantly conflating at least the three distinct issues of identity, attributes, and permissions or rights management.
I don't think ‘conflating’ is the right word, as I will explain. But it is true I am proposing that these things are more closely interrelated than many have thought.
Phrases such as “an identity provider is a claims provider in addition to whatever other services it might want to offer” are particularly confusing. Clearly, you see that this thing you call an “identity provider” is much more than just an “identity provider” yet you seem to insist on refusing to name it as such.
I apologize if I've been confusing. I see the provision of identity as the provision of claims. I was simply indicating that an identity provider might offer other related services as well – for example, auditing of usage, or management of authentication mechanisms. And so on.
In fact, what you often seem to view as a single service is actually a system of services composed as a conjunction of at least the three services mentioned above. It may be that your work has led you to “to think of a digital identity as a set of claims made by one digital subject about itself or another digital subject.” However, while this may be a natural simplification for someone who has worked long and hard on directory services — which are concerned with the issue of associating attributes with identities, it is not a useful or clear definition for those who work in other areas.
I appreciate Bob's gentlemanly gesture in explaining my myopia as a side-effect of excessive exposure to directory – certainly a possibility. But I've also built security systems for almost as long as I have been involved in directory, so I can't really claim overspecialization as an excuse. This aside, Bob continues to discuss keys in a way that I quite like, though I don't think it is the only truth:
Developing a solid and flexible architecture requires a more rigorous distinction between services. The problem here reminds me very much of the “Myth of Certificates.” We've been taught by the sellers of Certificate that keys aren't useful unless you have a certificate that binds the key to some person. The result is a nice little industry which specializes in tying claims of person-ness to key pairs that otherwise could be generated for free… Yet, the reality is that computer programs care little about “person-ness” and usually treat the keys themselves (or evidence of control over the keys) as the identifiers of unique entities.
Now here is the nub. Bob is describing a subset of computer programs, not all or even most computer programs.
There is almost always at least one cryptographic key involved in identity. But a key can be used in many different ways.
In some scenarios, the relying party knows the key of the party being identified. It can then use “evidence of control over the key” as evidence that it is “dealing with” that party. This has the advantage of being simple if there aren't too many keys involved, but in other cases has the drawback that the relying party needs to know a very large number of keys, and possibly who has them, and when they have changed or been lost or stolen. As Bob knows, this can get really complicated, and has all kinds of information leakage problems when there are large numbers of resources.
To avoid this complexity and vulnerability, other usages of keys have evolved appropriate to other scenarios. For example, the relying party may just know the key of some authority, and allow the authority to then provides a “claim” about the party being identified.
Consider Kerberos (and similar systems), since it is very widely deployed and relatively easy to manage. In Kerberos, no resource needs to know the key of everyone who can access it. The resource just needs to share a single key with the Key Distribution Center (KDC). There is thus no information leakage about other keys or identities in the system. The KDC creates a set of claims about the party being identified and packages it up so only the identified entity can present it to the resource. So such a KDC is an Identity Provider in exactly the sense I am using. Kerberos systems have been making claims about their users for more than a decade. In Windows systems employed in a great many enterprises, these claims include an identifier for the user and the identifiers of a list of groups to which the user belongs.
Now the question becomes “what is an identifier”. And again, I suspect Bob has notions about this which are restrictive. I don't. In my view, it is up to the relying party to decide how it wants to distinguish between potential users. In some scenarios, it may make a lot of sense to have some uniquely identifying claim – like an email address, or an identification number, or a guid, or a unique personal key. In others, it may be fine just to be able to determine that an authority known to me uses its key to say the subject is of a given age, or works for a given employer, or lives at a given address, or knows a given secret, or belongs to some club. And in yet others an authority might say that the digital subject possesses a given key, or combine this claim with others. What is wrong with this if it is the kind of identification required by the relying party?
Let's pop up the stack a bit. Let's go back to the Oxford English Dictionary (OED):
“Identity – The fact of being who or what a thing or person is.
A distinctive Scottish Tory identity is certainly not a unique identifier – rather it represents a certain class of user (!) – yet still an identity. The details referred to in the subsequent bullet (name, signature, photograph) are to my way of thinking precisely examples of claims being made in order to establish identity.
If I am guilty of conflation between “identity” and “attributes”, I am no more so than the authors of the OED just cited.
Code only “cares” that whatever entity it interacts with is able to distinguish itself from other entities. “Identity” lies in that ability to distinguish one thing from another. Names, permissions, addresses, etc. are not “identity” — rather they are claims which are bound to or associated with identities.
The problem here is one of vocabulary but it appears to be influencing design. We've got an “Identity Industry” that seems to be very focused on “personal information management” or claims processing but very little concerned with Identity itself. The result is systems that are more complex and less well defined than is necessary.
As respectful as I am of Bob Wyman's contribution to computing, I believe he is holding to a definition of identity which is overly narrow and has nothing to do with normal usage of the word. By reverting to a more usual use of the idea, and allowing claims to be unique identifiers or tuples of meaning or whatever the relying party would like to see, we can actually get a lot closer to building a unifying identity metasystem, because then the implementation details of different systems recede as well they should.
Bob also brings up the issue of permissions and grants, another interesting topic to which I will return as I explore the issues of the relying party in more detail.
