Cardspace, Liberty, & Intel's ICP

A couple of weeks back at DIDW 2008, I reported on a proof-of-concept that we put together at Intel where we combined Cardspace with our Identity Capable Platform (ICP) to show how ICP could extend/strengthen a cardspace deployment. While we used Cardspace in this demonstration, the code should work with any Identity Selector conforming to the Identity Selector Interoperability Profile.

For those of you who don't know, ICP is a research project we have been working on at Intel exploring how identity capabilities could be added to a platform to enhance online transactions. Our contributions to the Liberty Alliance's Advanced Client Technologies are part of that work.

In this proof-of-concept, we showed how a mythical bank (ACME Bank, of course) could provision an identity agent to the platform which was then subsequently used as the identity source for Cardspace when the user initiated a session at the bank. To Cardspace, the identity agent was a full fledged STS and had a managed card that has been provisioned into Cardspace (so, essentially, this was an off-the-shelf Cardspace deployment).

The provisioning process made extensive use of the Liberty Advanced Client Technologies protocols to securely provision the identity agent to the platform.

One might ask what exactly is an identity agent. I use the term very loosely to define any identity related agent software. In this particular case, the identity agent exposes WS-Trust and ID-WSF Provisioned Module interfaces as well as containing a SAML token generator and an ID-WSF IdP Service client (to be able to get minting assertions).

If you want to take a look at the presentation it's here. However, I have to warn you I write my presentations as something that needs speaking to and not as standalone documents.

Even better, there's going to be an encore presentation as a Liberty webcast on November 18th. I'll post the details once I get them.

UPDATE: Britta found it for me: Info/Registration for Webcast . Where would we be without Britta!

Tags : identity / Intel / Liberty / Cardspace / WS-Trust / SAML / Identity Selector / DIDW

What ID-TBD means to me....

