DigitalMe for Mac passed the Interoperathon

Bandit's contribution to the emerging identity metasystem is exceptional – we're talking about the DigitalMe Identity Selector for Mac and Linux , as well as relying party components.  I will post a download link as soon as one becomes available.  Novell's Dale Olds wrote about the Catalyst Conference and OSIS Interopathon here :  Continue reading DigitalMe for Mac passed the Interoperathon

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.

Ensuring Privacy and Consent

I think many will benefit from Marco Casassa Mont's Research on Identity Management blog.  He discusses business-driven identity management – and its foibles.

A recent post invites us to an upcoming Kable conference that I would attend if I possibly could:

An interesting conference is going to take place on July, 9th in London, UK on “Ensuring Privacy and Consent in Identity Management Infrastructures”. It is supported by DTI and free to attend to the private sector and academics. The conference program and online registration form are available here.

“The Department of Trade and Industry (DTI), through the Technology Strategy Board's Network Security Innovation Platform, is working with the Identity and Passport Service (IPS), the Home Office, the Economic and Social Research Council (ESRC) and the Engineering and Physical Sciences Research Council (EPSRC) to develop a work package that will sponsor a £10m, 3-year, research and development programme into how to balance the potentially intrusive nature of identity services and network security with users’ expectations of privacy and consent. This research will be cross-disciplinary, combining social science with technological innovation. …

The aim of this initial workshop on 9 July is to discuss and refine the areas of importance for research, as well as identifying where the research is needed and where the UK has potential to develop world-leading commercial services. The findings of the workshop will lead to the development of projects and proposals using the EPSRC's sand-pit concept at a further workshop to be held in early October.”

You might want to consider attending if you work in the areas of identity and privacy management …

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.

PHP managed card provider

Here's a new managed card provider from Patrick Patterson at  Carillon Information Security Inc.  With commendable understatement, Patrick writes:


I just thought that you'd like to know about a demonstration STS for issuing managed infocards that we've just finished.It's written in PHP, backends into either a database or LDAP, and is easily customizable to accommodate custom claims.

And, since it is written in PHP, it is easily deployable for those that want to experiment with a CardSpace STS, but who may not have either a JSP server to deploy one of the other Java based implementations, or an IIS .NET server to experiment with the one Microsoft has provided.

It is available here.

I'm a sucker for PHP and Ruby on Rails, so I love seeing this support.  Beyond that, I'm interested in Carillon's support for certificates. 

What is it?

The Carillon STS is a PHP-based Federated Identity Provider (IdP) which is capable of acting as a Secure Token Service (STS) compatible with Windows CardSpace and other “infocard” implementations. It has been successfully tested with CardSpace, as well as with Chuck Mortimore's Firefox identity selector plugin.

Once installed and configured, the Carillon STS allows a user to authenticate himself, either by password or by X.509 certificate, whereupon he is issued a digitally signed infocard containing some standard identity claims and optionally some customizable identity claims. When he presents this infocard to a Relying Party's (RP's) site, his browser's identity selector requests a SAML token from the Carillon STS. If the authentication information is still valid, a digitally signed token will be issued with the various claims asserted. The browser takes this token, checks the digital signature, encrypts it for the RP, and passes it along. It is the RP's responsibility to decrypt the SAML token, check the digital signature, check the asserted claims, and make an access decision based on this information.

Current Status:

This project has been tested with available releases of Windows CardSpace and the Firefox identity selector plugin. There are several Relying Party (RP) sites on the web to test against; in particular, the xmldap.org RP is able to consume Carillon STS infocards and display their contents.

Version 0.01 is the initial release of the Carillon STS. It is presently under active development.

License:

The Carillon Demo STS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Carillon Demo STS is Copyright © 2007 Carillon Information Security Inc.

Download:

Note: Please hold down the SHIFT key while clicking on package you want to download to avoid file corruption.

Source: carillon-sts-0.01.tar.gz

I hope to meet Carillon at the next Interopathon.  It's really awe-inspiring to see this level of Information Card expertise developing spontaneously in the security and identity communities.  Congratulations, folks!

CardSpace and Smart Cards

Over the next few days I will write about some of the Information Card ideas and products I saw at the Burton Group's Catalyst Conference.  The Interopathon demonstrated a whole slew of identity provider, identity selector and relying party products written by all kinds of competitors and collaborators.  Pretty much all the big software companies were involved, as were a some smart identity industry startups.  The next day, the party continued in the Microsoft hospitality suite – and probably other suites as well.

One of my favorite demonstrations was put together by Gemalto, one of the world's largest manufacturers of smart cards, cell phone SIMS and dongles.  They collaborated closely with the CardSpace team on a prototype of CardSpace in which Information Cards and the associated metadata and secret keys are all kept on a smartcard or dongle.

Here's the user experience:

You arrive at a machine, and insert your smart card. 

CardSpace asks for a password, and when you enter it, you see your CardSpace cards as usual – except they marterialize from the smart card.  The system supports both self-issued and managed cards. 

