Category: Information Cards

CardSpace FAQ

As you can imagine, over the years I've answered plenty of questions about CardSpace and Information Cards.  In fact, the questions have been instrumental in shaping the theory and the implementation.  To help put together a definitive set of questions and answers, I'm going to share them on my blog.  I invite you to submit further questions and comments.  You can post directly by using an InfoCard, post on your own blog with a link back, or write to me using my i-name.

Would banks ever accept self-issued information cards?  How could they trust the information on them to be true?

In fact a number of banks have expressed interest in accepting self-issued cards (protected by pins) at their on-line banking sites. 

They see self-issued cards as a simple but improved credential when compared to a password.  Because a self-issued card is based on public key technology, the user never sees a secret that can be phished.  The self-issued card uses a 2048 bit RSA key when authenticating to a site – and there is no key-distribution problem.

These banks would not request or depend on the card's informational claims (name, address, etc).  The banks have already vetted the customer through their Know Your Customer (KYC) procedures.  So it is just the crypto that is of interest.

There are also banking sites that are more interested in issuing their own “managed cards” – for branding reasons, and as a way to provide their customers with single-signon to a constellation of services operated in unrelated data centers.

Finally, some banks are interested in using managed cards as a payment instrument within specific communities (for example, high value transactions), and as a way to get into new identity-related businesses.

How can managed cards ever help identity providers prevent phising, if all the end user has is a password? 

Once a user switches to CardSpace, phishing is not possible even when passwords are used as an IdP Credential.

That is because an Information Card reference is included as a part of the “Request Security Token” message sent to the IDP. It may include a second secret in its CardId, never released except encrypted to a certificate specified in the card's metadata. For example:

 

Even if the user is tricked into leaking her password, she doesn’t know the CardId and can’t leak it. If the IdP verifies that the correct CardId is present in the Request Security Token message (as well as the username and password), it is impossible for an attacker to phish the user.

Why can't you use smart cards, dongles, and one-time password devices with CardSpace?

You can.  Using a password is only one option for accessing IdPs.  CardSpace currently supports four authentication methods:

  1. Kerberos (as supported on *NIX systems and Active Directory):  This is typically useful when accessing an IdP from inside a firewall.
  2. X.509:  This allows conventional dongles, smart cards and soft certs to be used. Further since many devices (such as biometric sensors) integrate with windows by emulating an X.509 device, it supports these other authentication methods as well.
  3. Self-Issued Card:  In other words, the RSA keys present in one of your self-issued cards can be used to create a SAML token.
  4. Username / password:  The password can be generated by an OTP device if the IdP supports it, and this is an extremely safe option.

Drilling further into delegation

Still further to my recent piece on delegation, Eric Norman writes to give another example of a user-absent scenario.  Again, to me, it is an example of a user delegating rights to a service which should run under its own identity, presenting the delegation token given to it by the user.

For an example of user-absent scenarios, look at grid computing. In this scenario, a researcher is going to launch a long-running batch job into the computing grid. Such a job may run for days and the researcher needs to go home and feed the dog and may be absent if a particular stage in the job requires authentication. The grid folks have invented a “proxy certificate” for this case. While it’s still the case that a user is present when their “main” identity is used, the purpose of the proxy cert is to delegate authentication to an agent in their absence such that if that agent is compromised, all the researcher loses is that temporary credential.

Perhaps this doesn’t count as a “user absent scenario”. Nevertheless, I think it’s certainly relevant to discussions about delegation.

I agree this is relevant.  The proxy cert is a kind of practical hybrid that gets to some of what we are trying to do without attempting to fix the underlying infrastructure.  It's way better than what we've had before, and a step on the right road.  But I think those behind proxy certs will likely agree with me about the theoretical issues under discussion here.

As an aside, it's interesting that their scheme is based on public key, and that's what makes delegation across multiple parties “tractable” even in a less than perfect form.  I say public key without at all limiting my point to X.509.

With respect to the problem of having identities on different devices, Eric adds:

Um, I think one of the scenarios Eve might have had in mind is the use of smart cards. A lot of people think that the “proper” way smart cards should operate is that secrets (e.g. private keys) are generated an the card and will reside on that card for their entire life and cannot be copied anywhere else. I’m not commenting on whether that’s really proper or not, but there sure are a lot of folks who think it is, and there are manufactures that are creating smart cards do indeed exhibit that behavior.

If users are doing million dollar bank transfers, I think it makes sense to keep their keys in a self-destroying dongle.  In many other cases, it makes sense to let users move them around.  After all, right now they spew their passwords and usernames into any dialog box that opens in front of them, so controlled movement of keys from one device to another would be a huge step forward.

