Category: Windows Cardspace

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.

AOL and “63 Million OpenIDs”

First Microsoft's announcement with JanRain, SXIP and Verisign at RSA.  Now news that AOL has launched an experimental system and announced it will support the next version of OpenID. 

The world streams by at breakneck speed.  We're getting some real momentum on this convergence thing.  I hear the identity big bang coming towards us.  Here's a fascinating post by panzerjohn at dev.aol.com. 

Yesterday, I blogged about AOL's work-in-progress on OpenID. It generated a lot of positive commentary. I realized after reading the reactions that I buried the lead: There are now 63 million AOL/AIM OpenIDs. Anyone can get one by signing up for a free AIM account. This is cool.

To address Paul's concern in Please delete my aol OpenID: We definitely want the user to be in control of their online presence. At the moment, the OpenID URL at openid.aol.com redirects you off to an AIM Profile. That's not necessarily the long term experience, though I think it should be one of the default options. George Fletcher has pointed out that it would be even better if we could redirect people off to whatever page they wanted, as long as they could verify that they owned the page. My take is, if you don't actually use the OpenID URL, it doesn't really exist. The same way a Wiki page doesn't exist until you edit it. On the other hand, having people go in and kick the tires to uncover issues is exactly why we're talking about this. So let us know what you think.

Another important point is that you can point at the AOL OpenID service from any web page you own in order to turn its URL into an OpenID. The minimal requirements are basically that you have some AOL or AIM account, and that you add a couple of links to your document's HEAD:

link href=”https://api.screenname.aol.com/auth/openidServer” mce_href=”https://api.screenname.aol.com/auth/openidServer” rel=”openid.server” 

link href=”http://openid.aol.com/screenname” mce_href=”http://openid.aol.com/screenname” rel=”openid.delegate”

We added this to our blogs product in a few minutes minutes and it's in beta now. You can also support YADIS discovery which gives additional capabilities. See Sam Ruby's OpenID for non SuperUsers for a good summary.

The detailed status from yesterday's post:

  • Every AOL/AIM user now has at least one OpenID URI, http://openid.aol.com/screenname.
  • This experimental OpenID 1.1 Provider service is available now and we are conducting compatibility tests.
  • We're working with OpenID relying parties to resolve compatibility issues.
  • Our blogging platform has enabled basic OpenID 1.1 in beta, so every beta blog URI is also a basic OpenID identifier.  (No Yadis yet.)
  • We don't yet accept OpenID identities within our products as a relying party, but we're actively working on it.  That roll-out is likely to be gradual.
  • We are tracking the OpenID 2.0 standardization effort and plan to support it after it becomes final.

(I should clarify that I really work in the social networking / community / profile / blogging groups at AOL rather than the identity group per se. You can look to see what I actually do on a day to day basis over at my personal blog.)

This is amazing stuff.

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.

 

New Information Card Profile V1.0 Technical Reference

These new documents are too low-level to be of interest to people working on the practical issues of deploying Information Cards on their Web sites.  

But they may be of interest to students, researchers and the intrepid souls who really want to get their hands dirty and understand the nitty-gritty of the underlying technical elements.

The latest and most accurate version of “A Technical Reference for the Information Card Profile V1.0” is available for download here.  In addition, I've posted a new version of “A Guide To Interoperating with the Information Card Profile V1.0” since it had a few grammatical errors and an inaccuracy in one of the examples – the URI of the self-issued IP claims was incorrect.

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…

Wouldn't it be more correct?

I'd like to share this interesting comment by Francis Shanahan, who works on identity from the vantage point of Citi:

“Your blog talks about “Cardspace enabling Apache”. Regarding the language in the post, I know I'm being picky here but…

“Wouldn't it be more correct to say “XML Tokens as an additional authentication…” rather than “…Information Cards as an additional authentication mechanism…” since I can use Kerberos or SAML tokens with Cardspace over WS-Fed.

“Wouldn't it be more correct to say “token enable” rather than “Cardspace enable”? I don't need to use the Cardspace selector with a WS-Trust enabled site.

“Wouldn't it be more correct to say “The whole identity token processing can…” rather than “The whole cardspace processing can…” and so on.  CardSpace is just the ID selector used to faciliate the token exchange.

“Just don't want to confuse folks thinking there's a Cardspace specific token.”

First I'll say that technically speaking I think you make good points, and I'll try to be as careful as I can to bring out these ideas.

Then, since pointing the finger at someone else is so fashionable, I'll say I was quoting what another company said it was doing.  (That, in itself, is interesting.)

