Category: Information Cards

Ben Laurie on Selective Disclosure (Part 2)

In introducing people to his Selective Disclosure paper, Google's Ben Laurie says: 

In fact, there are many ways CardSpace could violate the laws, but there is one which it is currently inherently incapable of satisfying, which is the 4th law – the law of directed identity – which says, once you’ve fought your way through the jargon, that your data should not be linkable.

Ben doesn't like the term “omni-directional identifier”, which is certainly his prerogative.  But speaking of jargon, note that according to the Oxford English Dictionary, Ben's word “linkable” doesn't actually exist… 

Meanwhile “omni-directional” is a real word from the field of telecommunications (isn't that what we are working in?)  It means “of equal sensitivity or power in all directions”.  Similarly, “unidirectional” means “moving or operating in a single direction”.

So I think the Fourth Law is precise enough:

A universal identity system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

The word “discovery” is again used in the technical sense of making it possible to locate and rendezvous with other entities.   The goal here is to embrace the range of use cases I discussed in part one. 

Ben argues that CardSpace breaks this Fourth Law.  In this he is wrong.  I suspect he is confusing CardSpace, which is just a way of selecting between identity providers, and the identity providers themselves.  Let's get that really straight.

CardSpace is one component of the Identity Metasystem – by which I mean a distributed mesh of parties asserting and depending upon identity.  CardSpace informs the user about the identity providers that can satisfy a given relying party request, and provides a mechanism to tell the user what information must be released to the relying party in order to gain admission to the site.  But the identity selector does not itself make assertions or sign them cryptographically, or do anything that introduces linkability or traceability.  If linkability is introduced, it is because of the choice of the identity provider people use with the the system, and of the cryptographic systems they employ.  

Privacy characteristics of the self-asserted Identity Provider 

While CardSpace is an identity selector, we have built it to include a self-asserted identity provider as a way to bootstrap the system.   So what are the privacy characteristics of this provider?

  • It emits no identifiers that allow the identity of the user on one system to be linked to the identity of the user on any other.  
  • A different signing key is used at each site visited so keys and signatures cannot be correlated.
  • Relying parties cannot collude with this identity provider because it is run by the user. 

So the Identity Provider that ships with CardSpace does not break the Fourth Law either.

Managed Card Providers 

Now let's talk about managed card providers, and think about other systems such as Liberty or Shibboleth or OpenID or SAML or WS-Federation in browser mode. 

These systems always identify the relying party to the identity provider.  They do so because they need to tell the identity provider how to redirect the client's browser back to the relying party.  So they are what I call panoptical by design.  There is zero collusion required for the identity provider to know what is being asserted where – that knowledge is designed right into the system.

CardSpace breaks with this paradigm, and I hope Ben comes to recognize this. 

To support use cases where we do NOT want linkability, CardSpace hides the identity of the relying party from the identity provider.  If we had built it without this feature, it too would have been “panoptical by design”.  But we didn't do that.  We built it to conform with the Fourth Law.  In other words, CardSpace does not provide unnecessary handles to facilitate linkability.

How does CardSpace hide the identity of the relying party?  It associates some random information – unknown to the identity provider – with each Information Card.  Then it hashes this random information (let's call it a “salt”) with the identity of the site being visited.  That is conveyed to the identity provider instead of the identity of the site.  We call it the “Client Pseudonym”.  Unlike a Liberty Alliance client pseudomym, the identity provider doesn't know what relying party a client pseudonym is associated with. 

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be.  Two users going to the same site would have cards containing different random information.  Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.   

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?  I'll discuss this next.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.   

Pamela Dingle on multiple issuers

Some clear and advanced thinking from Pamela Dingle at Eternal Optimist:

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

  • if a card’s issuer matches the value of the issuer parameter

  • if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

  • Common claim types are no longer needed to ensure the user picks the right card. This is good.

  • Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.

  • The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.

  • The system is more distributed, but MUCH less consistent for the user. This is bad.

  • It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Pam's thinking is unassailable.  The problems she outlines are issues we just didn't have time to solve in version 1.0 of CardSpace. 

We were aware of them, but wanted to get the first round of our technology “out there” so everyone could start doing proofs of concept and implementations that would help clarify the right approaches.  I think in practice we'll have time to fix this before people anyone really “feels” it.  Not all credit card providers will be supporting information cards at once.  Meanwhile we'll be pumping out more advanced versions of CardSpace that address the issue.  

The same problems Pam describes with respect to issuers apply with respect to RP support for multiple token types (e.g. SAML tokens plus OpenID tokens).  Currently we can address this by accepting “any” token type, and that will get us by for a while, but ultimately we will need to be able to specify rich combinations.

WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that has all the capabilities Pam calls for.  For example, you can say you will accept American Express AND Visa as issuers but not Diner's Club.  You can also require different claim types from different issuers.  So the architecture is adequate to the problems.  

So given that the architecture is right, it represents an opportunity for our competitors…  And we ourselves are working really hard to solve this problem in our next version – before it anyone feels the pain.

Information Card Contest

I was still reeling from the latest chicken pictures posted by James McGovern when I stumbled onto news of a contest put together by my colleague Richard Turner. 

James was complaining that the contest would slow down adoption in his case since it would break corporate policy to accept a prize.  I added a comment to his blog saying I would try to figure out a way that someone who could not accept the prize could make a charitable donation instead. 

But I didn't know what the prizes were until I read the original posting by Richard:

Identifying yourself online is becoming increasingly difficult and dangerous. Most people who use the web have to maintain several usernames and passwords and have to remember which usernames and passwords to use at the various sites they use.

While usernames and passwords are a growing frustration to most users, this problem is dwarfed by the growing threat of phishing and other forms of malware and identity-related attack.

Follow the wrong link and try to sign-in to a malicious site masquerading as, for example, your bank, and you run the very real risk of suffering considerable loss. These potential losses may be financial but may also impact your reputation (e.g. credit score) that may take years to repair.

Microsoft, along with many partners in the IT Industry, is building a suite of technologies to help combat the phishing issue, whilst making it easier for users to authenticate safely online. Technologies such as Windows CardSpace enable users to identify themselves by presenting cryptographically strong identity tokens (represented visually as information cards) to supporting websites.

To help fuel the growth of sites supporting Information Cards, Microsoft is announcing a competition that is open to every website owner, regardless of your web platform of choice. We hope you'll join us in helping to protect your user's identities from abuse and make it easier for your users to sign-in to your sites! 

How to enter

  • Add sign-up and sign-in support for Windows CardSpace to your website
  • Email the following to identity@microsoft.com
    • Details of your site
    • Your details
    • Complete this statement: “We added support for information cards to our site because …”
  • All entries will be judged by the CardSpace product team and winners announced on August 17, 2007. The winner will be notified by email.

The prizes

  • Grand Prize:
    • 1 Round-trip ticket (from and to a single location within the United States)
    • Overnight accommodation in a hotel near Microsoft Campus
    • Meet the team – spend a day with various members of Microsoft's Federated Identity team
    • Dinner with Kim Cameron
  • Second prize:
    • XBox 360 Elite Games Console
  • Third prize:
    • Zune music player

[Please note that due to international gaming laws we are only able to offer these prizes to US Residents and that any taxes incurred from receiving a prize is the sole responsibility of the prize winner(s).]

Adding support for Windows CardSpace to your site

  • The following resources will be indispensible in guiding you how to add support to your website:
  • If you have technical issues, please post questions to the Windows CardSpace discussion forum on MSDN – we'll be monitoring this forum closely and responding as quickly as we can. Note – if you contact us directly with support requests and your request is generic in nature, we'll ask you to post your question to the forum. This is the help others who may be experiencing the same issue as you and so that we can better manage potential support issues.

Anyway, that sounds like a lot of fun, and I'll make sure the winner gets a really incredible evening at one of the top restaurants in the region. 

And as for James, now I know what the prize is, if he wins we can just make it a working dinner at the local pub, taking on the role of Information Cards in the enterprise environment and all the other things I'd like to discuss with him from a purely business point of view.

Future of Active Directory

Here's a snippet from  another article by John Fontana that will be of interest to people wondering how much wood Microsoft is ready to put behind the claims based model.  Stuart Kwan has played a central role in the evolution of Active Directory and the emerging identity products: 

Las Vegas – Microsoft Tuesday laid out a vision for Active Directory in which it will take on a major role in pushing out user identity data to applications and securing collaboration between users.

“We are moving from being a directory provider to an identity provider,” said Stuart Kwan, director of program management for identity and access at Microsoft, during the second day keynote at the annual NetPro Directory Experts Conference.

He said the benefit for corporate users would be a standard user access mechanism that would benefit application development, access management and allow companies to more easily spread their identity systems.

Kwan concluded that Active Directory was so close to fulfilling its original goals as a trusted directory service for corporate users that it was time to look ahead and envision the next set of challenges.

The new challenges, Kwan said, will put the directory in a key role in Microsoft’s Identity Metasystem, a model for distributed identity architecture. Coupled with an emerging technology called Security Token Service (STS), which handles the exchange of identity data, Microsoft envisions an architecture that pushes identity data out to applications that know how to interpret and act upon that data.

Today, applications typically pull user access data from the directory to determine a user’s access rights. The push model not only affords network efficiencies but more easily ties identity and application development, puts less stress on the directory, provides more flexibility in defining a user and their rights and gives the ability to federate identity with those outside the corporate network.

Kwan said the push mechanism would be similar to the way group membership data for a user is automatically included in today’s Kerberos authentication process.

In the future, identity data coming from the directory would be transformed by the STS gateway into a properly formatted “claim” or a set of claims about the user and his access rights.   (Continued here)

My one clarification is that neither Stuart nor I are talking about “Microsoft's” identity metasystem”.  We are trying to build an identity metasystem that stretches across vendors and platforms and products and countries.  We're trying to do our part within this metasystem. 

Token Decryption Service for CardSpace

Via Richard Turner's blog, the announcement of an architecturally superior  token decryption component devised by Dominick Baier at leastprivilege.com. 

Dominick  and Richard have blogged previously about mitigating the dangers involved in allowing web middleware and front-end software to process encrypted payloads.  Decrypting a payload involves access to a private key.  The broader the range of applications that can get to the key, the greater the attack surface.  This led to discussions about:

  1. Re-factoring the token decryption code into an assembly that runs under full trust whilst the site runs under partial trust
  2. Building a Token Decryption Service to which you can pass your encrypted blob and you get back a list of claims, PPID and issuer key.

And that is exactly the problem Dominick has tackled:

Web Applications that want to decrypt CardSpace tokens need read access to the SSL private key. But you would increase your attack surface tremendously if you directly grant this access to the worker process account of your application. I wrote about this in more detail here and Richard Turner followed up here.

Together with my colleagues at Thinktecture (thanks Christian and Buddhike for code reviewing and QA) I wrote an out-of-proc token decryption service that allows decrypting tokens without having to have direct access to the private key in the application, the idea is as follows:

Your web application runs under its normal least privilege account with no read access to the private key. The token decryption service runs as an NT service on the same machine under an account that has read access. Whenever the application has to decrypt a token, it hands the encrypted token to the token decryption service which (in this version) simply uses the TokenProcessor to return a list of claims, a unique ID and the issuer key.

The token decryption service is implemented as a WCF service that uses named pipes to communicate with the applications. To make sure that only authorized applications can call into the service, the application(s) have to be member of a special Windows group called “TokenDecryptionUsers” (can be changed in configuration to support multiple decryption services on the same machine). I also wrote a shim for the WCF client proxy that allows using this service from partially trusted web applications.

The download contains binaries, installation instructions and the full source code. I hope this helps CardSpace adopters to improve the security of their applications and servers. If you have any comments or questions – feel free to contact me.

The approach is a good example of the “alligators and snakes” approach I discussed here recently.

Christian shows his controls for Visual Studio

Christian Arnold has now done a video where he shows how simple it is to add Information Card support to the “out of the box” Visual Studio membership provider. He has written some really cool controls. 

I think Christian is right on target – at the head of the pack in terms of getting this type of tool out there.  He invites people to download his controls and try them out.

When I first ran the video from his page it chopped off the properties part of the screen – which is the interesting part.  If this happens just right mouse click on the player and select “full screen”. 

Windows Financial Services “Best of the Blogs” list

I'm pleased to see the editors of Windows in Financial Services put identityblog on its “Best of the Blogs” list.   Welcome to any readers who “get here from there.” 

It's impressive for a publication so intensely focussed on financial services to invite its readers into a parallel universe which, as the editors put it, “…addresses the innumerable ramifications of this growing problem [identity theft – Kim]…”.  Yup.  There are definitely a lot of ramifications around here.

Identity theft is fast progressing as a huge threat to financial institutions everywhere, especially in the area of online banking.  In his “Identity Weblog,” Kim Cameron, Microsoft’s architect for identity, addresses innumerable ramifications of this growing problem, ranging from illegal sale of stolen credit card information on the Web, to whether or not schoolchildren should be fingerprinted, to technical solutions such as encryption. 

In an April 2nd entry, Kim answers questions from his readers about CardSpace, an encryption technology that can be enabled for .NET 2.0 through the use of Visual Studio 2005 Toolbox for Windows CardSpace. C lick below to read Kim’s advice on subjects such as how CardSpace prevents phishing – even when used in conjunction with passwords – and to find out how to ask him ID-related questions of your own.

So, welcome to any new readers and please make yourselves at home.  Extra bonus:  you'll have a chance to use CardSpace when posting comments.

newtelligence CardSpace API

Sergey Shishkin reports that a new developer's kit will be released by newtelligence AG.

newtelligence AG announces plans to release the newtelligence CardSpace SDK, a Software Development Kit for Microsoft Windows CardSpace. The SDK, based on newtelligence expertise in information security, will help developers build more robust CardSpace-enabled application on the .NET platform – with ease.Microsoft .NET Framework 3.0 was released in November 2006 and introduced Windows CardSpace – a user-centric digital identity solution.

CardSpace allows developers to leverage federated security and single sign-on in their solutions. As a leading security expert company, newtelligence investigated .NET Framework 3.0 and Windows CardSpace starting from its early, pre-released versions and developed technology samples to clearly demonstrate to customers the underlying technology as well as provide best practices for its use.

Although CardSpace is based on the standardized web service security protocols (WS-* standards), developing CardSpace-enabled applications is challenging. Developers have to possess solid knowledge not only in web service security protocols but also in cryptography and XML.

newtelligence SDK for Windows CardSpace will provide a comprehensible API for key CardSpace application scenarios: Programmatic creation of managed information cards; requesting and validating security tokens in Microsoft Windows and web applications; and issuing security tokens. Use of the API will increase software security and developer productivity: Writing secure software is simplified and less software coding is required to achieve the desired, secure functionality. To aid understanding of the SDK and of CardSpace in general, a reference application and additional code samples covering different aspects of the API usage will accompany the SDK.

The newtelligence CardSpace SDK will contain complete source code of the API and is intended for personal use only. For more information regarding availability, licensing or reuse of the SDK, please contact us.

One of Sergey's readers comments:

How about just releasing it instead of announcing the announcement 😉

Sergey responds:

Dominick, the work is in progress now. The release is of course the goal 🙂

I'm glad to see Dominick so itchy.  Sergey says he will host a discussion about the API on his blog.

Mike Jones and self-issued.info

Everyone who has met me has probably met my colleague Mike Jones, who put his work as a researcher at MSR on hold because he got so interested in user-centric identity and Information Cards.  He has now started to blog – check out the InfoCard showing Mike and Dale onstage at Novell Brainshare. 

For those new to Information Cards, you don't normally share an InfoCard with someone else.  This was truly a “they did it because they could” moment… 

On March 21st at Novell’s BrainShare 2007 conference, Dale Olds and I co-presented the session “Who are you? From Directories and Identity Silos to Ubiquitous User-Centric Identity”. Our presentation was a brief history of digital identity solutions, ranging from a password per application to interoperable user-centric digital identity using the Information Card metaphor and several steps in between.

demo self-issued cardThe coolest thing in the session was the first public demo of the Bandit/Higgins cross-platform Identity Selector. During the demo Dale and I both used the same self-issued Information Card (that I created on the BrainShare show floor 🙂 ) to log into a Bandit relying party site, Dale from Linux and me with Windows CardSpace. As Dale and Pat Felsted blogged, two days later the Bandits also demonstrated their selector running on the Mac. Also see Pat’s post on the Details of the Cross Platform Identity Selector.

Great progress towards enabling everyone to answer the question “Who are you?” online with the Information Card of their choice!

BTW, you'll see that Mike, like me, is using pamelaware for WordPress – and accepts comments through infocards.  If you use WordPress, you should check it out.