In terms of the deeper discussion about devices, I think we also have to be careful to separate between credentials and digital identities.  For example, I could have one digital identity, in the sense of a set of claims my employer or my bank makes about me, and I could prove my presence to that party using several different credentials-in-the-strict-sense:  a key on smart card when I was at work; a key on a phone while on the road; even, if the sky was falling and there was an emergency, a password and backup questions.

If we don't clearly make this distinction,, we'll end up in a “fist full of dongles” nightmare that will even make Clint Eastwood run for the hills.  When I hear people talk about CardSpace as a “credential selector” it makes my hair stand on end:  it is an identity selector, and various credentials can be used at different times to prove to the claims issuer that I am some given subject.

Speaking of smart card credentials, one of the big problems in last-generation use of smartcards was that if a trojan was running on your machine, it could use your smartcard and perform signatures without your knowledge.  Worst of all, smartcards lend themselves to cross-site scripting attacks (not possible with CardSpace).  To me this is yet another call to have the user involved in the process of activating the trusted device.

Mixed signals?

Stephen Mcgibbon, senior director of Microsoft's European technology office, is in the midst of a lively identity discussion on the Danish blog Overskudsdanmark.  In a posting called, “What CardSpace enables, Vista prevents…“, Stephen quotes Stephan Engberg – who is on the international advisory board of Privacy International and other important organizations – as saying,

“I can easily see that Cardspace in itself COULD be a step in the positive direction, but MS is sending mixed signals by pushing the aggressive Live Id and “trusted” computing simultaneously with Cardspace.

“That might be ok if someone else had access to make usable solutions, but it is not my understanding that VISTA and Cardspace provide that access. What Cardspace enables, VISTA prevents.”

I guess there are several issues here.  I'll defer the discussion of how CardSpace provides openness until Stephan has had a chance to look around this blog – the “HelloWorld Card” series would probably help get a technology orientation.  Or just poke through the articles, or look at comments like this recent one from Dale Olds at Novell.  While that's happening, I'll try to get more up to speed on his criticisms of Live ID and Vista.

Perhaps I can move the discussion forward by sharing some high level information about the current Windows Live ID service.

It's quite a bit different, conceptually, than Passport was – even though it is a technical evolution of that system.  At core, Live ID sees itself as part of a very distributed and multi-centered world, whereas Passport was centralized and technologically monolithic.

You can get a sense for this by looking at the most recent Windows Live ID Whitepaper.  Let me pass on a few quotes which I hope will entice you to read more of the paper:

How Does Windows Live ID Participate in the Identity Metasystem and Work with “InfoCard”?

Microsoft is working with others in the industry to create an identity metasystem that brings existing and future identity providers into a connected identity ecosystem and empowers end users to control the use of their identities. The Windows Live ID service will participate in the identity metasystem as one identity provider among many, able to accept claims from other identity providers and transform them so they can be used within Microsoft online services. This participation will include acceptance of self-issued and managed “InfoCards.” It will thus provide full support for the “InfoCard” identity model.

Roles of the Windows Live ID Service in the Identity Metasystem

Microsoft has published its vision of a universal identity solution that is inclusive of a plurality of identity operators and technologies—the identity metasystem. In such a metasystem, identity providers, relying parties, and subjects can select, request, transfer, transform, and consume identities through a suite of well-defined and open Web Services (WS-*) protocols. Microsoft is working to implement components of the identity metasystem, as are many other companies in the industry. As a result, various building blocks for the metasystem are being developed. Some of these components will be delivered to end users in the form of software installed and running locally on their computers and devices, while others will be online services.

The design philosophy of the identity metasystem is not to replace the existing identity systems in use today, but instead to bring these existing systems together by enabling interoperation among subjects, relying parties, and identity providers through industry standard protocols. The Windows Live ID service will participate in the identity metasystem as a “managed” identity provider already at Internet scale. Windows Live ID will bring a large base of end users and relying parties to the metasystem, taking us one step closer to Internet-wide identity federation and doing our part to help the industry move beyond the “walled garden” paradigm.

The Windows Live ID service will play several essential roles that are strategic for Microsoft. The service:

  • Is an Internet-scale identity provider intended primarily for users of Microsoft online services, which are all relying parties of the Windows Live ID service.
  • Is open and issues claims in a form that can be consumed by any relying party, any device, and any other trusted identity authority.
  • Serves Microsoft online services as a “claims transformer,” allowing those services to accept identities issued by third-parties. Third-party identity providers include other Internet service providers and managed-identity providers, such as the planned Active Directory Security Token Service (STS).
  • Will be the identity provider and federating authority for third party services and software built on top of the Microsoft online services platform