But most important, I'll argue that the simplification of our current ideas into “iconic” notions is inevitable, and worthwhile, even though subtleties will be lost.  So we have to achieve a balance between the irreconcilables of breadth and accuracy.

I'll start with an analogy – the analogy to file and folder icons.  Computer scientists know files are potentially complex mappings of streams of bits onto blocks of storage.  They know folders are doubly linked lists of pointers to these streams of bits.  But if they're smart, they keep all of this to themselves – even when they're with other computer scientists and the door is closed.  If we told people about the inner workings of file systems, we'd drive them crazy.  In fact, they still wouldn't know how to manage documents or pictures or music.

Instead, people have gotten used to little pictures of files, and drag them from one “folder” to another – or even “onto” their mp3 players.  Our official help files say things like “Double click on the document to open it”.  We conveniently overlook the fact that the document exists as magnetic fields on the hard disk and you can't double click them.

There is a dualism between the science of the thing and the way we conceive of it in usage, just as there is in all aspects of reality.

When we invent new technologies, we start from the science, and it's really hard to explain what one is doing.  It takes months or even years to develop an “elevator pitch” – the ten second description of what you've done that makes it seem worth doing.  But that doesn't actually matter much, assuming you get funding.  What matters is the way the idea eventually enters mainstream consciousness.

It is inevitable that marketers will talk about products (CardSpace, Higgins, etc) rather than technology.

While people will “get” that something is being transferred when you authenticate or authorize, I suspect they'll always see the visual image as being the identity itself, with few understanding it as “a means to manage the metadata enabling connectivity between identity providers and relying parties”. 

I think protocols like WS-Federation and WS-Trust will be more or less invisible except to backbone engineers.

Once we get an Information Card icon out there and people start to use it, I think people will take it as meaning “Information Cards accepted here” – and that, in their minds, will be synonymous with CardSpace or whatever Information Card selector they run on their devices.  They'll realize that some sites want some cards and other sites want others, but will never think about token types.

So my reading is that Ping, which developed the Apache product being referred to, is already thinking about how to present a message that begins to deal with taking Information Cards to a wider audience.  Not out of the technology ghetto yet, but to a wider audience within the very busy technology community.  It would be interesting to hear what Andre Durand has to say about this.

 

Can browser-based plugins solve OP phishing?

Dready blog writes about OpenID phishing and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed.

“The OpenID phishing issue is a hard one to solve, particularly because it aims to:

  1. be user-friendly, i.e. it should pass the mother-in-law test; and
  2. work on the web platform without special software or browser plugin

“So, why is this suddenly a problem?

“Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.”

Actually, the problem is worse than the one we currently face.  We are not just dealing with “the perennial problem”.  If you use one OpenID account to go to two hundred sites, the thief who steals your OpenID credentials gains access to any of the 200 sites.  That's new. 

“This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there is research1 to prove that people get tricked very easily.”

Dready's right about the research.  But rather than calling it a “social problem” I'd call it a “social engineering attack”.  Further, there is a protocol problem.  The protocol is based on telling the RP where the OP is located – such that an evil site can automate a “man in the middle attack”.  Some other protocols, including the one used by CardSpace, do NOT have this problem.  That's why combining CardSpace and OpenID is useful. 

“Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

‘Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.    

…

'This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.’

“The picture is not so sunny, however, because most users:

  • won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
  • won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

“And even if they installed those anti-phishing toolbars and what not, they still fall for it!

“While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.”  (Code follows here…)

This may help Dready and in that sense it may be a welcome finger in the dike.  But as OpenID becomes successful and is used for sites of value, this kind of solution clearly won't stand up to attack or scale to embrace the population.

People really need to think about what it will mean to actually have “single signon”, rather than just talk about it. 

You cannot overestimate the value of your single signon credentials, or the extent to which they will attract attack.

I don't think browser-based solutions will do anything for us long term – the whole point of browsers is to make it easy to introduce cool new behaviors and empower the RP to give the user great experience.  They are vulnerable because they put the RP in control – by design. 

This doesn't mean plugins can't play a role in getting us to our destination.  But ultimately, you need defense in depth, many layers of defense.  If we think of the browser as a “broadband communications channel” inundating the user with information, we also need a “narrowband communications channel” honed to protection of the user.  The CardSpace work represents an attempt to create this.

 

Tailrank blog links

Tailrank did a nice summary of some of the blogging around our announcement. It's a cools site, where the results look something like this:

 