Then, when you remove your smart card, all the CardSpace cards go away.

In other words, the system completely solves the roaming and “kiosk” problem.  You take your Information Cards with you, and use them wherever you go.  A single smart card can transport a whole set of unrelated cards – the “Fist full of dongles” problem is solved.

The Gemalto folks have a demo that makes the ideas completely clear here.   Much of the work was done by Kapil – great guy  and I have my fingers crossed that he'll start blogging again.

Identityblog Privacy Policy

This notice is the entire privacy notice for the site at http://www.identityblog.com which is solely owned and operated by Kim Cameron.

Personal information usage and storage 

  • In order to leave comments on the blog, I will ask you to log in and provide personal information (possibly via the intermediary of your social network provider if you reuse an existing social identity): a first name, last name, a ‘display name’ and an email address.
  • I don’t require that your first name, last name, or display name correspond to your natural identity. However you must be able to prove you can access to your working email address.
  • Each time you authenticate, I also employ a personal identifier – a random number used only at identityblog.com and created by your identity provider or our identity management system that I associate with you.
  • This information is stored in a WordPress mySQL database and protected by our identity management system.
  • The display name is retrieved from our database to identify your comments.
  • The email address is used as an anchor in case you are unable to authenticate to your identity provider: by proving ownership of the address you can register with another identity provider.

No combining or revealing of information

  • The information I collect will not be combined with information obtained from other services and companies.
  • The information will not be revealed to other companies or organizations under any circumstances unless I am legally required to do so.

No persistant cookies or tracking of your reading 

  • If you do not authenticate by using our identity management system, no cookie is generated and no tracking is done.
  • When you authenticate using our identity management system (and possibly a social networking provider), I create a session cookie to give you a better experience when leaving comments.  The time and IP address of your authentication may be stored in an audit database so we can aggregate the data and graph Identityblog usage.  No other tracking is done.
  • The cookie is not reused between sessions.
  • Under no circumstances do I track which postings you have read or searches you have done.

SPAM

  • You will never be sent an email except a) to prove possession of your email address during registration or b) to reconnect you with identityblog in case of technical or operational issues… I assure you that you will never be sent a ‘reconnection’ message more than once in any three year period.

Updating your personal information

  • To change your personal information, please use the ‘Update Profile’ link after you log in. The system will be updated automatically.

This is a personal blog and my goal here is to convey why and how I am using (and will use) any information I ask you to provide. If you have other questions I should answer or comments on my policy, please let me know.

Including the whole spectrum of use cases

Mathew Martin, who writes Mostly Mr. SQL, clearly detests PKI certificates more than almost any living person.  He finds CardSpace guilty by association in a piece called GRRRR!  CardSpace.  What a useless steeming pile…

Ok. Cardspace/Infocard is like OpenId.  Password-less access to websites (or password-fewer access).

BUT

1. You must use SSL.  Even if you just want to secure your application against your clueless neighbor.  That is a minimum of $40.

2. You must decrypt the response on an account with NTFS access to the private key.  The NT Network Service account is not likely to have read access to the private key on a hosted account.  Good luck explain how and getting co-operation from your hosting provider.

3. Decryption must be done under FULL TRUST.  Many hosted accounts only let you run in medium trust and don’t let you create COM+ dlls, put stuff in the GAC, etc.

[Items 2 and 3 might not even be a good idea.  If the world at large manages to use your web application to maliciously download your SSL cert, I suppose they could do something evil, like pretend they are you]

4. To get rid of the “the website isn’t secure for banking or ecommerce” you have to spend $1000 on an EV SLL cert.  Oh, sure, pocket change.

5. And who is issuing managed cards? I can get an SSL based cert from Thawte that says I am the person that controls my email account, but I can’t find anyone who issues managed infocards anywhere.

I’ve about realize that I–a computer profession and programmer, will not be able to implement InfoCard/Cardspace in any form, not for my blog, not for my hobby website, nothing.  Either one has $1040 and ones own entire server or nothing.

If only the top 10 biggest websites can overcome the hurdles posed by infocard, what we are going to see is 5 websites accept infocard and everyone else (mom & pop websites) continue to use passwords and user ID’s. InfoCard will have a minimal impact on how authentication is done.

This is going to drive small websites into using OpenId.  Consumer will rapidly gain a few dozen OpenId cards.  The rising ubiquity of OpenId–which doesn’t try to be a waterproof authentication method–will take over the world, relegating InfoCard to “that way you logon to Live.com services”.

Come on Microsoft, when are we going to be able to run CardSpace/Info card in “real world” mode?

[Thanks to Self-issued.info for the logo]  [Actually, I take that back, it is a Microsoft trademark. The purple box is has a substantial amount of IP self legislation that goes with it.  According to MS’s lawyers, I am currently in violation of usage guide lines for the icon.  Let’s see how Microsoft silences critics of InfoCard.]