In short, I see Windows Live ID as the identity component for the MSN properties, which speaks standard protocols, and is trying to be open and do business with the other parties who want to engage.  This is all a new model – not only for Microsoft, but for the industry as a whole.  There are many business details to be worked out, as there are elsewhere in the industry.  But I see a progressively deeper committment to putting privacy first, and think my Live ID colleagues deserve a lot of credit for that.  In fact, we have invited Stephan's Privacy International colleague Simon Davies to review and criticize our structures and initiatives, and have tried to act on his recommendations just as we would act on the recommendations of world-renouned security experts or other leading thinkers.

So I'm interested in the disconnect Stephan and I have in our perceptions.  Is it because Microsoft hasn't communicated broadly enough? Or is there something substantive here?  I would really like to understand. 

In terms of Stephan's comments about Vista being controlling in some way, I just don't understand at all.  It's the opposite of what we were trying to do.

Not everything about Vista is perfect, but we have been very hard core about putting our customers totally in control.  User-centriic is a big deal for me, and for everyone I know.  So are open interfaces and protocols.  I don't understand his objection to our “trusted computing” effort. 

So Stephan, let me know what you're thinking, and let's try to figure this out.

 

Bandit and Higgins hit interop milestone

I was so snowed under trying to work against time for the OpenID annoucement at RSA that I missed blogging another imporant milestone that has been reached by the identity community.  This report on progress in the Higgins and Bandit side of the house is great news for everyone:

The Bandit and Eclipse Higgins Projects today announced the achievement of a key milestone in the development of open source identity services. Based on working code from the two projects and the larger community of open source developers, the teams have created a reference application that showcases open source identity services that are interoperable with Microsoft’s Windows* CardSpace* identity management system and enable Liberty Alliance-based identity federation via Novell® Access Manager. This reference application is a first-of-its-kind open source identity system that features interoperability with leading platforms and protocols. This ground-breaking work will be demonstrated at the upcoming RSA Conference in San Francisco.

“There are two basic requirements for translating the potential of recent identity infrastructure developments into real-world benefits for users: interoperability and a consistent means of developing identity-aware applications,” said Jamie Lewis, CEO and research chair of Burton Group. “First, vendors must deliver on their promise to enable interoperability between different identity systems serving different needs. Second, developers need a consistent means of creating applications that leverage identity while masking many of the underlying differences in those systems from the programmer. The Bandit and Eclipse Higgins interoperability demonstration shows progress on the path toward these goals. And the fact that they are open source software projects increases the potential that the identity infrastructure will emerge as a common, open system for the Internet.”

The Bandit and Higgins projects are developing open source identity services to help individuals and organizations by providing a consistent approach to managing digital identity information regardless of the underlying technology. This reference application leverages the information card metaphor that allows an individual to use different digital identity ‘I-Cards’ to gain access to online sites and services. This is the metaphor used in the Window’s CardSpace identity management system that ships with the Vista* operating system.

“Windows CardSpace is an implementation of Microsoft’s vision of an identity metasystem, which we have promoted as a model for identity interoperability,” said Kim Cameron, architect for identity and access at Microsoft. “It’s rewarding to see the Bandit and Higgins projects, as well as the larger open source community, embracing this concept and delivering on the promise of identity interoperability.”

The open source technology developed by Bandit and Higgins enables initial integration between a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. Specifically, these technologies enable Novell Access Manager to authenticate a user via a Microsoft infocard (CardSpace) and consume identity information from an external identity system. It will further show that identity information from Novell Access Manager can be used within an infocard system. This is a significant step forward in the integration of separate identity systems to deliver a seamless experience for the user as demonstrated by the reference application.

“The Liberty Alliance project fully supports the development of open source identity services that advance the deployment of Liberty-enabled federation and Web Services as part of the broader Internet identity layer,” said Brett McDowell, executive director of the Liberty Alliance. “The open source community’s embrace of Liberty Alliance protocols is validation of the benefits this technology provides, and we salute the Bandit and Higgins teams for their role in making the technology more broadly accessible.”

Higgins is an open source software project that is developing an extensible, platform-independent, identity protocol-independent software framework to support existing and new applications that give users more convenience, privacy and control over their identity information. The reference application leverages several parts of Higgins including an identity abstraction layer called the Identity Attribute Service (IdAS). To support a dynamic environment where sources of identity information may change, it is necessary to provide a common means to access identity and attribute information from across multiple identity repositories. The IdAS virtualizes identity sources and provides a unified view of identity information. Different identity stores or identity management systems can connect to the IdAS via “context providers” and thus provide interoperability among multiple systems.

