Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Identity relationship management and the Relational Continuity Sockets Layer abstraction (2007/2/7)
In yesterday's post I mentioned the requirement for an ability to manage attributes of a relationship between an Identity Provider and a Relying Party in an OpenID or InfoCard deployment scenario. Paul Madsen wrote last November in "We need an IIW in Panama" on one of the attributes: the degree of RP selectivity in choosing an IdP, based on whether the RP uses black lists, reputations, white lists, or simply allows any IDP. He wrote in "Informed & controlling RPs" that
Mark makes the point that the RP will probably make its decision to trust an IDP (or not) just once in order to establish the relationship, with that decision subsequently manifested in the IDP being placed in a white (or black) list or some other more easily assessed mechanism (when you hire a new employee, you examine their resume and references at the interview, not every time they show up for work).
Similarly, another open question in identity management is,
How to manage the relationships of a user to each of the components of an identity management system?
In a deployment that's wholly within a single enterprise, identity lifecycle management products available from numerous vendors each provide a single point of management for administrators to implement provisioning and de-provisioning users, and many lifecycle management products also enable users to be proactive with user self-service features. By far, however, the most widely implemented self-service features are merely password change and password reset, and many other functions for managing the user's identities within the enterprise are the domain of a help desk or domain administrator, and users may not even be aware of the identities maintained about them in various enterprise IdM components. Potentially this will change as some of the user-centric identity management concepts are creeping into the enterprise context, with experiments in, for example, the use of social networks on the intranet, the definition of security groups which manage their own memberships and authorizations, roles that are built by observing user behavior rather than a static assignment of rights, and delegation to line managers of IdM provisioning tasks for their direct reports. For these to be successful, users need awareness of the components of the IdM infrastructure which manage their identity.
Mike Neuenschwander of the Burton Group, in his post on the Law of Relational Risk, proposes
a kind of "SSL" sessions for relationships - for now I'll call it Relational Continuity Sockets Layer. It would allow multiple participants to interact on a channel that is secure for the duration of the relationship or at least one risk cycle (this means longer-lived sessions than SSL) and allows for relation IDs (similar to session IDs). Such an invention would also address the requirements of addressable relations...
This RCSL abstraction has several promising benefits for use in identity relationships.
It could provide a standard and potentially portable container to hold the state of relationship as it changes over time.
Examples of this kind of state which could be referenced from this relationship might be a eBay reputation, or a transaction history. In addition, it could enable the user to view where their identities are in a workflow process.It could provide the means for each party to have access to the underlying data from which the party would be able to perform a consistency check.
For example, a bank may keep track of the date and source IP address of each succesful login. Other than to perform some basic checks that the requests are coming from a country that's appropriate for the user's transaction pattern, the bank may not wish or even be able to perform any further checks on whether the IP address is appropriate. While the end user may not wish to see this information displayed to them directly as they may not know their IP address history, theorietically the end user's computing systems could coordinate amongst themselves, determine whether this IP address history matches the addresses known by these systems, these end-user-focused systems could use this data to determine if there has been a compromise.It could provide a means of controlling the visibility of relationship state.
At a minimum, the ability to address the relationship as an entity separate from the participants could allow for selective disclosure of relationship information without needing to disclose who is in this relationship.It could provide a referencable underlying data set on which a reputation system could be built.
Some reputation systems may be able to leverage the knowledge that if A and B have had a relationship over n transactions, they each may be able to make a better assessment about each other than parties which has had fewer transactions with A or B.It could provide a template for common operations among many kind of identity relationships.
For example, just as "logout" is a typical operation for many kinds of identity transactions, "end relationship" could be an operation for an identity relationship.It could enable multi-party relationships to be better managed by the participants.
The majority of existing identity protocols describe pairwise relationships between two parties, but may not be able to incorporate the interactions of other parties.