Category: Information Cards

New CardSpace Techie Blog

Caleb Baker, Ruchi Bhargava and a group of their colleagues on the CardSpace team have set up a new blog by techies for techies, called CardSpace: Behind the Code.  It warms my heart to see the team members reaching out to make direct contact with other developers and engineers who are adopting the technology or creating versions on other platforms.  So often developers in big companies are caught behind a wall of gauze.

They begin with a post that talks in depth about a change in CardSpace that I first announced in June here.  Basically, without in any way decreasing the security of high end sites, we have made it markedly easier for bloggers and others whose sites don't represent a financial honeypot to accept information cards:

“CardSpace in .Net Framework 3.0 required that sites deploying CardSpace always have a SSL certificate. This meant that every site that wanted to use CardSpace was forced to deploy an https site.

“Based on customer feedback, we have decided to relax this requirement for the next release of CardSpace (currently available in .NET Framework 3.5 Beta 2). We realize that there are some sites like blogs which would like to use CardSpace, but consider the SSL requirement to be a deployment blocker.

“Now, if you have a website that you want to add CardSpace support to, all you need to do is add the object tag to the page and you are done.

“In addition to requiring .Net Framework 3.5 beta 2 or later [on the windows client – Kim], a new version of icardie.dll is required to use this new feature. This will ship with Vista SP1 and an upcoming update to IE7.

“CardSpace does behave differently for http vs. https sites. When CardSpace is invoked from an http site, CardSpace will inform the user about the lack of an SSL connection and the security implication of this. (Also, note the new streamlined look of this window.)

CardSpace without SSL 

“In addition, managed card issuers can decide if the card they issued can be used on sites that do not support SSL. This can be done by adding the following element to the .crd file. If this element is specified then the card can only be used on a site that has a SSL certificate. The card will not ‘light up’ when the user is on an http site.

“A point to be noted is that cards that were issued for last release of CardSpace will light up on http sites as they will lack this new element. In that case, the IP STS can make a decision on whether to release a token based on the identity of the recipient sent in the RST message…”

[Continues with changes in algorithms here.]

In one of the posted comments, reader MathiasR tells the team:

“Great to hear that you are listening to our feedback :). Thanks!”

Meanwhile, the MSDN blog site they're on doesn't yet seem to show any signs of supporting Information Cards for leaving comments.  Maybe I'm just missing it, or maybe Caleb can drum up some info on when that is going to be turned on.

Linkage with CardSpace in Auditing Mode

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

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

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

What changes with CardSpace?

CardSpace is based on a different protocol pattern in which the user’s system is active too.  Continue reading Linkage with CardSpace in Auditing Mode

The CardSpace dimensions

Axel Nennker from T-Systems in Germany now has a blog called ignisvulpis (OK, no translation found in search engines – I had to crack open my latin dictionary to be reminded that ignis means ‘fire’ and vulpes means ‘fox’…   Yikes, Axel!)  Axel is a contributor to the openinfocard project started by Chuck Mortimore and Ian Brown.

In a bizarre case of Information Card Fever sweeping through Germany, he writes:

Yesterday I learned that the team of the new java CardSpace project jinformationcard works in the same building as I do. As I am a contributor to the openinfocard project we now have two independent java CardSpace projects “in the house”. 

That's amazing.

Anyway, I heard Axel speak at a meeting a while ago and was fascinated by the way he conceptualized his “information card dimensions”.   Now I can share it with you because he posted it to his blog:

While thinking about how Windows CardSpace could be used and extended I came up with this graphic.

Thus the dimensions of Windows CardSpace are:

  1. Cardstore: Where is the cardstore?
    Service Providers store the information cards and facilitate the use through different devices.
  2. CredentialStore: Where are the credentials?
    Storage of credentials and engine for cryptographic operations.
  3. UI Generation: Where is the UI generated?
    The UI could be generated on a server but be displayed on one of the user’s devices.
  4. Identity Selector (UI): Where is the UI displayed and where is the Information Card selected?
  5. STS: Where is the STS?
  6. STS Authentication: Authentication Technology
  7. Browser: On which device is the authentication needed?

