What's All This Plumbing For?

Johannes Ernst blogs "If the Open Stack Is Mere Plumbing: The Plumbing Of What?". That question seems surprising from one of the proponents of OpenID. I thought it was all about simple identity for blog comments? Seriously though, he has a point.

If we look beyond OpenID, I would have to say it is the plumbing of layer 7 of the network - Applications! So, while I was joking when I said that I thought OpenID was only for blog comments, I was serious too. That's what it was designed to do. But was OpenID designed for the enterprise, for consumer applications, for social networking? Not yet. Hopefully some day in the future.

Of course user-centricity, which used to be all the rage, is still very important. But at the end of the day for the "users", centricity is just another tool, one of the plumbing options. Real people interact with businesses web sites. Notions of OPs, InfoCards, RPs are just plumbing lingo.

No, the real action is with applications. This is what consumers, users, and business people think about when they interact with the web. For the few of us, we might obsess about how a web site is built, and does it support UX protocol. But for the vast majority, identity plumbing for its own sake, doesn't mean much. Its hard to define a business model because well, there is no business.

What are the services that applications really need from identity plumbing? How about vetting, verification, privacy, assurance to name a few. Are they being delivered now? Many applications not only do their own identity management, but these as well. I would argue that in large part, many of the needed identity services are ill-defined and missing. This is why major web applications will continue to make mistakes as they try to learn, by managing personal identity information in a standalone silo.

The question I have, as specialist in IDM standards, does the application layer have all that it needs? When do we move beyond specific protocols and plumbing debates and ask what are the application-centric requirements that are needed to compliment the user-centric developments, we've had to date?

Johannes. Thanks for a great question!

Defining Identity Modality

During my last webcast about Project Aristotle at OpenLiberty Project, I introduced a new concept called Identity Modality. The idea occurred to me as I was trying to describe the different types of identity exchange protocols and methodologies and how they impact developers.

I noticed there are several different ways and modes in which information is exchanged. There are times when the user is present (online) or is absent (offline), there are times when the transfer occurs through a backend system (such as with a database), and times when it occurs directly via the user. Finally, there are simple transactions (atomic) and then there are multi-step or workflow like transactions.

If you take these 3 different dimensions and place them on a 3-dimensional axis and plot popular means of exchanging identity information (based on typical usage), there are some interesting observations that can be made.


What struck me is how the notion of a front-end or browser-based protocols create a 3rd dimension of information exchange. The diagram also shows why SQL based systems are so ubiquitous - because it fully encompasses user-online/offline, atomic vs. workflow based transactions. Likewise LDAP, covers a smaller area, because it was intended as a lightweight, atomic (single-operation at a time) protocol. Where SQL fully exists in 2-dimensions, LDAP exists only in the atomic space handling both user online and offline scenarios.

Considering the challenges of developers writing applications and the objectives of Project Aristotle, the chart suggests why applications dealing with multiple modes of identity communication face a huge challenge. It becomes one the reasons why most applications end up with their own identity "silos" -- it's much easier to ignore systems outside the application.

One of the objectives behind the architecture of ArisID is to be able to handle all of these modalities through a single API. A loosely-coupled architecture means Identity modality does not have to be restricted to a specific hard-coded set of choices, but rather be configuration-based leveraging policy and environmental requirements.

Time For Customers to Shout!

The attempt to merge various identity standards appears to be on the rocks with Johannes and Kaliya commenting here about the withdrawl by the Identity Commons folks.

Johannes is on the money about the culture clash. But in the end, the real loser is the customers as the the Identity version of HD-DVD vs Blu-Ray debate over competing standards and features will continue.

Customers, it is your time to shout! Contact your vendors (including my employer) and make yourselves heard! The vendors and open source communities need to hear from you!

Consent, Control, and Minimal Disclosure

Last Saturday I posted some screen shots showing some help text included in the Microsoft Cardspace client that indicate that what is displayed (display tokens) is not necessarily what is transmitted to a web site, and further that there are no guarantees that Cardspace has no control over what the web site does with the information once submitted.