“Many groups have been working towards the goals of Internet identity interoperability,” said Paul Trevithick, technology lead for the Higgins project. “This milestone represents a major step in having multiple open source projects work together to support multi-protocol interoperability.”

The Bandit project, sponsored by Novell, is focused on delivering a consistent approach to enterprise identity management challenges, including secure access and compliance reporting. The Bandit team’s contributions to the reference application include the development of multiple “context providers” that plug into the Higgins Identity Attribute Service (IdAS) abstraction layer to provide access to identity information across disparate identity stores. It also showcases the role engine and audit reporting capabilities in development by the Bandit community.

“The development of this reference application would not have been possible without the collaboration and contribution of the wider Internet identity community,” said Dale Olds, Bandit project lead and distinguished engineer for Novell. “This is the first of many milestones we are working towards as both the Bandit and Higgins communities strive to enable interoperable, open source identity services.”

So congratulations to Bandit, Higgins and everyone else who made this happen – this is great stuff, and the identity big bang is one step closer for it.

Understanding Bandit

There's so much going on around identity these days, that it's easy to lose track of how the different pieces fit together.  Here's a posting by Novell's Dale Olds that tells us all about Bandit.

There has been a huge flurry of activity in the Internet identity space in recent months mostly around convergence, working code, and actual deployments.

Since I am an unashamed Bandit, I am sometimes asked “where does the Bandit project fit in all this?” I think that it fits in three ways:

First, Bandit supports the above mentioned projects and convergence points.

We participate in the community as much as we can, and we are one of the few projects I have seen that will actively contribute code to other projects. We NEED this stuff to work coherently and we work to accelerate convergence where possible.

In some ways the Bandit project is much like our close ally, the Higgins Project. Both projects write open source code that glues together existing and future systems. Neither project pushes a particular protocol family or identity system. Higgins provides a framework that supports a common interface to multiple identity systems and protocol families. Bandit needs such a framework, so we contribute to Higgins to help it get done faster. We work with Higgins on other shared components as well.

We are also excited to work with the new Pamela Project. It fills a very important need for consistent relying party code that is usable, robust, and handles evolutionary accounts from existing silos to the emerging identity systems. Relying parties need consistent user experience too.

Most projects that we work with are open source. I personally would want my identity information handled by open source software. I also think that open source development is particularly good at interoperable components of distributed systems — like identity systems.

.
Second, Bandit adds a layer of open source components for consistent authentication, authorization and audit capabilities.

You might say that accelerating convergence, contributing code to other projects, and some authentication code is necessary before we can build effective authorization and audit components. We need a cohesive, distributed identity system. But we also know that when we get such a system, some critical issues involving authentication, authorization, and audit will surface.

Bandit focuses on simple, reusable components for authentication, authorization, and audit. These capabilities are most recognized as needed in enterprise identity systems, but I think they will be needed in other places as well. The recent experiences of the Bandit team and others are confirming this. Once applications or services (web based or otherwise) start to actually be used by more than a few users and sources of identity, they immediately find they need a general, scalable solution for authorization and audit.

Authorization means determining whether a particular user can perform an operation. Most network services really support authorization based on something like a role. For example, a wiki may have a notion of an administrator, an editor, and a reader. The Bandit Role Engine will allow a sysadmin great power and flexibility in how to map security tokens, claims, and other information into the native roles of the system.

Auditing is needed to provide an record of who did what. In the case of most of the emerging Internet identity systems we are particularly interested in providing a record for the user of what a service has agreed to do for them. Think of it (in the insight of Bob Blakley) as the receipt from a Relying Party. Audit records are also needed (like a cash register receipt log) to help a service prove compliance with various accounting regulations.

Bandit is not limited to these components or use cases, but they illustrate the point. From the main project page:

Bandit is a set of loosely-coupled components that provide consistent identity services for Authentication, Authorization, and Auditing.

Third, the Bandit Project is a conduit between developers and those who make these systems work in real deployments.

The Bandit Project works with Novell product teams, other vendors, current and future customers to determine what still needs to be done to make these identity systems work in real deployments. This will be an increasing emphasis of the Bandit Project this year.

 

Mozilla Links interview with Kevin Miller

Here is the Mozilla Links interview with Kevin Miller on his CardSpace selector, which will be included as an extension for Firefox 3. 