For those that don't know what ID-TBD is, it's an effort underway trying to tie the umpteen different identity efforts together into an uber identity organization. TBD as in To Be Determined (as in, we don't want to argue over the name till we get agreement on the organization and organizational structure).

My main goal here is to get out of the Liberty Alliance and away from it's exotic meeting locations like Singapore, Paris, Stockholm, Tokyo, Madrid, Sydney, Rome, etc.. I have become an active member in the Liberty 50 (those of us who have put on an extra 50 pounds or more since starting to participate in the organization). I'm probably at the head of the line and perhaps hit my peak at around 60lbs (30 or so kilos for the rest of you guys outside the US).

Yes, I blame Liberty for this (not my lack of good eating habits, my desire to have hamburgers and fries for every mean -- even breakfast -- my lack of exercise, etc., etc.). It's clearly Liberty's fault. You can see it in the pictures below:

That's me in 2001, shortly before I joined Liberty. And now, after 7 years participating in Liberty:

So by exiting Liberty and joining ID-TBD, I hope/expect to be able to loose my Liberty 50 and go back to my 2001 self. Even with just the announcement of the potential organization, I've made some progress in that direction:

This is why I am sooo supportive of the new organization. It has nothing to do with messaging convergence, coordination, consolidation or any other such mom and apple pie reason for me. I just want to get out of the Liberty 50 group!

Tags : liberty / ID-TBD

Pseudonymity would help

Kim Cameron writes of Google's failing to scope SAML assertions:

But according to the research done by the paper’s authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”? So they dropped the whole ID and scope “thing” out of the assertion. All that was signed was the client’s identity.

The result was that the relying party had no idea if the assertion was minted for it or for some other relying party. It was one-for-all and all-for-one at Google.

While I agree totally that the intended recipient should have been identified within an <AudienceRestriction> in the SAML assertion (how SAML shows the intended scope of the assertion) the problem would have been moot if Google used good pseudonymous identifiers for its users.

Pseudonymous identifiers are random identifiers that change for each relying party (so my identity at relying party A might be 123 while my identity at relying party B might be 345). Good pseudonymous identifiers are large random values (so that they are unpredictable) and are not reused across multiple users (so the same identifier is never used at different relying parties for the same or different users).

The primary impetus behind pseudonymous identifiers is to prevent the use of the identifier as a correlation factor across multiple relying parties -- in contrast, a globally unique identifier would allow relying party A to ask relying party B about what user 123 did yesterday, whether or not the user was around. However, pseudonymous identifiers also provide the following benefits:

• added security depth - an unknown user identifier adds another layer of security on the SSO system (which, in this case, would have protected the user accounts from attack since even if the assertion went to a different relying party, there would be no user account with that specific identifier, so it wouldn't be useful).
• easier integration of new partners - when integrating new partners, the identity systems of the partners may have different data structures for user identity (at it's most simplest case a new relying party may store user identifiers in 32 bit integer values, while the IdP typically uses 128 bit random values -- a system that supports good pseudonymous identifiers and the assumption that identifiers are different on each system will easily be able to handle this.

One might be concerned about how relying party A could invoke a service of relying party B when they are all using different identifiers (such as a google relying party using Google Checkout). This is pretty simple. Typically, any such service invocation requires relying party A to get a security token for the user at relying party B. When that token is obtained, the issuer does the identity translation. SAML provides for the protection of the identifier in the assertion using encryption since relying party A should never know what the user's identifier is at relying party B and the assertion is given to relying party A.

Liberty ID-WSF provides several entities that provide this translation services depending upon the topography of the deployment. The most common such service is the ID-WSF Discovery Service.

Similarly, in WS-*, the WS-Federation Pseudonym service is called out to perform the same translation service (and it is possible for a deployment of a WS-Trust STS to perform this translation internally during token generation).

I strongly recommend that any deployment of SSO, even within a single enterprise, make use of pseudonymous identifiers. They only strengthen the identity infrastructure.

Tags : identity / Liberty / ID-WSF / ws-federation / google / SAML / pseudonymous identifier

Paul, Paul, Paul....

Paul writes about an upcoming Liberty Alliance futsal match in Tokyo and includes:

Conor "One-Sock" Cahill, when asked whether he would be participating, responded 'Only if I can get an upgrade to First. Currently, I'm booked in business on a Triple 7 in from SFO, but I'm trying to switch that because I'm in seat 4A and I hate that seat because the power plug is about 2 inches too high and I have to unbuckle my seatbelt to reach it. I generally like 3F but the window shade was broken last time and the sun woke me up, even though I had taken my Ambien.'

Paul, everyone knows that there's no 4A on a United Airlines Boeing 777. First class stops at row 3 and business class starts at row 8. 3F isn't a window seat (3A and 3J are, though 3A is frequently reserved as a pilot rest seat, but not on the long haul triple 7 that United uses for IAD->NRT flights).

My preferred seat is, of course, 3A since they would have to pick the best, quietest seat for pilot rest, followed by it's opposite window seat 3J.

And finally Paul, you *know* that I don't sleep on the way to Tokyo. My rule for flying west is to stay awake till arrival at the hotel. In fact, I remember you telling me that you had tried doing the same and it worked for you as well.

Please try to get your facts somewhat correct when generating a fake Conor "Mr. Travel" Cahill quote. And stop ragging on me about the sock. I was in the middle of putting my shoes on when the called us together to take the picture.

Tags : futsal / Liberty / United / UAL / Boeing / 777

Updated Liberty Open Source

I've updated my Liberty ID-WSF Open Source Toolkits again. This time to reflect the minor changes made in the Advanced Client specifications as they were finalized within the Alliance.

For those of you who aren't familiar with this code, I have two toolkits available -- a C++ client and an Axis1/Java Server -- which implement the Liberty ID-WSF protocols (both the basic framework and substantial portions of several services).

This new release of the toolkit does not add new functionality -- it only brings the code up to match the final specifications.

Have fun!

Tags : identity / liberty / Liberty Alliance / Open Source / ID-WSF / Provisioning / Advanced Client

Advanced Client Take 2

The second draft of the Liberty Advanced Client Technologies set of specifications has been published on the Liberty Alliance web site.

For those who aren't aware, the Advanced Client Technologies work is the 3rd generation of client technologies coming out of Liberty. The first generation was work that enabled a Liberty-aware client and/or proxy to participate in the SSO transactions (similar to what Cardspace does today). The second generation enabled active clients to act as WSC's in identity transactions (such as a radio or mail client authenticating with an IdP, discovering and accessing a service provider).

This third generation enables clients acting as an extension of network providers such as an IdP, and addresses the issues related to hosting full-fledged service providers (such as my own IdP, or my own Contact Book Service) on my personal client.

So, this is your chance to nail me to the wall and point out how many stupid things I've done in there (though I'm not the only contributor, I'm sure that if something stupid is in there it is my doing). Please take a look-see and let us know of any interesting things you find in there (even pointing out the many, I'm sure, English mistakes would be helpful).

Go for it!

Tags : identity / Liberty / Liberty Alliance / Advanced Client

Relatinships and authorization

James McGovern writes about how relationships must include authorization:

Anyway, the notion of relationship is something that belongs to the identity provider and entities such as the Liberty Alliance are defining standards around it. Check out their notion of the people service. The key though is that relationships sometimes require authorization. For example, just because my son can order an insurance card from Amica doesn't mean he is also allowed to cancel the policy for the entire family. Relationship needs authorization especially in domains having to do with medical interactions.

While I like his good words about the Liberty Alliance, I take exception with some of his conclusions.

First off, I don't think that relationships should or must belong to the Identity Provider. This is especially important in a world where my relationships cross the boundaries to many different Identity Providers. Within Liberty's People Service, we took great pains to ensure that the protocols support both a) the People Service be able to be provided by a party other than an IdP (just as LinkedIn provides this type of service to their customers) and b) the relationships contained within a user's People Service must be able to cross identity domains while still protecting the privacy of the users. The latter requirement lead to some rather complex protocol sequence requirements when establishing a connection.