CardSpace & OpenID: Working together

kveton.com  

Found 4 days ago
The OpenID community has been having quite a few discussions about phishing and what we can do to help mitigate that problem. We have come up with a whole list of solutions that work together nicely to help address the problem. …
 

Microsoft and OpenID – commentary

identity20.com  

Found 4 days ago
Here are other posts on Microsoft and OpenID announcement: Kim Cameron (Microsoft) post Michael Grave (VeriSign) post “this is a significant step toward the convergence needed in the identity space” David Recordon (VeriSign) post “Convergence isn't new for OpenID, rather continues to show how …
 

Microsoft to Support OpenID Log on System

thomashawk.com  

Found 4 days ago
Time, Walk, Step, Turn Hosted on Zooom r [I am CEO of Zooomr] WIRED Blogs: 27B Stroke 6 : In a keynote speech at the RSA security conference earlier today Bill Gates reportedly announced that Microsoft was going to support OpenID. …
 

Microsoft Working on OpenID Support

25hoursaday.com  

Found 4 days ago
It looks like we just announced that we'll be supporting OpenID at the RSA conference. Official details are in the press release Microsoft Outlines Vision to Enable Secure and Easy Anywhere Access for People and Organizations which states To further enable the vision of secure and easy anywhere access, …
 

Microsoft marries CardSpace and OpenID 2.0

blogs.zdnet.com  

Found 4 days ago

With the Vista launch behind him, Bill Gates and Craig Mundie, Microsoft's chief research and strategy officer and security patron, were on stage the 16th annual RSA Conference in San Francisco before a crowd of about 15,000 security geeks and professionals. …

 

OpenID creates a foundation as Microsoft pledges support

factoryjoe.com  

Found 4 days ago

You can read it around the web, but, hot on the heels of the creation of the OpenID Foundation , the news from the RSA Security conference is that Bill Gates has announced Microsoft's intention to support OpenID 2. …

 

Alec Saunders .LOG

saunderslog.com  

Found 3 days ago

Sometimes wishes to come true. It was only a few days ago that I posted a rant about Yahoo's decision to impose Yahoo ID's on Flickr account holders . And I was just one of the many voices in the blogosphere raised against Yahoo's decision. …

 

Dogs and cats sleeping together!!!

hyperthink.net  

Found 3 days ago

There's lots of buzz in the blogosphere today about the big Cardspace/OpenId collaboration that was announced this morning at RSA. Whodathunk that a technology rooted in the RESTful open source ecosystem could intermingle with a technology built by the WS-* wonks without trigging some bizarre matter/antimatter explosion. …

 

OpenID and CardSpace Dance Takes the Next Step

equalsdrummond.name  

Found 4 days ago

User-centric identity infrastructure just took another key step forward today: Janrain, Sxip, Verisign, and Microsoft announced they will all be working together to help OpenID users get the benefits of CardSpace and vice versa. …

 

Post a comment

brad.livejournal.com  

Found 4 days ago

http://kveton.com/blog/?p=221

 

Microsoft Shows OpenID Love

blog.wachob.com  

Found 4 days ago

For those of us who've been helping to promote OpenID, today's announcement that Microsoft will work to get OpenID and Cardspace working well together is absolutely no surprise. Kim Cameron, Mike Jones and the rest of the crew have been saying both very rosy things, as well as giving some well-appreciated constructive criticism. …

 

Microsoft support OpenId (officially) honest!

vecosys.com  

Found 3 days ago

Unbelievably sleepy old Microsoft (we spend $4bn on R&D but has anyone seen a return) beats dithering Yahoo (should we support it or should we buy OpenID) and arrogant Google (we hate OpenID and Microformats, we only use complicated stuff we invent) to officially announce support for the OpenID movement today at the RSA conference. …

 