Now imagine all the combinations of the coordinates which span “use case space”.  My colleague Jochen Klaffer designed and implemented a tool which helped us a lot to find relevant use cases in our “CardSpace for Telcos” project which we are doing for Deutsche Telekom Laboratories’ Jörg Heuer.

This is of course only a selection of possible dimensions.  Others were excluded for simplicity and because there are strong indications that they will never be relevant.  Kim Cameron said e.g. about using different protocols instead of WS-*: “This will not happen”.

So the “Trust Protocol” dimension is not shown in this graphic.

Other dimensions missing are new transport protocols like SIP instead of HTTP to transport the RST/RSTR. So the “Transport Protocol” dimension is not shown in this graphic.

You will probably notice that there are points on the axis that are not part of CardSpace version 1.0…

Let us look at CardSpace 1.0.

  1. Cardstore: local (secure desktop).
  2. CredentialStore: local (secure desktop).
  3. UI Generation: local (secure desktop).
  4. Identity Selector (UI): local (secure desktop)
  5. STS: local or network
  6. STS Authentication: fixed set of four technologies
  7. Browser: PC

So this the current state, but the universe is expanding, right?

Interpretation of the axes and the new points the axes is left to the reader 😉

I think this is really brilliant and have been amazed at the methodologies being used.  I hope Axel will also report on the work by Jochen Klaffer to which he refers.

One small correction – we already support a simple RESTful http post of a token to a relying party – in other words, no need for WS.  So there is a protocol dimension.  In terms of the highly trusted connection between identity selector and identity provider, I would much rather avoid introducing alternate protocols that would drastically increase our attack surface and test matrix.

Paul Madsen leaks internal photo

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.

Catalyst Interopathon reveals sea change

Here are the logos of the projects participating in the Information Card Interopathon at the Burton Group's Catalyst Conference. Beyond that, people told me about at least half a dozen new open source projects (each with a unique mission) that are sitting in the wings getting ready to go public.  I'll try to keep you posted on these. 

We had a rehearsal for this a couple of months ago at Internet Identity Workshop, but something has changed since then:  many of the players seem to have made strides in getting concrete about how the technology would be used in their products.  That's the key.

According to the press release:

Participants include projects groups Eclipse Higgins Project, Internet2 Shibboleth Project, The Pamela Project, Ian Brown (OpenInfoCard), XMLDAP, and SocialPhysics and vendors BMC Software, CA, FuGen Solutions, IBM, Microsoft, NetMesh, Novell, Nulli Secundus, Oracle, Ping Identity, Sxip Identity, VeriSign, and WSO2.

The demonstration will be centered on a photo sharing application and will show the breadth and maturity of user-centric technologies by executing a variety of information card-based component capabilities including:

  • Protocol and wire format interoperability
  • Card format interoperability
  • Policy interoperability
  • Platform interoperability 

The interop event was organized by OSIS and identity commons and hosted by The Burton Group.  Thanks to all involved.

Control, not nagging

In a piece called Pleading down the Charges, Jeff Bohren of talkBMC  refers to the discussion I've had with Conor about invisible redirection as ‘inflammatory’, and adds: 

“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.

Jeff continues:

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.

Jeff concludes:

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.

CardSpace control for ASP.NET

Dominick Baier at LeastPrivilege has made leaps and bounds in his CardSpace control for the Microsoft ASP.NET environment (though it should work equally well for people using a Higgins identity selector or managed card).  It is very cleanly designed.  Amazingly, he's already added support for the new icon (does he ever sleep?).  His blog has an ongoing discussion around the control and related issues:

After I made some incremental changes and releases of my CardSpace control (found some bugs, got some feedback), I wanted to consolidate all the information along with a new version and some new features here. It now contains all the features I need and will be the last release for some time i guess.

If you have any feedback or suggestions feel free to write me or leave me a comment. If you want to add support for XHTML, contact me too 😉

Download here. Have fun!

PS. This was only possible with a little help of my friends…thanks Brock and JasonD!

Features

Easy to use syntax
One of my main goals was to have an easy to use markup syntax and intellisense support. I don't want to type in all those namespace URIs…