Interestingly, Kim wrote a response to a thread on a similar topic on an exchange between Citi's Francis Shanahan, Microsoft's Vittorio Bertocci, and University of Wisconsin's Eric Norman. This exchange talks about Cardspace and whether or not it violates Kim's Law of Identity #1 - User Control and Consent - "Technical identity systems must only reveal information identifying a user with the user's consent."

Aside: If you haven't already read Kim's 7 Laws of Identity, I recommend reading them. My opinion is that they set an excellent starting point for minimum requirements - though I believe many other observations will be made in the future (e.g. Madsen's Lemma of Dubious Attributes).

While I agree with Kim that some level of compromise is needed to make the identity meta-system work, I also think this thread indicates there is more work to do.

With regards to the issue of concealed or coded information which is not displayed in the display token, one of the justifications I can think of for coded information are reference pointers. These pointers might be there because of Law#2 - minimal disclosure.

For example, when going to a book merchant web site I would normally provide my shipping address so that I can receive my order. However, if I had an existing relationship with a courier firm, then that firm could act as a managed card provider with the web merchant. When ordering a book, I could elect to use my courier's managed card which would include a shipping reference token. The web merchant would use that token to mark my package and notify the courier. When the courier picks up the package, the courier is able to translate the shipping reference token into my confidential mailing address. This allows me to avoid giving my shipping address to the web merchant.

What we have here is a case of Law #2, minimal disclosure causing conflict with Law#1. The shipping reference isn't meaningful to me, but it does work on my behalf. It allows me to avoid giving out my address.

There are of course many other cases where the encoded information is not in the user's best interests. And so, the Cardspace client should be able to test a token from a managed card provider to see if the display text matches the encoded text.

While we can’t then prevent evil, we can detect and punish it. The claims in the token are cryptographically bound to the claims in the display token. The binding is auditable.

In this case though, the audit should be done by the Cardspace in order to verify the token. This would allow Cardspace to warn the user of encoded data or additional data not originally requested.

I also agree strongly that Identity Providers need to be trusted. This is why the Liberty Alliance has begun work on the Identity Governance Framework and the Identity Assurance Framework. BTW. Both IGF and IAF are intended to work in a multi-protocol environment, including WS-Trust (Law#5 - Pluralism of Operators and Technologies). ;-)

After you send data on a card...

A colleague of mine noticed something interesting in the Cardspace help text (click to enlarge)...

Important: The data that is retrieved and viewed may or may not be the same as the data that is being sent to the requesting site. A managed card is encrypted so that it can only be opened only by the requesting site. When you retrieve a version of the requested data, it is the responsibility of the managed card provider to send an accurate copy of what the card provider will send to the site. If you do not want to send the retrieved data, you can choose another card or you can exit Windows CardSpace.

There's no guarantee that what you think you are transmitting is really what you are transmitting.

After you send data on a card, you cannot control what the site does with your data. Use caution when deciding what data you will send and to whom you will send it.

These aren't my words - they are Microsoft's (at least in the version of Vista I have). See for yourself! Open up your Windows control panel, then look for "Windows Cardspace". Open this, and set up a new card; create a personal card, and enter in some data. In the upper right of the window (under the Tasks heading) select the "What data should I include on my card". You'll find the text there.

I guess user-centricity will actually happen in a future release. Some new identity policy standards might have something to do with that.

Motivations for Identity Providers

I recently blogged about a couple of use-cases of organizations and why they might become attribute authorities and their general motivations. What are some more of the general motivations and for that matter de-motivators?

Yvonne Wilson of Sun writes...

I think the attribute provider concept makes a lot more sense when there is an entity that already has information about a person and which would be authoritative for a particular attribute and authorized (not necessarily by the user) to hand that attribute out, possibly in an obfuscated form. A government might be an authoritative source for whether someone is a citizen, and obliged to respond to another government to that effect. An employer might be an authoritative source for whether someone is employed and obligated to respond to a bank loan officer to that effect. A credit agency might be an authoritative source on someone's credit rating, and obligated to report that to a credit card company. The user doesn't get to intercept, alter or halt any of this, because the entities which need the information trust these authoritative sources more than they trust the user. Of course, this kind of provider would offer up only a limited set of attributes.

Some motivators for information providers:

• Is the provider authoritative? Before making assertions about individuals, the organization has to decide if it can provide some level of assurance about the information.
  
• Is the organization considered authoritative by means of legislation? Example, legislation may make a professional organization responsible for tracking and verifying the professional status of its members.
• Privacy enhancing reduction of information flow. Because a provider may know several things about an individual, they are often in a position to answer questions about individuals. Without directly revealing what they know, they can answer some questions. E.g. If you own property and pay taxes, your city can state whether you own and potentially live in that city. A department of vital statistics, responsible for birth certificates, could generate an assertion that you are over a specific age.
• Transactional co-ordination between business service providers. In order to complete a service to a user, a web merchant might exchange assertions with a credit card company and shipping company. This allows 3 service providers to co-ordinate in order to complete a transaction. The merchant sells a product. The credit company arranges for the financial exchange, and the shipper arranges for shipment. In this case, the credit card company and shipper are temporarily acting as Identity Providers, but in reality, they are motivated by the ability to offer a service.
• Auditing use. By switching from a bulk publishing method to a dynamic provider method, the provider organization can potentially keep better track of when and potentially where information was used. Note: this is not always possible or desirable, but the environmental privacy requirements will dictate it.
• Revokability. When organizations using batch methods exchange information about individuals, they have no convenient way to revoke or update the list on a timely basis. In a dynamic provider model, the assertions can be relatively short lived - from seconds to months.
  

Some of the de-motivators:

• Self-asserted, or asserted by a third-party information. If the providing organization is non-authoritative, then asserting these values to another party brings increased liability for accuracy, privacy, and potentially even copyright violation (e.g. credit scores from a credit bureau).
• SLA obligations. In the past, authorities may have been authoritative or responsible for assertions about individuals. However, requests were done through slower or legacy processes. Example, professional organizations issuing diploma's or certificates now moving to acting in real-time may change infrastructure requirements and the legal rules and responsibilities.
• Aggregation and compliance risk. The more information a providing organization amasses, the more risk they run for inappropriate exposure of information and inaccuracy.

I should point out that these observations are all from the perspective of the information provider and are not the view of the users/customers. It is important to understand the perspectives of all parties or user-control (centric) systems won't matter much.

Send me your thoughts! What other types of motivators or observations can be made?

Also, in a somewhat related post, check out Paul Madsen's Lemma of Dubious Attributes.

Desktop-Centricity, Service-Centricity, and User-Centricity

Paul Madsen comments on Dale Old's comment that "user-centric" should just mean the user participates in the flow of personal information.

Hmmm. In my mind, I prefer to interpret user-centric to mean the user has control. Control is what users care about. Conflating the idea of user-control with specific implementation or architecture is a mistake.

I mention this because a desktop-centric model such as Cardspace (an example of a user-agent) brings forward several problems:

• Sometimes desktops are shared (e.g. in manufacturing, service, or medical areas) and a single "windows" login does not match an identity. How would multiple doctors share the same desktop in an ER for example?
  
• Sometimes we users use multiple desktops at home, at work, and travelling. How do we stop the proliferation of personal information (e.g. InfoCards) and avoid leaving traces of ourselves?
• Sometimes we users are offline or not present during an information exchange. When an online retailer ships product, it happens when we are not present. Our personal information is shared with the shipper. How can we control the exchange of information when we do not have access to our normal desktop?
• Social networks and multi-party transactions create new challenges. What if my wife wants to look up my travel itinerary? Do I manage this dynamically, or pre-arrange this by policy (consent)? When you consider multi-party scenarios, the likelihood of one of more parties being away from their desktop or "offline" becomes problematic. I suspect this is why consent in social networks is most often handled by e-mail.
  

There have been some interesting discussions of late in the telco community about cell phones. Should they be the platform for a user-agent? Do they represent a better user-agent then desktop agent? Could you associate a mobile user-agent with a user in control of a desktop browser? Example, a doctor with a mobile cell phone associates with a browser session in a hospital workstation or kiosk. Further, what happens when the person is in an environment, such as a hospital, where cell phones are banned?

SAMLv2 and ID-WSF's more service-centric implementation of user-centricity is also an excellent design. The supported use-cases for user-control and relationship handling are very broad indeed. Finally, they depend little on a user-agent but still offer user-control. The thin user-agent has been both their key advantage, but also key disadvantage. Microsoft's work on Cardspace shows how important it can be when it comes to providing a strong visual interface that improves a user's understanding of information flow.

It seems that like life, no single implementation model of user-centricity will fits all use cases (at least nobody has proposed one yet). I'm not sure what a combined solution would look like. But I think this thread highlights why more of this type of conversation is needed at Project Concordia (an open effort to look at how we can have better interoperability across protocols).


Aside: It also occurs to me that smartcards are also a nice portable form of identity. The use of the card is under the control of the user. But are they a good implementation for user-centricity? The problem with smartcards is they are fixed in time and tend to be created for a single purpose. Is it appropriate to use a smartcard for reasons other than its intended purpose? If a card maps to a single-identity or set of assertions, then that may create problems with privacy. The beauty of SAMLv2 and Infocard systems is the potential for dynamic relationships that allow only specific information to be provided to each web site - kind of like having many many cards in your wallet. Smartcards are still an important format for credentials, but like driver's licenses and passports, I'm skeptical about the use of a smart card as a universal credential.

Thinking About An Identity Services API

My colleague at Oracle, Nishant Kaushik, was asking me about whether I knew if something was going on to develop a high-level API for Identity Services in the open source community. I realized that in a way, my work at Open Liberty on the implementation of the CARML API for the Identity Governance Framework was in fact turning out to be the startings of that exact API. From the developer's perspective, we're not building an IGF API, we're building an attribute/identity services API of which identity policy is only one of the many services needed.

The focus of the Open Liberty IGF project has been to demonstrate and provide libraries for using IGF, the issue I have run into, is that this project also needs a complete set of Identity Services. It needs to work with all the popular protocols (which is why working with a protocol specific API isn't good enough and why we're using Higgins IdAS to build on top of). It needs to deal with a wide variety web application needs and deployment environments. What started out as simply an implementation of IGF is definitely much bigger.

I would like to invite anybody interested in identity services to join the IGF Development Discussion group and add your thoughts. Should we broaden the direction of the IGF development to be more generic? Should we even rename or relocate the project? What do you think should be included in Identity Services. I know opinions vary widely on what Identity Services is. But this is exactly why collaborative input is needed now. Are you interested in getting involved? If so, feel free to respond to this post, or add your thoughts to the official development list!

Self-Issued Cards Are More Secure?

Ben Laurie responds to Pam Dingle's post on the issue of self-issued cards vs managed cards. I have to say I disagree!

Self-asserted cards are no more user-centric than plain old web forms. There's nothing user-centric about them. There's nothing giving users more control here at all. The only difference is the convenience factor offered by streamlining the form-filling process and another might be that the authentication mechanism might be stronger.

What Pam and Ben are missing is that when there is a third party involved, then the information that needs to be transferred can be dramatically reduced due to the relationship a third party has with both a user and a potential relying party. In her example, Pam was so close to the real value point but missed it. The point is not whether you can propagate a self-issued card to make claims about your credit score, the point is that you can choose a third party (that the relying party trusts) to verify whether your credit is good. No score needs to be transferred and no personal information needs to be revealed. The only thing the relying party needs to know is that Pam's credit is "good" for the purposes identified by the provider.

What I'm talking about is the identity oracle effect. The idea that managed card providers (or more generally federated systems) have the ability to act as an Identity Oracle, minimizing the exchange of information. Instead of forcing users to provide all sorts of personal information, a provider can simply say "I know Pam, and you can trust me, her credit is good!".

Self-asserted cards do not add any trust or reliability value - just convenience. Managed cards offer the opportunity via a third-party relationship to reduce the information transferred in the first place.