Secondly, I look at authorization as being associated with the object being accessed (where the input parameters may include individuals and/or group memberships) and not with the relationship itself. So in the example provided by James, James would introduce his son to Amica (using the People Service) and then set the associated rights at Amica, not within the People Service. The primary driver for this is that only Amica understands the objects available to Jim and the associated access permissions that may be possible for those objects.

The one place where I see the People Service (and/or any other relationship tracking service) getting involved in authorization is where the user controls what another may do with his relationship (e.g. I can allow Paul to see my relationships (and the fact that I long ago had a coolness link to the ever-cool Joni)).

Tags : identity / authorization / Liberty / Liberty Alliance / Linkedin / People Service / Relationships

Maintaining Social Networks

A recent article on the Teknision blog complains about the pain it is to build and maintain social networks again and again on one site or another:

There is something very wrong with the web……

I wonder how many times I have had to find and add Gabor Vida, Steve Mackenzie, Ryan Stewart, Mike Chambers, Phillip Kerman, Mike Downey, Mike Potter, Stacey Mulcahy, Ryan Murphy, Mykel Ruvola( and on and on and on and on) in the last few months. I have spent a huge amount of my time across social networks re-finding the same people over and over and over again.

I too have felt that pain and I am feeling the pain yet again as several of my compatriots have joined dopplr to keep track of where we all are and find interesting crossings of paths as we gallivant around the world.

Interestingly, this is what the Liberty Alliance's People Service was designed to solve, including the connection to people in different identity circles (e.g. they didn't all have accounts within the same identity domain). You can follow along on a webcast on the subject: audio is here, presentation deck used is here.

Take a look, there's some interesting stuff there.

Tags : identity / liberty / Liberty Alliance / People Service / social networks / Dopplr

Perhaps not so much Bashing...

Kim responds to my note about SAML Bashing:

...which is, by the way, absolutely NOT my intent. I’m simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies. I can’t take up all the points he raises, but encourage the reader to look at his piece…

Perhaps I reacted too negatively, but the analogy of some unknown clerk reaching into my pocket really irked me as that clearly isn't what happens and it appears to be written to instill unreasonable fear in an implementation of a browser-based SSO protocol.

I’m not criticizing or discussing the profile for an Enabled Client/Proxy. I was talking about SAML as we know it - in the mode which has been widely deployed in portals all over the world.

I think such analysis should be based upon the capabilities of the protocol and not about what some deployments have chosen to do within their environment (where they clearly felt that browser-based SSO meets their needs (and in many cases is mandated by the deployment scenario).

I think Conor is misunderstanding my intentions. I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor’s b) and c) above would apply. But we are looking at linkability precisely to judge the threats in the case that parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.) So arguing that the identity provider will behave properly has nothing to do with what I am exploring: risk. I’ll try to build Conor’s concerns into my ongoing discussion.

I'm sure there's some misunderstanding here. I normally find that I agree with most of what Kim has to say and really respect his opinions.

As far as the trustworthiness is concerned, there's nothing that is completely trustworthy, not even if I make the decisions myself and hand-code the response messages from the keyboard (I'm sure that I will make mistakes of judgment and or typos).

I would ad that the same "attacked in ways that undermine their trustworthiness" applies to client implementations that try to enhance privacy protection. They too are subject to being attacked. Nothing is totally foolproof and I'm not sure which has more likelihood of successful attack, a service maintained under contractual agreements or open software systems in the hands of end user.

I certainly have chosen to put my money in a bank rather than store it under my mattress. Yes, the bank is more likely a target for a robbery, but they are legally obligated to maintain my funds, even if they are robbed. Similar decisions will be made by many people in the identity space (and yes, some out there will always keep their funds in their mattress).