The “Eveel Empire” Strikes Back (But Not in the Way One Might Expect

oreillynet.com  

Found 3 days ago

Just when you thought it was safe to make assumptions regarding whether or not MSFT understood the ” Don't Fight The Internet ” rule of doing business on the 2. …

 

Microsoft to support OpenID

phildawes.net  

Found 3 days ago

Microsoft, Verisign, Sxip and JanRain have announced that they will all support the OpenID protocol in their upcoming products. Kim Cameron has the scoop (but then he would have, being the ‘Chief Architect of Identity’ at Microsoft). …

 

Libraries in the NHS

nelh.blogspot.com  

Found 3 days ago

CardSpace OpenID collaboration :

 

David Recordon's Blog

daveman692.livejournal.com  

Found 4 days ago

http://netmesh.info/jernst/Digital_Iden

 

Two-Factor Web Authentication with a Bookmark.

benlog.com  

Found 4 days ago

(There's always a dilemma between “publishing soon” and “polishing for peer review.” This is my first attempt at blog-based collaborative peer-review. Let's see how it goes!) The Problem Phishing is a serious issue, and it's only getting worse. …

 

OpenID Gets a Boost From Microsoft

lagesse.org  

Found 3 days ago

This is great news for the OpenID community – having companies like Verisign and Microsoft onboard certainly help the chances of achieving a way to manage your persona on the web! OpenID ( Radar post ) got a big boost today when it gained support from Microsoft . …

 

MSFT RSA announcement.

kaliyasblogs.net  

Found 4 days ago

This morning at RSA Bill Gates and Craig Mundie announced MSFT support of OpenID2.0 . ( Johannes has a good summary of the points they made too ) I wouldn't go so far to say that they got Married. But what exactly was announced? …

 

Microsoft to Support OpenID System

internet.seekingalpha.com  

Found 3 days ago

Thomas Hawk submits: In a keynote speech at the RSA security conference yesterday, Bill Gates reportedly announced that Microsoft was going to support OpenID. OpenID is an open, decentralized identity system that attempts to provide a solution to the multiple log on ID systems to access various sites across the internet. …

 

A new direction for ClaimID

chimprawk.blogspot.com  

Found 3 days ago

I'm proud to announce that, as of this morning, we are going to be taking ClaimID in a slightly new direction. We're going to be concentrating our efforts on being an OpenID provider, one that is extremely simple and easy to use. …

 

Microsoft supports OpenID

blog.broadbandmechanics.com  

Found 3 days ago

So I haven't had any time to talk to Kim or Dick – but here's my take on this deal between Microsoft and their CardSpace/InfoCards standards efforts and the OpenID community (Sxip, JanRain and Verisign. …

 

Post-SuperBowl blogging

blog.broadbandmechanics.com  

Found 3 days ago

Microsoft and the OpenID community have decided to support each other. In depth coverage here. Congrats to all! THis is important news! Getting Microsoft to recognize and then support an open effort like OpenID is a first step. …

Apache Authentication Module for CardSpace

Yesterday I referred to a mind-altering announcement from Ping Identity Corporation.  I think it's a key piece of the identity puzzle.  Since it's obvious that this is a big accomplishment and that he's played a major role in it, I'll quote Ashish Jain's Identity TIcker blog: 

Thanks to the efforts of our labs team, we finally have the ‘Apache Authentication Module for CardSpace‘ available for download .

Here is the product description from the SourceID website:

“The Apache Authentication Module for CardSpace is an open source module that allows applications using an Apache server for hosting or proxy to use Information Cards as an additional authentication mechanism. It allows the Apache applications to act as CardSpace relying parties (RP) by means of simple configuration. The module is responsible for decrypting the tokens submitted by CardSpace, retrieving the claims and making them available for the applications’ use.”

The idea behind this is simple. If you have an application that is deployed on an Apache server and you want to CardSpace-enable it, drop in the module (along with the dependencies), change the httpd.conf and your application should have access to the claims in the infocard.

The post includes proof that these guys were coding twenty-four hours a day.

To my mind this is really huge.  I wonder if one day we'll see it become a part of Apache, just like the password and digest authentication modules.

The whole cardspace processing can be a black box for the administrators

The module puts the attributes in the session. So if you have a PHP application, you can do the following to retrieve the attributes

$email = $_ENV[‘auth_infocard_env_emailaddress’]
$ppid = $_ENV[‘auth_infocard_env_privatepersonalidentifier’]

The same thing works in any other programming language, since they all give you access to your environment variables.

So this is pretty much as simple as it gets.  I hope everyone with a product that runs on Apache will look at this.

But wait!  There's more!  When I wrote to Ashish to congratulate him on this development, he added:

We also have a .jar file for java that serves the similar purpose (we internally refer it as the cardspace-magic.jar and we will open source some day). Same idea…drop the .jar file in,  then:

xmltoken in -> attribute’s map out

So if you use Java, you can go that way too.

But wait! There's still more!!

Yes, folks, Ping Identity is actually showing a demo at RSA of some of the very ideas we've been discussing over the last couple of days.  Namely, use of CardSpace to log in to OpenID sites.  I'll do another post to sow you some screen shots.