Linkage with CardSpace in Auditing Mode

As we said here, systems like SAML and OpenID work without any changes to the browser or client – which is good.  But they depend on the relying party and identity provider to completely control the movement of information, and this turns out to be bad. Why? Well, for one thing, if the user lands at an evil site it can take complete control of the client (let's call this “extreme phishing”) and trick the user into a lot of evil.

Let’s review why this is the case.  Redirection protocols have two legs.  In the first, the relying party sends the user’s browser to the identity provider with a request.  Then the identity provider sends the browser back to the relying party with a response.   Either one can convince the user it's doing one thing while actually doing the opposite.

It’s clear that with this protocol, the user’s system is “passive”. Services are active parties while the browser does what it is told.  Moreover, the services know the contents of the transaction as well as the identities and locations of the other service involved.  This means some classes of linkage are intrinsic to the protocol, even without considering the contents of the identity payload.

What changes with CardSpace?

CardSpace is based on a different protocol pattern in which the user’s system is active too.  In fact, the user is in the center of and completely controls the interaction.  It connects to a relying party and then to an identity provider.  This means the services don’t need to know how to connect to each other (i.e., their locations).  The only linkage potentially intrinsic to the identity layer protocol is that of simultaneity, in the sense that the identity payload is obtained and delivered within a very small time window.  (As we will see, this can be mitigated through caching). 

Therefore, in addition to the anti-phishing characteristics of the new protocol, it has a fundamental advantage in the realm of privacy, since breaking the tight coupling – often an unnecessarily cozy relationship – between the identity provider and relying party is the premise for any reasonable expectation of privacy in the digital age.  Put a little differently, it is a requirement for conformance to the second law identity: minimal disclosure.

Having removed linkage from the necessary workings at the protocol layer, does this mean that no linkage is possible?  Absolutely not.  The protocol payloads carry identifying information of various kinds.  So the difference is simply this.  You don’t HAVE TO leak identity information in order to make the new protocol work.  This means that identity information communicated can match each use case and context.

Sometimes you want more visibility

There are cases which call for very tight coupling between the relying party and the identity provider.  An example would be a bank which needs to be able to audit your electronic transactions (I know noone who wants a bank account that is completely loosy-goosy..)  The bank also wants to ensure the payload arrives in the right hands.  Wouldn’t a direct connection from bank to relying party help in this case?

Paradoxically, in the age of the Internet, there are no direct connections of the kind there used to be with physical wires.  On its way from a bank to a merchant, a payload passes through dozens or even hundreds of machines, and the only way to protect it is through cryptography.  If the bank encrypts its payload for the merchant, only the merchant can read it – it can’t be decoded or altered by the many intervening machines.

In this sense, CardSpace provides a communications path that is as “direct” as any other Internet connection, even though the communication is initiated by the client, and one of the machines the payload must traverse is the client machine.  The point is, once encrypted for the relying party, the payload cannot be usurped by the wrong party.

The “direct” or “end-to-end” application channel is a function of encryption, not of the physical network layer or even a transport connection such as that offered by http. 

Movement to embrace these new paradigms is part of the evolution of access control into information protection.  Embracing application layer encryption significantly aids in the protection of sensitive resources – even after transactions have been processed.  What is worth protecting in transit is even more worth protecting in storage, where it can be attacked at leisure.

CardSpace auditing mode

The use case we have been describing requires the identity provider to know the identity of the relying party.  In CardSpace we call this “auditing mode”.  In this mode, the client sends information about the relying party to the identity provider for use in protecting the payload and making sure it ends up decipherable only by the intended recipient.

The identity provider can therefore verify the identity of the recipient – perhaps even rejecting it out of hand.  Otherwise it will encrypt the payload as just described.  We achieve all the benefits of a direct connection but because of the new protocol pattern, the participation of the client can be demanded as well.  Why is this useful?

One of the best examples is that of the identity theft ring which claimed to need the identity information of 140,000 people – and easily convinced ChoicePoint to give it to them!  The identity thieves were a “relying party”, and ChoicePoint was the “identity provider”.  The information was delivered using a backchannel connection with no users in the loop,  ChoicePoint had mechanisms in place to vet the legitimacy of the the thieves, but these were not sufficient. 

How could ChoicePoint dramatically increase its confidence that a request is legitimate?

What if the participation of the data subjects were required for the transactions to complete?  This isn't so hard to imagine in the current period of wikipedia, Facebook and mass collaboration.  If the data subjects had been involved, using a CardSpace protocol pattern, there would have been no ChoicePoint horror story, no ensuing investigation, no $10,000,000 fine. 

Strengthening the lock

Because of this, the CardSpace protocol pattern (WS-Trust) functions like a lock with three tumblers.  The client opens the first tumbler by initiating an identity transaction – an interaction over which it retains control.  The relying party opens the second by deciding to act upon information from an identity provider it can scrutinize and authenticate.. And the third tumbler is opened by the identity provider, which can similarly scrutinize the relying party – and assure itself of the participation of the user.  This three tumbler lock is the heart of the new protocol pattern used by Information Cards in auditing mode.

Linkage in auditing mode

Although the security characteristics are better, the privacy characteristics of CardSpace operating in auditing mode are no different from those obtained through SAML or OpenID.  That is because the mode is, well, auditing.  The types of linkage enabled can be minimized in the same way they can with SAML – for example, by using pair-wise identifiers as is done with SAML pseudonyms.

Let's view where we stand in light of criteria I laid out here.

Intra-transaction linking	The issuer knows a given user is transacting at a given time with a known relying party, creates the transaction content, and even associate a transaction identifier with the event.
Single-site transaction linking	The identity provider may offer a consistent identifier to the relying party or may not, and so controls single-site transaction linking on the relying party side.
Multi-site transaction linking	The identity provider controls decision to use an omnidirectional identifier linking the user across relying parties (or not).
Natural person linking	The identity provider and relying party may or may not be aware of the natural identity of the user, and may or may not share the knowledge across parties to the transaction.

In other words, with auditing mode, a great deal of trust must be placed in the identity provider.  It should only be used in the contexts where it is really required.

So this is key.  Unlike the case with the passive protocols, auditing mode is just one part of the CardSpace story.  It is also capable of functioning in privacy mode, with entirely better privacy characteristics.  We’ll turn to that after discussing the case of what we call “self-issued” Information Cards.