Tags : identity / privacy / SAML / CardSpace / liberty

SAML Bashing

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion:

• SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
• The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on. (”Trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of "I give one of my providers permission to reach into my bank account and withdraw money to pay my bill". I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” - without the requirement for any collusion. Knowing each other’s identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether.

The IdP does not "see all". The IdP only sees that you have visited a particular relying party. It does not see what you do at the relying party. Knowing that I visited Amazon, is not the same thing as knowing what I looked at and/or purchased at Amazon.

Secondly, my choice of an IdP (as with most others) would be made based upon the appropriate policies and auditing capabilities at that IdP (just like I don't choose to use Johnny down the block as my bank, I choose a reputable firm and just as I would require the exact same policies and auditing in any client that I chose to use to act as my identity selector (yes, I have to *trust* Cardspace's or Credentica's implementation of policies just as I have to trust an IdP's).

In fact all versions of SAML include an “artifact” binding intended to facilitate this. The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.

That isn't the intention at all. The intention, as Kim surely knows, is to pass a message by reference rather than by value. For the non-programmers in the audience, this means that I have a message that I need to send to the relying party (in this case that message contains an assertion, which can be big and complex and which has additional security requirements if passed through someone else's hands -- yes, the user can count as someone else). Instead off sending the token to the client to have the client then send it up to the relying party, I can send a small artifact that the relying party then presents to the IdP to get the token. The protocols explicitly define what the artifact is exchanged for -- it was never intended as, nor can it be used within the protocol definitions, as a general collaboration handle.

In many enterprise implementations, the artifact is used to allow the IdP to issue assertions to the Relying Party that don't need to be signed by the IdP. Clearly that isn't something I could do if the assertion was sent to the client (otherwise we'd be talking about how I took the token and edited it say I was Bill Gates when I sent it to his bank).

In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.” In other words, an IP/RP collaboration use case.

All SSO use cases (where one party authenticates a user and asserts an identity for that user at a relying party), redirection or not, would then be, by Kim's definition, an IdP/RP collaboration since the RP (Relying Party) is relying on the identity presented by the IdP. This has nothing to do with redirection or user involvement, or SAML in particular.

As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.

No. RelayState is designed for the RP to send information to itself, not the IdP, so that it can remember what the user was trying to access when the user is returned to the RP following a successful SSO operation. This is primarily used in the case where the RP is unable to set a cookie in the user's browser to remember that information. SAML even points out that as little as possible data should be included in the RelayState.

Paul's point in his comment was that if an RP used this incorrectly, they could leak information. The SAML specs contain exactly this caution.

I don't claim to say that SAML is the end-all for every use case. I do believe that we need to support multiple methods, some of which have different privacy implications. I also don't want some privacy weenies making life intolerable by the need for a confirmation of every thing that I already said it was OK to do. I do trust some of the parties that I interact with and want to be able to automate as much as I feel comfortable doing. I have no problem with the privacy weenie that wants to turn on the "let me approve everything" -- just don't force me to live that way as well.

Tags : identity / privacy / SAML / CardSpace / liberty

Concordia Schmordia

Next week, I will sit on a panel with Mike Jones of Microsoft and David Recordon of VeriSign. This panel will be a part of day spent on the subject of the Concordia Project.

One might ask, "What's Concordia?" and I, of course, would respond that that's a good question. My recollection (questionable, I know) of the sequence of how we got to where we are is as follows: The name originated in an earlier internal project at the Liberty Alliance where a number of us were examining potential paths towards convergence with the other technologies/protocols in the identity and web services space. Eve Maler can be blamed for the name as she brought it up given that Concordia was the Roman goddess of agreement, understanding, and marital harmony (not that any of us were getting married to each other) -- which, theoretically, is what convergence is about.

Anyway, as we moved forward on the project we eventually figured out that doing this ourselves would likely be a waste of time (why would anyone else listen to us). If we really wanted to talk about convergence we needed to bring the other players to the table. That led to more deep thinking (and perhaps a few visits to the neighborhood psychologist) and the eventual realization that many of the differences in the current approaches had to do with different use cases and with looking at the problem from different points of view.

So, here we are. Trying to organize an effort to bring together people interested in this space so that we can discuss our respective use cases and understand the problems that need to be solved. Liberty has tried to be very careful and very clear that this isn't a Liberty effort, but an industry effort (which Liberty supports). My hope is that we can use this common understanding to drive towards common protocols, features and capabilities so that those trying to use our stuff will have an easier time integrating with the rest of the world.

So come join us for the Concordia day at the Burton Catalyst Conference. At the minimum, it should be fun (though without Dick Hardt on the panel, I won't have someone to pick on :-)). The Concordia sessions are free, you just need to register here.

I look forward to seeing you all there!

Tags : identity / Liberty / Liberty Alliance / Microsoft / Verisign / Burton Catalyst / Concordia

April... an unusually quiet month...

I just noticed that last month, I only wrote 6 blog entries (Paul frequently hits that number in a day)... My slowest month in a long time.

This wasn't about a lack of things to write about -- there's more than enough stuff going on out there that is clearly calling out for my essential input :-). My lack of posting has been because my free time (what little there is) has been taken up by the updating of my Open Source Liberty ID-WSF implementation to have some of the functionality documented in the new Advanced Client specifications.

No, it isn't done yet, but I just had to take a breather and do something fun like post a blog article about not blogging. I'm sure Paul will find some higher meaning in my doing so :-).