<lp:CardSpaceSelector runat="server" ID="_selector_sic" AutoPostback="true" 
    IssuerType="SelfIssued"> 

    <lp:ClaimType Name="givenname" /> 
    <lp:ClaimType Name="surname" /> 
    <lp:ClaimType Name="email" /> 

</lp:CardSpaceSelector>

Clean markup and independence of the server form
The emitted markup works with Firefox and IE. I also made sure that the <object> tag is placed outside of the postback form. This allows you to have multiple postback controls on the form without triggering the identity selector.

Support for standard InfoCard image
You can choose between all standard sizes of the official InfoCard image. You can also supply your own image and dimensions

Designer integration
I never use the designer – but I acknowledge the fact that some people do 😉 The control renders correctly in the designer and has an editor to setup the required/optional claims (including intellisense support).

Event driven
The control fires an event when a token is submitted.

protected void _selector_sic_TokenSubmitted(object sender, TokenSubmittedEventArgs e) {     string xmlToken = e.Token; }

Conditional rendering
You can choose to render the control only if the client browser supports InfoCards. You can specify an alternative <div /> that would render in that case (e.g. to tell the user how to get CardSpace).

Decoupling
I intentionally didn't couple the control with any user management semantics (like membership) or decryption clases (like the TokenProcessor). It is totally up to you how to proceed after you received the encrypted token. This is considered a feature 😉

Properties

InfoCard setup

IssuerType
This enum has two values ‘SelfIssued’ and ‘Managed’. If you select ‘SelfIssued’ then the issuer URI for self-issued cards will be emitted. If you select ‘Managed’ you have to set the issuer URI yourself. Defaults to ‘SelfIssued’

Issuer and IssuerPolicy
Specifies the URIs for the issuer and the issuer policy.

TokenType
Specifies the token type. Defaults to SAML 1.0.

PrivacyUrl and PrivacyVersion
Specifies to the URL and version of the associated privacy policy (if any).

Image

ImageUrl
Specifies a custom image to display. Defaults to the official InfoCard icon. 

StandardImageSize
Selects one of the standard images sizes for the official InfoCard icon. Defaults to 114×80.

Width & Height
Specifies the size of the image in pixels. Only relevant when a custom image is used.

Rendering

RenderOnlyIfSupported
When set to true, the control will only render if the client browser supports CardSpace. You have to embed the control into a <div /> and specify the name in the DivToRender attribute. Defaults to false.

DivToRender
Specifies which <div /> to render/make invisible based on client support.

UnsupportedDiv
Optionally specifies a <div /> to render when CardSpace is not supported on the client.

RenderMode
Choose between static and dynamic rendering. Static preserves the space for the control on the client. Defaults to Static.

Misc

HiddenFieldName
Name of the hidden field used to transmit the token back to the page. Defaults to __XMLTOKEN.

AutoPostBack
Specifies if the control posts back after a card has been selected. Defaults to false.

TriggerOnLoad
Specifies if the identity selector should be invoked directly after the page has finished loading. Defaults to false.

XmlToken
Holds the encrypted token after the user has selected a card.

Dominick also did a set of four videos on CardSpace for UK MSDN that I would recommend:

Implementation Strategies

Also find the sample code he used here

Information Card user education resources

Keith Brown points out that we need some permanent web resources that would teach people about Information Cards, how they work, how to use them, and so on:

As I add support for information cards to Pluralsight, I'm rather surprised that I'm having trouble finding official landing pages for consumers. For example, on our logon page, there will be a button to click to log in using an information card, kind of like what you see on Kim's login page. For people who don't know what an information card is, this might be confusing, so of course we'll want a link that points to some documentation. But right now it seems as though everyone is creating their own descriptions for this. Here's Kim's what is an information card page, for example.

It seems as though it would help adoption if there were some centralized descriptions of this stuff. Do these pages exist and I'm just missing them? Or is it that Microsoft only wants to talk about CardSpace, which is their implementation of the selector? I note that when Kim wants to tell you how to install an identity selector, he points to a WordPress blog called the Pamela Project, which doesn't seem too helpful, but might be interesting for someone wanting to add support for information cards to their WordPress blog.

It seems to me that if the industry really wants consumers to start adopting information cards, somebody's going to have to explain this stuff in terms my mother can understand, and it would help to have a common place where those explanations live.