CardSpace, is Microsoft’s identity management system, a way of reducing the hassle of having as many identities (username/password credentials) as services we use and is already listed as a requirement for Firefox 3

Kevin Miller who has released Identity Selector, a Firefox extension that adds CardSpace support, tells us what his extension does and what identity management in general is about and what can users expect from this and other alternatives currently in development. For the record, Kevin notes he doesn’t work for Microsoft.

Mozilla Links: What exactly CardSpace is and how it works?
CardSpace is the method of implementing what Kim Cameron calls an Identity Metasystem. I would describe an Identity Metasystem as a protocol definition, or a pattern for secure identification on the internet trying to solve three problems:

  1. Phishing attacks
  2. Lack of trusted identity
  3. Proliferation of personal information

I don’t think we need to discuss phishing attacks. By now everyone should be familiar with them.

The second point, lack of trusted identity, is a bit more difficult. Web sites seeking to authenticate users have very few good options. They may require credit card numbers, which are verifiable. However, most users are reluctant to give their credit card numbers to just any site on the net. They may require a digital certificate, but these are difficult for the average user to maintain and verify.

For consistency with the documentation, I will refer to web sites as Relying Parties (RPs). I will refer to the users as users, although the Microsoft documentation calls them subjects. Please keep in mind that the users could be individuals, companies, or other computer systems. The RP need not be a web site. It could be a Windows client, a web service, or nearly anything.

The third point, proliferation of personal information, is a side-effect of the second point
first two items, and also contributes to identity theft. Because the RPs require users to register, they typically ask for a large amount of personal information, whether they need it or not. They may be selling this information, or they may be using it for marketing purposes. Or, they may just be collecting it because everyone else is and they think they might need it in the future. The problem for the users comes either from the sale of this information, or in the compromise of the servers (or laptops) on which this information is stored.

Now, the Identity Metasystem goes the distance on resolving all these issues.

  • Users now have easy-to-manage cards (InfoCards), instead of difficult to manage certificates.
  • The RP can ask for information relevant to the security level of the site.
  • For simple web sites, they may allow a self-generated card. This might be typical for many news sites where the company only asks users to register. Instead of typing the information into a form on the website, the user can self-generate a card and use it at multiple sites.
  • If the RP requires real authentication, they may accept cards from a number of valid Security Token Servers. These are third parties that host cards for users. The third parties must be trusted by both the user and the RP. This is similar to the concept of escrow. The user and the RP do not need to trust each other as long as they trust the third party.
  • The RP publishes the claims required for access.
  • The user decides what information to deliver. If the RP is asking for too much, the user can decline.
  • The user doesn’t have to fill out endless web forms.
  • The RP can customize the InfoCard request.
  • The user can customize the InfoCard response.
  • The RP can choose any available server implementation.
  • The user and site can agree on any Security Token Server.
  • The user can choose any Identity Selector.

All of these components can be provided or consumed in any language, browser,
or operating system, as long as they support the necessary components of the
Identity Metasystem.

This system directly answers points two and three, above, and indirectly reduces phishing attacks. It is also hoped that the trend will be for users to hand out less information, and the RP to ask for less. For example, consider two companies sharing information.

  • Company A has an information library that Company B wants access to.
  • Company B is willing to pay for the information, but doesn’t want to have to administer a list of user accounts. They also don’t really want to tell Company A the names of the employees accessing the data.
  • If Company A and Company B can agree on a common Security Token Server, Company B can simply provide valid InfoCards that indicate the user is an employee of Company B. The user can have access to Company A’s library without divulging any other information.

This is a bit of a contrived example. A real-world example may be a bar. The bar must make sure that you are of legal age to get in. The mechanism that most use now are driver’s licenses. In addition to your age, the license contains medical conditions, name, address, and description. Add to this the fact that some bars are now photographing licenses and storing the data. This means that now you are at risk of identity theft just to enjoy a night on the town. In an InfoCard world, you could simply provide an InfoCard validated by the government STS, and the bar would know that you are of legal age. No further information given or at risk.

Mozilla Links: How does CardSpace compares to OpenID, an open source identity management proposal?

There is only the most superficial comparison with OpenID. They both use third party sites to validate users. CardSpace, however, is all about authorizing and authenticating the user. OpenID provides only a unique ID (based on a URI). It does allow the third party to provide a variety of information, but does not provide the user an easy way to preview the information prior to each transaction. OpenID also relies on the honour of the implementers. There are no checks and balances to recover from a rogue provider.