Let's start with the CardSpace requirement that a relying party support SSL.  I agree with Mathew that requiring use of SSL and PKI is overkill for the type of blogging and hobbyist use cases he describes.  While my identityblog certificate is fairly inexpensive (thanks to godaddy.com), the extra cost associated with it at textdrive (which hosts my system) is around $100.00 per year because of the need to have a dedicated outward facing IP address.  I don't mind the cost too much, since I know there are people who will hit on my site and I like the extra protection.  But this really isn't appropriate for everyone. 

This underlines the fact that identity and the identity metasystem involve a continuum of use cases and technologies – and we have to embrace the whole continuum.  By making certificates mandatory, we cut the continuum in half.  Luckily, we can fix that before we get into the wide deployment phase.

My conclusion is that rather than hard-wiring the requirements for identification of a relying party into the identity selector, we should have allowed each identity provider to decide what minimal requirements were appropriate. 

This ends up having advantages both at the low value and high value ends of the spectrum. 

For example, a bank's IP might decide to only release information to a relying party with an Extended Validation (EV) certificate.  If so, CardSpace would not illuminate the associated information card if an EV certificate were not in use at the relying party site.   [EV certificates are only granted to companies or other organizations after they follow an extensive procedure for proving their legitimacy.]

Meanwhile, a blogging reputation identity provider might be happy to release reputation to any site the user proposes, certificate or no certificate.

Of course, the relying party is always free to use a certificate and gain the extra protection that provides.

This change is actually part of CardSpace 1.1 – which people should be able to start experimenting with very soon now.  When combined with the release of great toolkits for all the important languages, I think this will bring quite a bit of lift-off.

As for point 4), let's look at what the CardSpace advisory actually says:

I think there's a big difference between “a major internet business” and a site doing “ecommerce”.  When I buy a tee-shirt from Mathew I don't expect him to be EV.  If he were trying to sell thousand dollar cameras, I would feel differently.  I'd want him to either be well identified, or to work through a site like eBay that would provide another way of establishing his reputation.  And in this case, I want to make sure I'm really talking to eBay, so once again would like to see an EV cert.

I don't think any “major internet business” or bank will have any difficulty whatsoever covering the cost of an EV cert.  The idea of using the superior certs came directly from them, since they're the ones whose users get phished.  I don't understand why, given his earlier rant against the poor validation proceedures in conventional certificates, Mathew rails against our support for EV.  Part of his earlier criticism of EV certs is that the browser doesn't show the meaning of the cert properly, a problem CardSpace has solved. Consider this recent Anti-Phishing Working Group report:

As for who is issuing managed cards, you'll be seeing many outfits doing it as we move toward the InfoCard tipping point.  We're in the sockets and ecosystem phase of Information Cards, but I can tell you many players get the potential of the technology and are integrating it into product.

As for OpenID versus Information Cards, I don't see them as opposites.  Go to signon.com today and you'll see it supports use of Information Cards for OpenID authentication.   This is nice because it gets you InfoCard safety along with OpenID long-tail support. Going forward, I think you'll see most OpenID vendors supporting OpenID managed cards that work with OpenID sites.

As for the Information Card Icon, our intention is that it be available to everyone who supports the technology.  There has been pushback on the language around the icon, and we'll be figuring out how we can get this thing right.  In the meantime, I wouldn't be worried about using it on a teeshirt or to criticise us – but I would be worried about using it at a phishing site. 

Charles Fitzgerald doing “platformonics”

I just discovered that Charles Fitzgerald, General Manager of Platform Strategy at MS, has started a blog called Platformonics.  I know a lot of industry people will be interested – Charles has really been around the block at the highest level.  I think he learned more from “Hailstorm” than anyone else who I've spoken to.  Beyond that, he's a great business person, well-read and beautifully wry.  Here's a piece full of implications called There is no free lunch (especially in France):

The BBC reports the French security service has told French government officials not to use Blackberries because their data is stored in foreign countries and could be susceptible to prying eyes. Expect many more such awakenings going forward to the tradeoffs to putting data in the cloud.  Not just national security concerns, but trade secrets, privacy and compliance requirements will all require people to think more explicitly about the risks and tradeoffs of where you put your data and what can happen to it.  Today's all or nothing approach is a crummy way to do it. Three contenders for the most amazing part of this story:

  1. They're just realizing this now?  Did they just figure it out or did some incident precipitate this decision?  There is probably a pretty good spy novel in if you combine this with almost any headlines from France in recent years.
  2. French officials are “flouting the ban”.  I predict the upcoming ban on smoking in public places in France takes “flouting” to a whole new level.
  3. RIM insists the US National Security Agency can't read content on their service.  Disciples of Taleb might call that epistemological arrogance.

Oh yeah, I almost forgot.  Charles has been a great supporter of the Laws of Identity – ribbing me by somehow learning to recite the title with reverb.  He was also one of the first to see the potential of Information Cards.