Posted 2:17 PM (0) comments

The Wandering Mind wonders...

James Van Kessel makes an important point about one aspect of the 7 laws.

Where Kim states (in discussing "Advantages of a claims-based definition"): "...within a given context, identities have to be unique. Many early systems were built with this assumption, and it is a critically useful assumption in many contexts. The only error is in thinking it is mandatory for all contexts." (The Laws of Identity, page 5)

James replies:

Maybe it's my enterprise mentality but even if I can't determine which specific person is the user uniquely, I still want to have a unique and consistent identifier for the user in MY service's context. By not doing so, it can be difficult to track, support and understand the users' experiences over time at the service.

Not only can't I disagree with Van Kessel but I'm even more emphatic that each identity must be unique within every contect in which it exists - or it isn't a valid identity. If there's a possibility that a given identity can apply to two or more objects then the system is not only flawed, but worthless.

Cameron cites as an example:

... consider the relationship between a company like Microsoft and an analyst service that we will call Contoso Analytics. Let's suppose Microsoft contracts with Contoso Analytics so anyone from Microsoft can read its reports on industry trends. Let's suppose also that Microsoft doesn't want Contoso Analytics to know exactly who at Microsoft has what interests or reads what reports.
In this scenario we actually do not want to employ unique individual identifiers as digital identities. Contoso Analytics still needs a way to ensure that only valid customers get to its reports. But in this example, digital identity would best be expressed by a very limited claim - the claim that the digital subject currently accessing the site is some Microsoft employee. Our claims-based approach succeeds in this regard. It permits one digital subject (Microsoft Corporation) to assert things about another digital subject without using any unique identifier.

But within the context of Contoso Analytics, the object "Microsoft" has a unique identity, and as far as this context is concerned, the persons posing as (or acting on behalf of, if you prefer) Microsoft have no stannding at all - they aren't objectified so there's no need for them to be identified. However, in the context of "Microsoft" there is an object uniquely identifiable for each person and each of these objects are granted the role of "Contoso client" with the identity of "Microsoft".

Context is extremely important to identity, it is a necessary component of identity and it's absolutely essential that we realize the context in which a given identity is existing and that the identity have a unique identifier within that contextual system.

Posted 10:03 AM (0) comments

i-names: a convention searching for a use.

I've never understood the benefit of i-names as promulgated by Identity Commons and what's known as the "XRI community."

"dizzyd" has now posted some of the same concerns I have about this - for lack of a better term - intellectual exercise. In particular, he cites two major drawbacks:

1) there aren't any obvious tools available to the average user which would allow them "use" my i-name to contact me.
2) by default i-names are global, so there can only be one "=dizzyd" for the whole Internet. From an identifier standpoint, i-names are regressing us back to the days of "bob394" and "alice2zz".

Drummond Reed takes on the challenge of explaining these issues in his latest blog entry.

He concedes that there are few uses for i-names outside of the deeply incestuous identity industry right now, but points to plans for future efforts including Single Signon and data sharing. Neither appear to offer a compelling reason for Joe Sixpack to get an i-name.

As to the unique naming problem - and I do hate when registering for a service to be told that my choice of username is "already in use" - he notes that i-names are "at least as partionable as URIs, DNS names, and IP addresses." That is, every holder of an i-name can delegate extensions. He gives examples:

=dizzyd*john
=dizzyd*jerry.johnson
=dizzyd*jerry.johnson*mary.johnson

So he's saying that if someone else has already enabled "kearns" as an i-name all I need to do is to convince them to grant me "kearns.dave" and I'm home free. But suppose the holder of "kearns" doesn't want to do that? And what of my son Dave Kearns and my nephew Dave Kearns? I do not want to be the 5th derivative of "kearns"! Nor do I wish to be beholden to some jocko who happened to register the name and wishes to charge me a fortune to be part of the "clan kearns". None of this, by the way, makes it any easier for someone wishing to contact me to decide which of the "kearns.*" or "kearns.dave.*" entries I might be. Only if, somehow, I give my i-name directly to you can you then use it to contact me.

I simply don't see the point. XRIs (like the URIs and URLs they replace) at least have some logical reason for being - an XML universal locator. But when it comes to identifying and locating people, there's still nothing more accurate or efficient than x.500 naming.

Posted 8:17 AM (0) comments

Witchely wicked web security

Nick Owen offered some commment on my ideas about stronger cell-phone based two-factor strong authentication (say THAT five times fast!) and, naturally, pointed out what he feels is the superior features of WiKID.

THe WiKID system - not limited to any single platform - usues a triangulated method of providing one time passwords over a secure connection from a WiKID server to a WiKED client which is then relayed (via the resource that the client wishes to use) back to the server for validation. I'll have to give it some more thought, but it's certainly one way to go.