But, no worries, the interoperability event is scheduled for the first week of June in Dulles, Virginia (yeah, that's a real place, not just an airport -- although the airport was first). I should have my head above water by then.

In the meantime, I'm off to Munich to participate in the European Identity Conference hosted by Kuppinger Cole. I'll be in 3 sessions there:

• A panel (Identity Federation and User-Centric Identity – How will it affect Business and IT Infrastructures) with Dick Hardt, André Durand (Ping Identity), and Jörg Heuer (Deutch Telecom). I don't think I know Jörg, but there's usually lots of fun when Dick and I are in the same room at the same time :-).
• A presetnation session (Identity Capable Platform) where I will talk about some of the research work done in the area of client based identity, a joint POC between Intel, British Telecom, and HP, and the latest Liberty Alliance Advanced Client specifications.
• A tutorial session (Implementing Secure Liberty Alliance Web Services)with John Kemp (Nokia) and Sampo Kellomäki (Symlabs) talking about developing secure web services.

It should be a fun week! I hope to see many friends there.

Tags : blogging / identity / Liberty / ID-WSF / Liberty Alliance / SXIP / BT / HP / Nokia / Symlabs / Advanced Client / Ping Identity

Anonymous identity

Paul writes in "Identity as Relationship Precursor":

This is interesting because it seems the exact opposite of most use cases in which identity attributes are shared (and those that Liberty ID-WSF has historically focused on). In these use cases, interaction comes first. The user shows up at a service provider and, in order to provide some enhanced level of customization, the service provider seeks to obtain identity. The model is

Interaction --------------> Identity Sharing

I'll argue that current identity systems (OpenID to a lesser extent, albeit not spec'd out) are geared to the latter model, what are the implications of the former?

Au contraire Monsieur Madsoooooon, we considered the both use cases and specifically designed the anonymous release of attributes around the case where the user gave away some bits of information in order to get a better experience at a target entity without giving away their identity nor creating a federation to their identity (which they could, of course, do later if desired).

The common discussion around anonymous identity was, for example, releasing your zip code out of your personal profile to anybody so that when you showed up at a movie web site, they could automatically display the movies that are showing in theaters in your area.

Tags : identity / liberty / Liberty Alliance / anonymous

Liberty's Advanced Client Trusted Module

Last week, the Liberty Alliance announced the release of the initial draft of the Advanced Client Technologies (ACT) specification set. I mentioned it as well last week.

One component of the Advanced Client Technologies that may be less than obvious is the Trusted Module (TM). The TM should not be confused with the Trusted Platform Module (TPM) whose specifications have been released by the Trusted Computer Group -- the two modules do very different things, although I expect that some TM implementations will make use of a TPM to enable their trustedness.

The TM doesn't stand out so well since there is no "Trusted Module" specification in the specification set, although there is discussion about the TM in the Advanced Client Technologies Overview. That is, in part, because the TM isn't a service itself (although it does make use of other services such as the IdP service).

However, the TM is one of the more useful components included in the Advanced Client Technologies specs and was driven by a number of valuable (from a personal and a business sense) use cases which called for the following capabilities:

• The TM can act in the name of the (Identity Provider) IdP for SSO and Web Services transaction identity assertions.
• The TM can locally validate user credentials (username/password, smartcard, biometric, etc.) and assert the identity of the user based on the local validation (to the IdP and/or to relying parties (RPs)).
• The TM can perform these tasks when "offline" or otherwise disconnected from the IdP (sometimes out of a choice for privacy reasons).
• The solution must allow for, document, and support a model that does not inadvertently require the creation of a correlation handle for the user's identity across multiple providers. This requires interesting solutions when you take into account that an entity that is likely to be per-user will be participating in signed transactions.