CardSpace is designed to give both sides of a transaction (one or both of which may behave poorly given a chance) a way to verify the information requested and provided. Now, CardSpace won’t force an eBay seller to put your iPod in the mail, but at least you could get validation that you are dealing with a specific user.

Mozilla Links: What does your extension, Identity Selector, do?

My extension really does only a couple of things.

  • It parses the parameters representing the required and optional claims, and other key parameters.
  • It invokes CardSpace (or an alternative, such as Chuck Mortimer’s Identity Selector)
  • It passes the parameters from the web page back to CardSpace.

There’s a fair amount of validation, and some interfaces to allow developers to provide alternative implementations, but those three functions are the key pieces of the extension.

Mozilla Links: Why does Firefox need an extension to support CardSpace?

An extension is required in order to get the appropriate information from the browser and invoke CardSpace. Without the extension, Firefox has no mechanism to invoke CardSpace. We could theoretically generate some SAML code based on a web interface and hand that back to the relying party, but it would provide little benefit, at a large cost of effort.

CardSpace is hardened against attacks, provides a simple mechanism for choosing cards, and allows the user to verify the relying party. CardSpace also provides all the “plumbing” for handling and reading certificates, basic encryption, and writing SAML.

Mozilla Links: How much support does CardSpace have currently?

I’m not sure how many pages support this at the moment. The three I’m familiar with are the xmldap.org site, Kim Cameron’s sample page, and the official CardSpace sandbox (which, unfortunately, only supports IE 7. I’ve talked to some folks about sorting that out).

Essentially, xmldap.org allows you to create a managed card (or select a previously used one from the site), and then use that card to log in. If you’ve logged in correctly, you get a page that displays the SAML code sent, and displays the claims in the InfoCard. It doesn’t look very flashy, but trust me, the code underlying all this is very cool, and exciting to us security types.

Thanks to Kevin. If you want to learn more visit CardSpace web site.

CardSpace is still pretty bleeding edge, but the software is starting to get out there.  Having Firefox support is great for users, since the identity selection experience is consistent across IE or Firefox or “desktop” applications.  With respect to OpenID, clearly my view is that OpenID and CardSpace have a lot of synergy, and the identity community is working hard to maximize this.

Ignite Deux Seattle

Jackson Shaw knows as much about identity management as anyone.  I very much value his thinking.  If that weren't enough, there is that irresistable love of life that sweeps everyone into his energy field.  I think it comes through in his new blog:

No, it's not another French post from Jackson. Tonight I did something a bit different. I headed over to the Capital Hill Art Center in downtown Seattle to watch . There were 21 speakers scheduled including Scott Kveton the CEO of the folks behind . As you probably know, my buddy Kim Cameron is the man behind the curtain for Microsoft's CardSpace initiative ( I guess I should stop calling it an initiative – it is actually part of Vista now) and at the RSA conference Microsoft announced that CardSpace would be interoperable with OpenID.

I thought since Scott was going to present I might as well go over and see what all the hub-bub was about. The format of the evening was interesting in itself. Presenters had 5 minutes – only – to present their 20 slides! That's 15 seconds a slide. Scott was third presenter in the first volley of speakers. The first talk was from Matthew Maclaurin of Microsoft Research on Programming for Fun/Children/Hobbyists/Hackers. The second was from Elisabeth Freeman (Author in the Head First Series, Works at Disney Internet Group) on The Science Behind the Head First Books: or how to write a technical book that doesn’t put your readers to sleep. Then Scott was to speak.

First, I was shocked to walk into this “art space” that was packed to the rafters with people. Was I in the wrong place? Apparently not. On the website they stated the space would hold 400 people and it was jam packed. I had this vision of a few people sitting around some tables chatting. Not so! It was pretty cool; folksy; kinda out there but very engaging. Second, what was I going to get out of a 5 minute talk? Well, the speakers kind of had the pressure on them to make their points. The ones that I saw all got to the point quickly and they all engaged the with the audience, did their thing and got off.

Check out my photos on Picasa if you want to see the shots I took which included many from Scott's talk. So, what did I learn from Scott's talk?

  • OpenID is single sign-on for the web
  • Simple, light-weight, easy-to-use, open development process
  • Decentralized
  • Lots of companies are already using it or have pledged support
  • 12-15M users have OpenIDs; 1000+ OpenID enabled sites
  • 10-15 new OpenID sites added each day
  • 7% growth every week in sites

Scott predicts that in 2007 there will be 100M users, 7,500 sites, big players adopt OpenID and that OpenID services emerge. Bold predictions but something that is viral, like OpenID has a shot at it.

