Here's the most beautiful take yet on the Seven Laws of Identity - put together by Karon and Katrika, who even saw how the Laws connect with the Perception of Ailatan. In the past people have asked why I didn't do a Laws of Identity poster – this must be it. Click to view full size.
After my last post, it occurred to me that people would probably be interested in knowing about some of the other figures from the identity community who have joined my colleagues and I to work on identity and access – great people with diverse backgrounds who bring new depth to the increasingly important area of identity and access management.
I'm going to break this up across several posts in order to keep things manageable…
Ariel Gordon came to Microsoft recently from Orange / France Telecom. It's really key for the Identity group at Microsoft to have the best possible relationships with our colleagues in the Telecom sector, and Ariel's 12 years of experience and understanding of Telecom will move our dialog forward tremendously.
Ariel led the creation and deployment of Orange's consumer Identity Management system, focusing his staff on optimizing customer journeys and UX through Identity lifecycles. The system currently hosts tens of millions of user identities across Europe.
Ariel oversaw marketing work (and the development of business planning) for Identity Management and other Enablers, including User Privacy and API exposition framework. As a key spokesperson for Orange, he unveiled several of their innovations at Industry Events including their support of OpenID and SAML for Outbound Federation at “DIDW” in Sept 2007, and support of OpenID and LiveID for Inbound Federation at “the European Identity Conference” in April 2008.
Orange played an important role in Liberty Alliance, and Ariel has a lot to share with us about Liberty's accomplishments. Listen to Kuppinger Cole's Felix Gaehtgens interview Ariel on YouTube to get a real sense for his passion and accomplishments.
Many people around Internet Identity Workshop know Pete Rowley, not only for the work he has done but because he has a coolio rock-star-type web page banner and a real stone fence:
Pete has been working on identity since the mid 90’s. He contributed to the Netscape Directory Server. Later at Centrify he worked on connecting heterogeneous systems to the Active Directory infrastructure for authentication and policy applications. Many of us met him at the Identity Gang meetings while he worked for Red Hat. There he founded the Free IPA (Identity, Policy, Audit) open source project. I remember being impressed by what he was trying to achieve:
“For efficiency, compliance and risk mitigation, organizations need to centrally manage and correlate vital security information including
- Identity (machine, user, virtual machines, groups, authentication credentials)
- Policy (configuration settings, access control information)
- Audit (events, logs, analysis thereof)
“Because of its vital importance and the way it is interrelated, we think identity, policy, and audit information should be open, interoperable, and manageable. Our focus is on making identity, policy, and audit easy to centrally manage for the Linux and Unix world. Of course, we will need to interoperate well with Windows and much more.
Now he's working on evolving the Identity Lifecycle Manager (ILM).
Mark Wahl has been well known to identerati ever since the early days of LDAP. In 1997 he published RFC2251, the famous Lightweight Directory Access Protocol (V3) Specification with Tim Howes and Steve Kille. Of course it was fundamental to a whole generation of directory technology.
People from the directory world may remember Mark as Senior Directory Architect at Innosoft International, and co-founder and President of Critical Angle. This was great stuff – his identity management, directory, PKI, messaging and network middleware systems were deployed at many large enterprises and carriers.
Mark was also a Senior Staff Engineer and Principal Directory Architect at Sun Microsystems, and later developed and taught a one-year course on information assurance and computer security auditing at the University of Texas.
His passion for auditing and risk assessment technologies for the enterprise identity metasystem led him to create a startup called Informed Control. You get a good feeling for his thorough and no-holds-barred commitment by browsing through the site.
Mark is now applying his creativity to evolving the vision, roadmap and architecture for the convergence of identity and security lifecycle management products.
[To be continued…]
There has been a lot of coverage of the newly formed Information Card Foundation (ICF) in the last couple of days, including stories by mainstreet publications like the New York Times. This article by Richard Thurston from SC Magazine gives you a good idea of how accurately some quite technical concepts were interpreted and conveyed by our colleagues in the press.
Google and Microsoft are among an extensive set of technology vendors aiming to spur the adoption of digital identity cards.
The two internet giants have helped form the Information Card Foundation (ICF), which aims to develop technologies to secure digital identities on the internet and which was launched today.
Digital identity cards are the online equivalent of a physical identity card, such as a driver's license. The idea is that internet users will have a virtual wallet containing an array of digital identity cards, and they can choose what information is stored on each card. The aim is to replace usernames and passwords in an effort to improve security.
Alongside Google and Microsoft, large suppliers such as Novell, Oracle, PayPal and financial information company Equifax, have joined the ICF, as well as 18 smaller suppliers and industry associations.
“Our shared goal is to deliver a ubiquitous, interoperable, privacy-respecting federated identity layer as a means to seamless, secure online transactions over network infrastructure,” said Brett McDowell, executive director of Liberty Alliance, one of the founding members.
The idea of digital identities is far from new. But so far vendors’ efforts have been fragmented and largely not interoperable.
The ICF is proposing a system based on three parties: the user, the identity provider (such as a bank or credit card issuer) and also what it calls a reliant party (which could be a university network, financial website or e-commerce website, for example).
The ICF argues that, because all three parties must be synced in real-time for the transaction to proceed, it should be more secure.
“Rather than logging into websites with usernames and passwords, information cards let people ‘click-in’ using a secure digital identity that carries only the specific information needed to enable a transaction,” said Charles Andres, executive director of the ICF. “Businesses will enjoy lower fraud rates, higher affinity with customers, lower risk and more timely information about their customers and business partners.”
The ICF now wants to expand its membership to include businesses, such as retailers and financial institutions, as well as government organizations.
It also wants to become a working group of Identity Commons, a community-driven organization which promotes the creation of an open identity layer for the internet.
Despite my repeated requests not to go there, Paul Madsen of ConnectID has published a leaked, top secret, internal Microsoft Identity and Access photo. His post reads as follows:
An un-named source in Redmond sent me this never before seen picture of the first ever infocards assembly line.
In the front you can see a worker inserting secret keys obtained from the bins below (the punch-card calculating machines on which those keys were generated are in another room). Other workers further down the line can be seen inserting attributes before securing the top of the cards with wrenches.
My source tells me that another line is planned.
Luckily, the IP revealed by this photo is part of the Open Specification Promise (OSP). I checked with our operations people to see if the items in the bin really are the secret keys, but apparently they are silver bullets.
“In subsequent exchanges Kim and Conor plead the charges down from a felony to a misdemeanor. Kim allows that the redirection is OK so long as the IdP is completely trusted, but he is concerned about the case where the IdP is not trustworthy…
It's probably true that my “hand in wallet” metaphor was a bit stark. But how can I put this? I'm doing a threat analysis. Saying everything is OK because people are trustworthy really doesn't get us very far. Even a trustworthy IdP can be attacked; threats remain real even in the light of mitigations.
When we put on our security hats, and look at the security of a system, we try as hard as we can to explore every possible thing that can go wrong, and develop a complete profile of the attack vectors. No one says, “Hey, don't talk about that attack, because we've done this or that to prevent it.” Instead, we list the attack, we list what we do to mitigate it, and we understand the vulnerability. We need to do the same thing around the privacy attack vectors. It is revealing that this doesn't seem to be our instinct at this point in time, and reminds me of the days, before the widespread vulnerability of computer systems became apparent, when people who brought up potential security vulnerabilities were sent to stand in the corner.
What is missing from this discussion is the point that “automatic redirection” is not mandated by SAML. Redirection, yes, but automatic redirection is not required. The SP could very well have presented at page to the user that says:
“Your browser is about to be redirected www.youridp.com for the purposes of establishing your identity. If you consent to this redirection, press Continue. If you do not consent, press Cancel….
Correct. This could be done. But information can also be made to fly around with zero visibility to the user. And that represents a risk.
Nobody does this kind of warning because the average user doesnâ€™t want to be bothered and isnâ€™t concerned with it. Not as concerned as, for instance, having a stranger reach into their pocket.
Actually, thanks to “invisible system design”, the “average user” has no idea about how her personal information is being sent around, or that with redirection protocols, her own browser is the covert channel for sharing her identity information between sites. This might be all right inside an enterprise, when there is an implicit understanding that the enterprise shares all kinds of personal information. It might even be OK in a portal, where I go to a financial institution and expect it to share my information with its various departments and subsidiaries. But in the age of identity theft, I'm not so sure she would not be concerned with the invisible exchange of identity information between contextually unrelated sites. I think she would probably feel like a stranger were reaching into her wallet.
To be clear, my initial thinking about the “hand in wallet” came not from SAML, but from X.509, where the certificates described in Beyond maximal disclosure tokens are routinely and automatically released to any site that asks for them without any user approval. SAML can be better in this regard, since the IP is able to judge the identity of the RP before releasing anything to it. In this sense, not just any hand can reach into your wallet – just a hand approved by the “card issuer”… This is better for sure.
Do we need to nag users as Jeff suggests might be the alternative? No. Give the user a smart client, as is the case with CardSpace or Higgins, and whole new user experiences are possible that are “post nagging”. The invisibility threat is substantially reduced.
In my next post in this series I'm going to start looking at CardSpace and linkability.
I concluded my last piece on linkability and identity technology by explaining that the probability of collusions between Relying Parties (RPs) CAN be greatly reduced by using SAML tokens rather than X.509 certificates. To provide an example of why this is so, I printed out the content of one of the X.509 certificates I use at work, and here's what it contained:
|Serial Number||13 9b 3c fc 00 03 00 19 c6 e2|
|Issuer||CN = IDA Enterprise CA 1|
|Valid From||Friday, February 23, 2007 8:15:27 PM|
|Valid To||Saturday, February 23, 2008 8:15:27 PM|
|Subject||CN = Kim Cameron
OU = Users
DC = IDA
DC = Microsoft
DC = com
|Public Key||25 15 e3 c4 4e d6 ca 38 fe fb d1 41 9f
ee 50 05 dd e0 15 dc d6 2a c3 cc 98 53
7e 9e b4 c7 a5 4c a7 64 56 66 1e 3d 36
4a 11 72 0a eb cf c9 d2 6c 1f 2e b2 2a
67 4f 07 52 70 36 f2 89 ec 98 09 bd 61
39 b1 52 07 48 9d 36 90 9c 7d de 61 61
76 12 5e 19 a5 36 e2 11 ea 14 45 b1 ba
12 e3 e2 d5 67 81 d1 1f bb 04 b1 cc 52
c2 e5 3e df 09 3d 2b a5
|Subject Key Identifier||35 4d 46 4a 13 c1 ae 81 3b b8 b5 f4 86 bb 2a c0 58 d7 ad 92|
|Enhanced Key Usage||Client Authentication (18.104.22.168.22.214.171.124.2)|
|Subject Alternative Name||Other Name – Principal Nameemail@example.com|
|Thumbprint||b9 c6 4a 1a d9 87 f1 cb 34 6c 92 50 20 1b 51 51 87 d5 a8 ee|
Everything shown is released every time I use the certificate – which is basically every time I go to a site that asks either for “any old certificate” or for a certificate from my certificate authority. (As far as I know, the information is offered up before verifying that the site isn't evil). You can see that there is a lot of information leakage. X.509 certificates were designed before the privacy implications (to both individuals and their institutions) were well understood.
Beyond leaking potentially unnecessary information (like my email address), each of the fields shown in yellow is a correlation key that links my identity in one transaction to that in another – either within a single site or across multiple sites. Put another way, each yellow field is a handle that can be used to correlate my profiles. It's nice to have so MANY potential handles available, isn't it? Choosing between serial number, subject DN, public key, key identifier, alternative name and thumbprint is pretty exhausting, but any of them will work when trying to build a super-dossier.
I call this a “maximal disclosure token” because the same information is released everywhere you go, whether it is required or not. Further, it includes not one, but a whole set of omnidirectional identifiers (see law 4).
SAML tokens represent a step forward in this regard because, being constructed at the time of usage, they only need to contain information relevant to a given transaction. With protocols like the redirect protocol described here, the identity provider knows which relying party a user is visiting.
The Liberty Alliance has been forward-thinking enough to use this knowledge to avoid leaking omnidirectional handles to relying parties, through what it calls pseudonynms. For example, “persistent” and “transient” pseudonyms can be put in the tokens by the identity provider, rather than omnidirectional identifiers, and the subject key can be different for every invocation (or skipped altogether).
As a result, while the identity provider knows more about the sites visited by its users, and about the information of relevance to those sites, the ability of the sites to create cross-site profiles without the participation of the identity provider is greatly reduced. SAML does not employ maximal disclosure tokens. So in the threat diagram shown at the right I've removed the RP/RP collusion threat, which now pales in comparison to the other two.
As we will see, this does NOT mean the SAML protocol uses minimal disclosure tokens, and the many intricate issues involved are treated in a balanced way by Stefan Brands here. One very interesting argument he makes is that the relying party (he calls it “service provider or SP), actually suffers a decrease in control relative to the identity provider (IP) in these redirection protocols, while the IP gains power at the expense of the RP. For example, if Liberty pseudonyms are used, the IP will know all the customers employing a given RP, while the RP will have no direct relationship with them. I look forward to finding out, perhaps over a drink with someone who was present, how these technology proposals aligned with various business models as they were being elaborated.
To see how a SAML token compares with an X.509 certificate, consider this example:
You'll see there is an assertionID, which is different for every token that is minted. Typically it would not link a user across transactions, either within a given site or across multiple sites. There is also a “name identifier”. In this case it is a public identifier. In others it might be a pseudonym or “unidirectional identifier” recognized only by one site. It might even be a transient identifier that will only be used once.
Then there are the attributes – hopefully not all the possible attributes, but just the ones that are necessary for a given transaction to occur.
Putting all of this together, the result is an identity provider which has a great deal of visibility into and control over what is revealed where, but more protection against cross-site linking if it handles the release of attributes on a need-to-know basis.
Conor Cahill (Conor's Web log of Esoterica) responds to my discussion about SAML protocol and linkability in a piece called 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 at this point in the flow, but encourage the reader to look at his piece…
Conor mentions the emerging ideas for a SAML 2.0 Enabled Client/Proxy. I want to make it clear I wasn't analysing these proposals. I was analysing SAML as everyone knows it today - using the “http redirect” and “post” modes that have been widely deployed in portals all over the world, and don't require changes to the browser.
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.
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 points b) and c) above would likely apply. But we are looking at linkability precisely to judge the threats in the case where 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.
In terms of Conor's point about letting his telephone company deduct directly from his bank account, that's a use case that “rings true”, but there are few companies to which I would want to give this ability. That's my point. We need a spectrum of technologies to handle different use cases and risk profiles.
[Update: Conor later relents a bit in Perhaps not so much Bashing, bringing up a number of points I hope to make part of this exposition.]
â€¦And when did it know it?
Kim Cameron sums up the reasons why we need to understand the technical possibilities for how digital identity information can affect privacy; in short, we canâ€™t make good policy if we donâ€™t know how this stuff actually works.
But I want to call out one assertion he (and heâ€™s not the only one) makes:
First, part of what becomes evident is that with browser-based technologies like Liberty, WS-Federation and OpenID, NO collusion is actually necessary for the identity provider to â€œsee everythingâ€.
The identity provider most certainly does not â€œsee everythingâ€. The IP sees which RPs you initiate sessions with and, depending on configuration, has some indication of how long those sessions last. Granted, that is *a lot* of information, but itâ€™s far from â€œeverythingâ€. The IP must collude with the RPs to get any information about what you did at the RP during the session.
Completely right. I'll try to make this clearer as I go on. Without collusion, the IP doesn't know how the user actually behaved while at the RP. I was too focussed on the “identity channel”, thinking about the fact that the IP knows times, what RPs were visited, and what claims were released for each particular user to each RP.
Eric Norman, from University of Wisconsin, has a new blog called Fun with Metaphors and an independent spirit that is attractive and informed. He weighs in to our recent discussion with Collusion takes effort:
Now don't get me wrong here. I'm all for protection of privacy. In fact, I have been credited by some as raising consciousness about 8 years ago (pre-Shibboleth) in the Internet2 community to the effect that privacy concerns need to be dealt with in the beginning and at a fundamental level instead of being grafted on later as an afterthought.
There have been recent discussions in the blogosphere about various parties colluding to invade someone's privacy. What I would like to see during such discussions is a more ecological and risk-assessing approach. I'll try to elaborate.
The other day, Kim Cameron analyzed sundry combinations of colluding parties and identity systems to find out what collusion is possible and what isn't. That's all well and good and useful. It answers questions about what's possible in a techno- and crypto- sense. However, I think there's more to the story.
The essence of the rest of the story is that collusion takes effort and motivation on the part of the conspirators. Such effort would act as a deterrent to the formation of such conspiracies and might even make them not worthwhile.
Just the fact that privacy violations would take collusion might be enough to inhibit them in some cases. This is a lightweight version of separation of duty — the nuclear launch scenario; make sure the decision to take action can't be unilateral.
In some of the cases, not much is said about how the parties that are involved in such a conspiracy would find each other. In the case of RPs colluding with each other, how would one of the RPs even know that there's another RP to conspire with and who the other RP is? That would involve a search and I don't think they could just consult Google. It would take effort.
Just today, Kaliya reported another example. A court has held that email is subject to protection under the Fourth Amendment and therefore a subpoena is required for collusion. That takes a lot of effort.
Anyway, the message here is that it is indeed useful to focus on just the technical and cryptographic possibilities. However, all that gets you is a yes/no answer about what's possible and what's not. Don't forget to also include the effort it would actually take to make such collusions happen.
First of all, I agree that the technical and crypto possibilities are not the whole story of linkability. But they are a part of the story we do need to understand a lot more objectively than is currently the case. Clearly this applies to technical people, but I think the same goes for policy makers. Let's get to the point where the characteristics of the systems can be discussed without emotion or the bias of any one technology.
Now let's turn to one of Eric's main points: the effort required for conspirators to collude would act as a deterrent to the formation of such conspiracies.
First, part of what becomes evident is that with browser-based technologies like Liberty, WS-Federation and OpenID, NO collusion is actually necessary for the identity provider to “see everything” – in the sense of all aspects of the identity exchange. That in itself may limit use cases. It also underlines the level of trust the user MUST place in such an IP. At the very minimum, all the users of the system need to be made aware of how this works. I'm not sure that has been happening…
Secondly, even if you blind the IP as to the identity of the RP, you clearly can't prevent the inverse, since the RP needs to know who has made the claims! Even so, I agree that this blinding represents something akin to “separation of duty”, making collusion a lot harder to get away with on a large scale.
So I really am trying to set up this continuum to allow for “risk assessment” and concrete understanding of different use cases and benefits. In this regard Eric and I are in total agreement.
As a concrete example of such risk assessment, people responsible for privacy in government have pointed out to me that their systems are tightly connected, and are often run by entities who provide services across multiple departments. They worry that in this case, collusion is very easy. Put another way, the separation of duties is too fragile.
Assemble the audit logs and you collude. No more to it than that. This is why they see it as prudent to put in place a system with properties that make routine creation of super-dossiers more difficult. And why we need to understand our continuum.
Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters. And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst. This really adds to the momentum.
There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.
Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingleâ€™s introduction to Cardspace.
Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.
If IE isnâ€™t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameronâ€™s blog, which you can obviously do with CardSpace.
There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I donâ€™t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.
The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.
While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.
For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.
Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.
I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user. I think that depends on whether they are combined with a challenge such as a one-time password. I hope Jeff writes more about what he means by this.