Essentially in this model, the TM is a local beachhead for IdP delegated functionality. The reasons why an IdP might want to support this model include (in no special order, nor intended to be totally inclusive):

• Security - allowing verification of credentials locally, without the need for network transmission nor network storage of the credential verification data decreases the likelihood that such data will be stolen (especially an issue when considering biometric data given that the user typically can't change their biometric data).
• Load distribution - the identity related transactions are distributed out to end-user systems rather than having to rely on a central server for every transaction.
• Privacy - allowing the TM to perform SSO operations reduces the visibility of the IdP into exactly what the user did when since the TM can do so without involving the IdP (assuming, of course, that the IdP has allowed the TM to do so).
• Availability - the user is able to actively assert their identity, even when the IdP is not available (e.g. because of maintenance downtime, connectivity issues, or even remote site access).

All-in-all, this TM provides a substantial package of powerful technology that will improve the overall identity meta-system. I look forward to seeing some of this stuff hit the street.

Tags : identity / liberty / Liberty Alliance / Advanced Client / Trusted Module / delegation / TCG / TPM / TM / privacy

Keylogging & Security

In Identity X-File 0x01, Pam writes about a story in the UK where a 6 year old was able to bring in and install a hardware key logger on an MP's computer in the House of Commons (it was part of a BBC experiment).

I assume a physical keyboard logger like this could still be used to steal an IdP username & password, even with all the secure desktop stuff that the CardSpace client has built in…

Essentially what a key logger does is use a Man-In-The-Middle attack to capture all input to programs and applications (including login screens) on a computer. The captured data is then analyzed to pull out useful information such as login credentials, credit card numbers, and other such valuable information.

If the primary concern is login credentials, the "easy" answer is to move to some form of strong authentication that requires hardware assistance (such as a smart card or biometric reader). These usually have communications protections in them to protect against MITM attacks. This isn't so easy to implement across a number of vendors (especially if you try to do it without identity federation networks such as those discussed by the Liberty Alliance's ID-FF and OASIS's SAML 2.0) and, even if you were to do so, the non-credential data entered by the user would still be subject to loss (such as the content of all typed emails, documents, etc.).

I did stumble across one amusing way around loggers (but, IMHO, opens all kinds of other problems) which uses a screen based keyboard to enter your data by clicking on buttons -- theoretically this is less likely to be picked up by loggers. The problems with this model include:

• While you click on the keys, your credentials are displayed plain-text on the screen so anyone looking over your shoulder would get them.
• You are trusting that the party that manages that page is not going to add anything to that page to log your entries (and without looking at the code, there's no easy way to do so).
• The site is unencrypted, so anyone looking at your network traffic can get the data
• The way that you then copy the data to the appropriate application is via the Operating System's copy/paste routines, something that is frequently available to any application and so subject to attack.

I wouldn't recommend using such a solution. Just too many weaknesses for me.

The ultimate answer for key loggers is a Trusted Path (sometimes called "Secure Path"). The trusted path ensures that the user is talking to the application that they think they are talking to (i.e. that there's no MITM listening in). Microsoft talked about doing this in their Next Generation Secure Computing Base (NGSCB) (code-named Palladium), which, at one point was to be part of Vista. However, only a limited set of the NGSCB functionality made it into Vista - the BitLocker drive encryption component.

This problem isn't small and isn't easy to solve, especially when you consider the need for being able to replace keyboards (because they broke, because you want to try a more ergonomic version, etc.). If you make replacement easy, you make MITM easy. If you protect against MITM, you end up making it hard for your users to easily work with their systems (increasing IT maintenance cost).

Tags : key logger / Microsoft / Palladium / Vista / Trusted Path / Secure Path / MITM / NGSCB / SAML / Liberty / Liberty Alliance / ID-FF

Liberty's Advanced Client Technologies

Today, the Liberty Alliance announced the availability of the public draft release of the Advanced Client Technologies specification set.

This is personally pretty important for me because:

• it is closely related to the Identity Capable Platform research work that I'm doing at Intel (which we demonstrated at the RSA Security Conference in a joint proof-of-concept with British Telecom & Hewlett-Packard)
• I was the editor of each of the specifications (with lots of great contributions from several other Liberty members -- even Paul, if you can believe that)
• I was quoted in the press release :-)

The advanced client work is some pretty cool stuff where we are taking the next step in the evolution of powerful client capabilities including:

• Trusted Module - the IdP can extend itself onto the user's device in a trusted way so that the user's device can act as an extension of the IdP and assert the user's identity independently of an active session with the IdP (for privacy and/or connectivity reasons).
• Provisioning - functionality can be provisioned over-the-air (or over-the-wire) in a trusted fashion with full life cycle support. So Trusted Modules can be provisioned to devices already in the field.
• Service Hosting/Proxying - enabling connectivity challenged devices to be the primary host of services (such as my PDA being my "official" contact book service) while providing a more stable network visible proxy to provide access to that service's data through either local hosting or proxying request to the client service.

This draft release is being done much earlier in the spec evolution process than Liberty has typically done in past specification releases as part of our attempt to be much more open in our specifications development process. I hope that you take some time to look at the specs and provide feedback and/or input. I would recommend starting with the Advanced Client Technologies Overview before digging into the other specifications.

The only negative in all of this is, as Paul surmised, I was unable to figure out a way to insert my blog url (http://conorcahill.blogspot.com for those few that don't know) into either the specs or the press release. I'll have to see if I can get that error fixed in the next release.

Tags : identity / Liberty / Liberty Alliance / Advanced Client / Intel / HP / BT

Mail Fraud

This week I've been off in the UK (in sunny, friendly Ipswich which is northeast of London) attending a Liberty Alliance Technology Expert Group (TEG) face-to-face meeting. Paul and I have been giving one of the other attendees (who works for Sun, but shall remain nameless) a hard time the entire week about an interesting work item that we want him to take on.

We discussed talking to his boss offline and having our management board reps approach his boss as well and clearly had him worried about the possibility.

So I used my mail server to forge a note from his boss stating:

Hubert,

Robin has advised me that he can no longer participate as the co-chair of the PPEG group within Liberty. Given that Sun needs to maintain it's visibility Liberty for our customer base, Eve and I have spoken and it seems that you would be an ideal candidate to step up as the next Chair of the TEG.

We need to talk further when you're back in town.

Bill

We thought about talking directly to Bill afterwards and getting him in on it so he could send a note to the nameless one with a "Why haven't you responded to my mail?" -- perhaps he will read this and do so :-).

Moral of the story: Don't believe email, especially if the sending server isn't within your own domain. George says there should be a thunderbird plug-in that will red-flag any email coming from one of my cahillfamily.com domain, but I pointed out that I host like 15 or so domains for friends, so I could easily work around such a restriction.

Tags : identity / fraud / Liberty / Liberty Alliance

Delegation, Impersonation, and downright access

This discussion is going on and on and people are talking about it from all points of view (including Kim, Pete, Dave, Paul, and Eve, who apparently started it all in a conversation with Jim). The conversation seems to be arguing about technical issues, but in reality it is mostly a semantic argument rather than a technical one.

From what I can gather, I think all of the parties agree that:

• The user can give permission to an entity to do "something" for the user at some later point in time.
• When this "something" occurs, the entity initiating the "something" needs to be identified as well as the user for whom the "something" is taking place.
• When this "something" occurs the user does not need to be physically present, online, or otherwise directly involved.

The points of disagreement seem to be in the area of how to refer to this taking place and whether or not this is supported by one protocol or another. I'm not married to the terms "user-not-present" (which is, physically true, by the way) nor the term "on behalf of", although I do think that both apply to this case. I'm also OK with the term "delegation".

One thing that hasn't been clearly discussed here is the case of real impersonation. There are real world cases where impersonation takes place, such as when an administrative assistant performs some tasks in the name of his boss (like sending flowers to my wife :-) ). I certainly don't want those flowers to indicate that they came from my admin. However, I still think that case is rooted in my admin authenticating as himself to a provider where I have granted permission for him to act in my name (perhaps for a particular set of tasks), so this seems like the same ultimate use case (me defining permissions on some resource I control).

So the last part in the discussion is onto the protocols. I can state unequivocally that Liberty ID-WSF does in fact fully support this use case and has explicit definition of all the parties involved in a transaction. Liberty also provides for the means for collection of the permissions necessary for the transaction as well as a means for an entity to indicate to the service provider that they intend to invoke a particular request later in a context where the user will no longer be present (so that the service provider can prompt for any necessary permissions from the user). At Liberty, we painstakingly walked through the entire use case and all of its related messages to ensure that the system would work in that case.

I do not understand how this same (or similar) sequence would be done using the WS-* family of specifications. I am sure it could be done, but I believe anyone doing so would be doing a one-off solution that would not interoperably work with anyone else's one-off solution as the protocols don't dictate a standard way to do this (yet). I would like to be wrong here and call on the WS-* guys to stand up and point out how this could be accomplished in a standard way that is expected to be interoperable.

Tags : identity / liberty / Liberty Alliance / WS-Trust / delegation / SAML / impersonation

SAML, Liberty and user presence

Clearly Kim Cameron doesn't understand Liberty Alliances's Identity-based Web Services Framework (ID-WSF) when he states:

One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.

This multi-token design perfectly supports strong identification of a service combined with presentation of a separate delegation token from the user. It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.

First off, I don't think hap-hazard combining of tokens is a way of ensuring that the user's desires are followed. So I presume there's something else going on that supports the correct combining of tokens within WS-Trust, not just the fact that I have the two tokens.

Secondly, in SAML (and specifically in ID-WSF's profile of SAML), the method used to connect the user token to the presenter is dictated by the Subject Confirmation within the token. Essentially this says that "to use this token, the presenter MUST meet the following condition" and that condition, in many circumstances, is the presentation of proof of possession of a key (thus securely binding the presentation of the token to the possession of a specific token by the provider). This is a clear, specific requirement that securely binds the presentation of the user token to the possession of a particular token by the provider.

Thirdly, we don't generally see the model of the user issuing tokens to a provider (most user's I know don't have a clue about how to create a token). The model we used is one of permission based identity sharing where there are appropriate controls provided by the various parties.

For example, the IdP would have a permission switch available to the user giving them control as to whether or not the service provider is allowed to obtain a token for the user when the user is not actively present (so, I would record at my IdP whether or not the service provider is allowed to get a token for me to talk to my payment service, perhaps because I setup automatic payments for that provider).

There are advantages to this model. First off the tokens used in any transaction would be short-term tokens rather than long lived delegation tokens (and as a security weenie, I always like shorter lived tokens better). Secondly, when and if the user would want to change this decision, they just needed to talk to the IdP and not go deal with tokens that they have lying about all over the place.

A second step in this permission based model is that the payment service itself would store permissions about what the other service provider is allowed to do in that context. I may have stored a permission that says the provider can do anything they want. I may have instead stored a more specific permission that says get OK from me for any transaction above $x. These permissions would be specific to the service that I'm giving access to.

In order to support the collection of these permissions, Liberty has identified specific methods used when the user is present to invoke a service indicating to the provider that the caller intends to invoke this service later when the user is not actively present. This allows the service provider to collect the necessary permissions from the user while the user is around.

One final note, Kim separately claims that the user is actually present when these transactions takes place since they consented to their operation at some point in the past. I disagree. Saying that the user is present just because a provider can identify me is a bit of a misleading statement. When my electric company charges my account for my electric bill each month, I am typically asleep and not in any way involved in the transaction. Any identity system that doesn't make that situation clear to all relying parties is, IMHO, wrong. The parties need to know if I'm sitting there instigating this particular transaction or if this is taking place when I'm asleep. Yes, it still should be able to take place when I'm asleep. Yes, it should securely identify who I am in the transaction. But no, it should not look the same as a transaction taking place in the context of a live authenticated session with me directly involved.

Tags : identity / liberty / Liberty Alliance / WS-Trust / delegation / SAML / liberty

Is it an AOL ID or an OpenID?

My friend (yes, I think I have one or two of those), George Fletcher, from AOL has started blogging and has broken through a threshold and actually written two blogs so far this month (and we're only just over half way through the month). Go George!!!

His latest blog entry discusses AOL's OpenID implementation and raises the question:

In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.

This falls into a discussion about whether or not the user is using their "OpenID" at the relying party, or are they using their "AOL ID" at the relying party.

I would think that AOL would want the user to consider that they were using their AOL ID and I would expect most users would understand that.

However, the OpenID folks seem to want the user to know they have an ID that is associated with the OpenID protocols and therefore understand that they aren't just using their AOL ID, but using their AOL ID via OpenID protocols (or, perhaps, that their AOL ID is actually an OpenID).

To me that just seems to complicate issues for normal users who don't understand (and don't want to understand) protocols or bits or bytes. All they want to do is to be able to leave comments on someone else's blog.

In the Liberty Alliance and in OASIS SSTC, we've always thought that the user wouldn't know or care they were using SAML or Liberty protocols to SSO into a relying party. The IdP and the relying party would care since they wanted security and interoperability, but not the user... The user just wants this stuff to work.

Tags : identity / OpenID / AOL / Liberty / SAML / Liberty Alliance