In another post, discussing the issue with Richard Turner, he adds:

In my opinion, somebody (Microsoft?) needs to break this holding pattern fast. I agree that things aren't going to take off until there are more relying parties. But as a guy who is busy doing just that (adding support for infocard to pluralsight.com), it doesn't make me feel very comfortable that those consumer landing pages I talked about in my post don't already exist on the web. I happen to be very committed to this technology, so I'm going to implement a relying party no matter what. Other websites might not be so inclined.

I agree this would help – and simplify our lives.  When I InfoCard-enabled my site, I had to cobble stuff up from scratch.  It was tedious since none of the materials existed.   Maybe that's why my help screens are a bit, as Keith is too polite to tell you, crude.

It sure would be neat to have a PERMANENT location everyone's Information Card help links can point to.  That would provide consistency, and let us get some really good resources together, including videos. 

I'll bounce this idea around with others here at Microsoft and see how we can play, as Keith says, a leadership role in making this happen.

Neil Macehiter on the identity metasystem

Here is some recent commentary from Neil Macehiter at macehiterward-dutton Blog on IT Business Alignment:

It's perhaps unsurprising, given all the brouhaha surrounding Microsoft's claims that open source software infringes on 235 of its patents (which incidentally I take to be largely ‘sabre rattling’ from Redmond in the face of the implications of the GPLv3 for its deal with Novell, as discussed in the Risk Factors of the latter's recent 10-K filing), that some recent news regarding the Redmond company's very positive collaboration with the open source community has not received the attention it deserves.

The news in question concerns a series of announcements the company made at last week's Interop conference in Las Vegas. These announcements, as the title of the post suggest, all revolve around Microsoft's vision for an Internet-scale, interoperable identity metasystem and range from additions to the Open Specification Promise (OSP) through to support for OpenLDAP with Microsoft's Identity Lifecycle Manager.

So, what did they announce? First, Microsoft is

making the Identity Selector Interoperability Profile available under the OSP to enhance interoperability in the identity metasystem for client computers using any platform. An individual open source software developer or a commercial software developer can build its identity selector software and pay no licensing fees to Microsoft, nor will it need to worry about future patent concerns related to the covered specifications for that technology

In other words, third parties are free to build the equivalent of Microsoft's CardSpace, following the likes of the Higgins project, Ian Brown's Apple Safari Plug-In and Chuck Mortimore's Firefox Identity Selector. This is important not only because it extends the reach of CardSpace-like capabilities beyond Windows but also because it facilitates the consistent user experience (I know because I have used CardSpace, the Safari Plug-In and the Firefox Identity Selector) which helps to reduce errors and misunderstanding by users.

Second, Microsoft

is starting four open source projects that will help Web developers support information cards, the primary mechanism for representing user identities in the identity metasystem. These projects will implement software for specifying the Web site’s security policy and accepting information cards in Java for Sun Java System Web Servers or Apache Tomcat or IBM’s WebSphere Application Server, Ruby on Rails, and PHP for the Apache Web server. An additional project will implement a C Library that may be used generically for any Web site or service. These implementations will complement the existing ability to support information cards on the Microsoft® Windows® platform using the Microsoft Visual Studio® development environment.

Or, to put it another way, doing for back end servers what the first announcement is doing for the front-end: enabling web sites and enterprises running a wide variety of web server infrastructure to support authentication using CardSpace and the other identity selectors.

The cyncical amongst you might be forgiven for thinking that these two announcements are just Microsoft paying lip service to interoperability. This post should help to allay your concerns: at the Internet Identity Workshop earlier in May the Open Source Identity Selector (OSIS) group demonstrated interoperability amongst 5 identity selectors, 11 relying parties (the party relying on authentication to prove an identity), 7 identity providers (the party asserting the identity), 4 types of identity token (the mechanism for conveying the identity assertion), and 2 authentication mechanisms. Also, on the same day as the Microsoft press release, Internet2 announced plans to extend Shibboleth, a federated web single sign-on solution based on SAML that is widely used amongst educational institutions, to support CardSpace and compatible identity selectors.

The third piece of news from Redmond last week, concerned the new Identity Lifecycle Manager product and is thus primarily focussed behind the firewall. Microsoft is going to be working with KERNEL Networks and Oxford Computer Group to enable bi-directional synchronisation of identity data between OpenLDAP, an open source implementation of the ubiquitous directory standard, and Microsoft's Active Directory. Identity Lifecycle Manager already supports a wide range of the commonly-deployed identity data repositories so I think this move is primarily in the “playing well with open source” category – but valuable nonetheless.

These announcements are further evidence that the likes of Kim Cameron, Microsoft's chief identity architect, and Mike Jones, the company's Director of Identity Partnerships, have been working hard to foster the relationships and commitment (both from Microsoft and third parties) required to help make the identity metasystem a reality. That reality is too important for the results of those efforts to be diluted by political shenanigans around patents and GPLv3.

I'm glad to hear that Neil has tried CardSpace and its sister implementations on different platforms. 

Unifying the experience of online identity

Jon Udel zeros in on the problem of web sites that introduce “novel” authentication schemes once these schemes start to proliferate.   I had the same concerns when I set out the seventh law of identity (consistent experience).  Jon says:

Several months ago my bank implemented an anti-phishing scheme called Site ID, and now my mortgage company has gone to a similar scheme called PassMark. Both required an enrollment procedure in which I had to choose private questions and give answers (e.g., mother’s maiden name) and then choose (and label) an image. The question-and-answer protocol mainly beefs up name/password security, and secondarily deters phishing — because I’d notice if a site I believed to be my bank or mortgage company suddenly didn’t use that protocol. The primary anti-phishing feature is the named image. The idea is that now I’ll be suspicious if one of these sites doesn’t show me the image and label that I chose.

When you’re talking about a single site, this idea arguably make sense. But it starts to break down when applied across sites. In my case, there’s dissonance created by different variants of the protocol: PassMark versus Site ID. Then there’s the fact that these aren’t my images, they’re generic clip art with no personal significance to me. Another variant of this approach, the Yahoo! Sign-In Seal, does allow me to choose a personally meaningful image — but only to verify Yahoo! sites.

These fragmentary approaches can’t provide the grounded and consistent experience that we so desperately need. One subtle aspect of that consistency, highlighted in Richard Turner’s CardSpace screencast, is the visual gestalt that’s created by the set of cards you hold. In the CardSpace identity selector, the images you see always appear together and form a pattern. Presumably the same will be true in the Higgins-based identity selector, though I haven’t seen that yet.

I can’t say for sure, because none of us is yet having this experience with our banks and mortgage companies, but the use of that pattern across interactions with many sites should provide that grounded and consistent experience. Note that the images forming that pattern can be personalized, as Kevin Hammond discusses in this item (via Kim Cameron) about adding a handmade image to a self-issued card. Can you do something similar with a managed card issued by an identity provider? I imagine it’s possible, but I’m not sure, maybe somebody on the CardSpace team can answer that.

In any event, the general problem isn’t just that PassMark or Site ID or Sign-In Seal are different schemes. Even if one of those were suddenly to become the standard used everywhere, the subjective feeling would still be that each site manages a piece of your identity but that nothing brings it all together under your control. We must have, and I’m increasingly hopeful that we will have, diverse and interoperable identity selectors, identity providers, relying parties, and trust protocols. But every participant in the identity metasystem must also have a set of core properties that are invariant. One of the key invariant properties is that it must bring your experience of online identity together and place it under your control.

The “novel authentication” approach used by PassMark and others doesn't scale any better than the “pocket full of dongles” solutions proposed by Dongle queens or – for that matter – than conventional usernames and passwords. 

So far Information Cards are the only technology that both prevents phishing and avoids the novel authentication and multiple dongle problems.

By the way – if what Jon calls the “dissonance” problem that arises from the use of different images and questions on web sites were to be overcome by reusing the same images and questions everywhere, things would only get worse!

Once sites begin to share the same “novel authentication” model, you no longer have novel authentication. 

In fact you return full circle to the deepest phishing problems.  Why? 

If you went to an evil site and set up your reusable images and questions, you would have taught the evil site how to impersonate you at legitimage sites.   Thus in spite of lots of effort, and lots of illusions, you would end up further behind than when you started.