I have to say I was impressed. Scott finished up with a call to action that included learning more about OpenID at openidenabled.com. I'm definitely heading over there to learn more.

I'll report back.

p.s. Here's an interesting read:

Jackson just “gets” the potential for contagion into the enterprise – assuming we can use OpenID in the proper roles and with the right protections.  Corroborates for me the possible “charging locomotive effect”.   People shouldn't be caught looking the wrong way.

As for the numbers Scott threw out, I think they are very achievable.

HelloWorld Information Cards Part III

To understand this discussion, start here and then follow the continuation links until you return to this posting. Click on the images below to see a larger and more readable version.

In the demo, as shown in the following screen shot, only the HelloWorld card is illuminated – all the other cards were “greyed out” as inappropriate:

This happened because in the Information Card login page,  the “relying party” expressed a requirement that a HelloWorld card be presented.  This was done by embedding “policy” in the “object tag” that tells the browser (and through it, CardSpace) what Information Cards will be accepted.  To drill into this, let's look again at the login page:

Here's the HTML that created it:

You'll see that one of the PARAMs in the OBJECT tag is “tokenType”.  It's set to a completely arbitrary value – one I made up to show you can do whatever you want – of http://kcameron11/identity/helloworldToken,  Since I specified this specific token type, only Information Cards that support it will illuminate at selection time when you go to this web page.  Further, the other PARAM specifies “requiredClaims”.  Only Information Cards that support these values will be possible candidates.

The InfoCard Web App and Browser Guide has more information about the OBJECT tag.

In the next installment, I'll explain how the Identity Provider works, and you'll be able to examine the code.

 

HelloWorld Information Cards Part II

To understand this discussion, start here and then follow the continuation links. Click on any of the images below to see a larger and more readable version.

When you pressed the “Install” button on the “try it” page, you would have seen the normal “Open or Save” dialog:

If you then clicked “Open”, CardSpace would have brought you the standard “Reputation and Privacy” dialog, showing the certified details of the HelloWorld identity provider, and asking if you want to install its card:

Armed with your new card, you would have begun the “usage” demo by going to the HelloWorld information card login page:

Clicking on the InfoCard image to log in, CardSpace would have shown the “Relying Party Reputation and Privacy” page for Identityblog.  (If you normally use InfoCards at Identityblog, you won't see it.  In order to avoid “clickthrough syndrome”, it only shows up when you start a new relationship with a relying party.)

Once you approve starting the identity relationship, you are taken to your CardSpace card selector, and your HelloWorld card will be illuminated, since in this demo, the relying party has asked for that kind of card:

When you click on the card, you can preview what will be sent to the relying party should you opt to proceed. To get any information out of the HelloWorld identity provider, you need to authenticate to it. The first version of CardSpace supports four ways to do this (more in a later piece). This demo uses the simplest mechanism – entering a password within the protected CardSpace environment:

Now you'll have a chance to review the contents which will be sent from the identity provider to the relying party:

The contents include “favorite snack” – an attempt to show the elasticity of the contents. If you decide to proceed, the HelloWorld token is transfered to the relying party, which displays it verbatim:

For those who are multi-tasking as they read this, I'll show the token full size to make sure the format and contents are as clear as possible.

In the next episode I'll start looking at what goes on under the hood. Continue here…

OpenID? Huh?

In a posting called “OpenID? Huh?“, Francis Shanahan, whose job it is to worry about high value financial transactions and strong assertions about molecular identity, wonders why OpenID is nothing more than a reinvention of the WS wheel.  

“I don't understand OpenID [LINK].  I'm sorry.  I've tried to understand it but I just don't get it.

“The spec is confusing but thankfully Phil Windley has translated it into a diagram for us mere mortals [LINK].

“The idea of OpenID is to provide “an open, decentralized, free framework for user-centric digital identity.” 

“And here's how the flow works (at least one of the scenarios).  Note I've taken Phil's explanation and augmented it with my own understanding:

  1. User is presented with OpenID login form by the Consumer
  2. User responds with the URL that represents their OpenID (for example “FrancisShanahan.myIDServer.com”). Now the Consumer needs to determine if I actually “own” the URL I've specified.
  3. Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.
  4. Identity Server returns the HTML document named by the OpenID URL
  5. Consumer inspects the HTML document header for tags with the attribute rel set to openid.server and, optionally, openid.delegate. The Consumer uses the values in these tags to construct a URL with mode checkid_setup for the Identity Server and redirects the User Agent.  {fs: Said differently, the consumer directs the user to login at their ID server.}   This checkid_setup URL encodes, among other things, a URL to return to in case of success and one to return to in the case of failure or cancellation of the request
  6. The OpenID Server returns a login screen.
  7. User sends (POST) a login ID and password to OpenID Server. {fs: I assume you can authenticate how ever your OpenID server likes}
  8. OpenID Server returns a trust form asking the User if they want to trust Consumer (identified by URL) with their Identity
  9. User POSTs response to OpenID Server.
  10. User is redirected to either the success URL or the failure URL returned in (5) depending on the User response
  11. Consumer returns appropriate page to User depending on the action encoded in the URL in (10)

“Ok, makes sense but there's an obvious problem as Kim Cameron correctly points out in this post [LINK].

“If you assume the Consumer is evil, they can take the openID URL from step 2 and instead of directing the user to that legitimate URL, they can substitute it with their own faker site. This site'll look EXACTLY like the one the user's expecting. The user unwittingly enters their credentials and the scenario continues as normal. The user's never aware that they were phished.

“Clearly there's a piece missing that Kim claims can be provided by the CardSpace ID selector. By integrating OpenID with CardSpace you can avoid malicious redirections and phishing in the protocol. But then what've you actually achieved? You've just re-invented the WS-* wheel all over again using redirects and a browser? So what's the point?

“I don't get it but this is dark mojo and I'm probably missing something somewhere.”

Let me clarify what really happens.  Let's go back to step (2) above.  We know Francis by his blog URL – http://www.francisshanahan.com.  So if he was going to leave comments on my blog, he would most likely use his own blog URL as his OpenID.

Note that his blog URL isn't an identity server.  So in step (3), the consumer doesn't contact an identity server – it requests and gets Francis’ actual web page (or, at least, its header).  As explained in step (5), the header contains a “link” element telling the consumer who to trust as the identity provider for this page.

Now, in steps (5) through (10), the user is redirected to the identity server, enters his credentials, and picks up a coupon that he gives back to the consumer after another redirect.  Behind the scenes, the consumer then sends the coupon back to the identity provider (using a backchannel) to see if it is valid. (There is a potential optimization that can be used here involving exchange of a key – but it is only an optimization).

So let's think about this.  Where is the root of trust?  In conventional systems like PKI or SAML or Kerberos, the root of trust is the identity provider.  I trust the identity provider to say something about the subject.  How do I know I'm hearing from the legitimate identity provider?  I have some kind of cryptographic key.  The relevant key distribution has a cost – such as that involved in obtaining or issuing public key certificates, or registering with a Key Distribution Center.

But in OpenID, the root of trust is the OpenID URL itself.  What you see is what you get.  In the example above, I trust Francis’ web page since it represents his thinking and is under his control.  His web page delegates to his OpenID identity provider (OP) through the link mechanism in (5).  Because of that, I trust his identity provider to speak on behalf of his web page.  How do I know I am looking at his web page or talking to his identity provider?  By calling them up on DNS.

I'm delving into the details here because I think this is what gives OpenID its legs.  It is as strong, and as weak, as DNS.  In other words, it is great for transactions that won't attract criminal attack, and terrible for those that will.

This now brings us face to face with the essence of the metasystem idea.  We don't live in a one-size-fits-all world.  Identity involves different – and even contradictory – use cases.  Rather than some monolithic answer, we need a metasystem in which the cost (in complexity or money) of using identity is proportional to the value of the asset being protected.  OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages.  But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.

The way I see it, there is a spectrum with DNS-based technology at one end and hardware-backed crypto technology at the other.  If we can get this continuum structured into a metasystem, the dichotomy between RESTful and Web Services approaches can be changed from a religious war to simple selection of the right tool for the right task.  That's why I want to see OpenID as an integral part of a metasystem providing a common experience while respecting the economics of identity.

This having been said, Francis is right for asking whether we've “just re-invented the WS-* wheel all over again using redirects and a browser?”.  While I think it is known I'm a strong supporter of SAML as a step forward for identity, I've been an equally vocal advocate of separating communications protocol, trust, and token payloads.  OpenID has a different token payload and trust system than SAML, but if the three axes had been properly disentangled, you could imagine OpenID as a very simple SAML profile.  Because of the entanglement, that can't be the case.

WS-Federation (possibly misnamed…) doesn't have this problem.  It can carry any token, and use any trust framework.  OpenID would work inside the WS-Federation protocol patterns, and would be able to retain its payload and trust structure.  So could SAML for that matter.  So there is the “theoretical possibility” of merging all these things.  Will it happen?  Someone would have to pass out large quantities of pain killers, but there is a possible future in which, over time, they converge.