Commentary by Mark Wahl
Organizing principles for identity systems:
Location and other attributes
(2005/6/6)
Bob Blakely posted an important comment on claims in the discussion which began when Dave Kearns posted in The WHERE in IdM that
"I could see [physical location] being used in a graded authentication scheme to reduce or deny access based on a possibly adverse location (e.g., someone trying to access a Pentagon database from Uzbekistan)."
and Kim Cameron posted in Location as an identity claim that
"Once you get your head around expressing identities as sets of claims, you can easily imagine expressing a user's location as one of those claims. "
Bob Blakely's comment to that was
"The statement "identity is a set of claims" does not imply that every possible claim is an identity claim. Does treating location as an identity claim make it easier or harder to manage identity? It's perfectly plausible to treat location as an authorization attribute; it's not clear that it's reasonable to treat it as an identity attribute."
Now for infrastructure devices, perhaps a thermostat for an air conditioning system, a smoke detector or an emergency phone, location is a primary attribute of the device's identity itself.
However for many other contexts, location seems to be an attribute of a particular transaction.
Similar attributes in this situation include
-
the capabilities of the device used to make the request.
This attribute is of interest to a portal site that wishes to display content in a format amenable to display on particular device or class of devices (desktops, mobile phones, etc). Perhaps only in the mindset of a particular mobile carrier would the type and capabilities of a mobile phone be attribute of the user's identity, generally it would not. - source system.
IIRC Microsoft Windows ™ for one has an attribute in its user database of the name a particular workstation from which a user is allowed is allowed to log in - if this is set, the user is denied the ability to log in from other workstations in the domain. - various metadata, such as time-since-last-login.
- time of day.
Some authorization systems only allow access during defined working hours, or would permit but flag as anomalous access requests outside of those hours.
One can imagine numerous other functions that can be applied to a user and their identity. These functions might have as hidden input paramters numerous aspects of the environment, such as physical or logical location, transaction history, clickstream, creditworthiness etc. The output of such a function could be expressed in a claim in one of these identity systems, and could no doubt be negotiated through a WS-* protocol suite association. I agree with Bob Blakely that a user's identity is not merely any set of a claims about or referencing the user, and that there can be distinction between the claims that are part of the user's identity and those which are ex-identity. The fact that a user has the electronic equivalent of a stamped timecard showing that that they entered the building at 8:30AM does not imply that the timestamp should be part of their identity.