openinfocard for Firefox >= 3.0.2

Andrew Hodgkinson found a workaround for the latest Firefox hickups. Mozilla removed the non-standard two-parameter eval( statement, scope ) function which was used by the Firefox add-ons that implement identity selection through Information Cards. SUN's java problems that the openinfocard id selector experiences continue to bug us. With Firefox 3 the openinfocard selector is really usable only for managed cards because the java part of the selector is mainly used to issue self-issued tokens. Managed cards are handled by javascript code.
You can download the latest version of the openinfocard selector from the project's repository.
I still recommend to use Firefox 2 until SUN and Mozilla fix the java problems.

xmldap STS update

While the service at https://xmldap.org/sts/ currently has an outdated certificate (Sorry!) the code did improve nevertheless.
When you compile and install the code on your server then you can now create managed cards that have the RequireStrongRecipientIdentity and RequireAppliesTo elements set.

I will update the applications on xmldap.org after we have the valid cert again.
The openinfocard id selector was updated too to read and interpret the new element in managed cards.
Enjoy.

Instant Managed Cards

One of the problems around managed cards is that if they are protected through username and password then the benefit to the user seems not as big as one might expect. The promise to get rid of passwords is not completely fulfilled because now instead of giving a username and passport to a RP I have to give one to the IdP. The user now is disappointed and the product management responsible for the introduction of information cards at the RP is unhappy because the user is disappointed.
Well, the promise was not to get rid of ALL passwords. The promise was to get rid of most passwords. The user has to authenticate to the IdP to get the security token.

CardSpace has alternatives to the username/password authentication at the IdP.

• self issued cards
• X509 certificates
• kerberos

Kerberos is said to be not adaquate for Internet use and should be restricted to Intranet use. Hm.
So that leaves us with self-issued cards and X509 certificates.
Self-issued cards that back a managed cards have their own difficulties. Try to explain to a user that he has to generate a self-issued card, then introduce that card to the IdP before the IdP can issue a managed card backed by this self-issued card. This is just to complicated and if you delete your self-issued card then your managed card is toast. Or if you backup your cards and import the managed card somewhere else but fail to import the self-issued card then that managed card is useless too.
X509 certificates are similar complicated. Where do I get one that is accepted at the IdP? (I am talking about the Internet use-case here, not the corporate use-case)
Well, the mobile operator might deploy one over-the-air and the IdP might accept that. This is a scenario that I like very much, but we have to wait whether mobile operators will do this or not.

Anyway, how do we solve the problem? I suggest that we simply put the username/password into the managed card's private data section. This might be optionally PIN protected or the whole cardstore might be protected by "something I know/have/are".
The user experience should be that the card is imported and that the authentication to the IdP is preformed by the identity selector (preferably without user interaction) when the card is used.

First I thought that we should put the self-issued card or the X509 certificate into the managed card's private data and that that should be used to authenticate to the IdP. The needed keypair should be generated on the fly by the identity selector when the managed card is retrieved from the IdP (We could use a RST to push the public part of the keypair to the IdP and retrieve the managed as a security token in the RSTR).
But now I think that putting the username/password into the managed card's private data and use it without user interaction is a valid option if the user consents to it. This is like the "remember this password?" option in Firefox.
Yes, these credentials need to be protected but not necessarily by something the user has to enter when the managed card is used.

To repeat: I think we need a managed card that is easy to deploy and easy to use.
The solution is to put the credentials needed for IdP authentication into the managed card's private data and to deploy these credentials to the IdP in one step.
The username/password does not have to be the same as the initial username/password needed to authenticate to the IdP. I suggest that they should be different. Like the keypair from the self-issued card that is generated on the fly.

The goal is: IdP offers managed card. The user retrieves it and can immediately use it without further dialogs and complicated procedures.
The solution: IdP offers managed card (signifying what authentication method is/are supported). The id selector generated the authentication credentials (random password, keypair in certificate/self-issued card are not really different from each other) and sends them in a RST to the IdP. The managed card is retrieved as the security token from the RSTR.

Alles wird gut.

Card Selector on Windows Mobile

I just heard a very interesting talk given by Dr. Bruno Quint from Corisecio. They implemented an id selector on windows mobile. So you are able to surf on the windows mobile device and use this selector when information cards are accepted by a RP. And they implemented a connection between your PC and the windows mobile device, so that you now can surf the Web on any PC and use your information card selector on your mobile device.
Corisecio also added smartcard support on the mobile device which makes this an extra strong solution.

To bad that Corisecio does not participate at the OSIS interops. Unlikely that Dr. Quint does not know about OSIS. I will ask him during the break.
I guess this stuff is still smoking because it is so new.

id selector advertising

I just uploaded a new version (xmldap-0.9.9.200712212304.xpi) to the openinfocard's download area. This version allows you to change the value of the http header that advertises the id selector to the relying party.

You can choose between

• no advertising
• advertise existence
• advertise id selector name

Please enlarge this picture to see the values in the preference dialog. The X-Id-Selector http header is visible in the left sidebar.



This version has now similar object handling code from digitalme as the id selector that was shortly known as CardSpace for Firefox.

Of course all of the id selector advertising stuff is preliminary and subject to change.

update: Rob Richards corrected my initial code that fills the menupopups in the preferences dialog so that only installed id selector extensions are added the popup's item list.

xmldap paymentCard_sts certificate

Kim Cameron noted that the certificate of the xmldap paymentCard_sts was expired. This is/was my fault. I used the wrong key alias and selected the expired certificate instead of the current one.
I changed the application's configuration today. Now I am able to create a card and import it into CardSpace, which formerly complained about the expired certificate and refused to import the managed card.


Please note that the paymentCards are importable into CardSpace but not usable with CardSpace, because the claims can not match.
The card has the claim "http://schemas.xmlsoap.org/PaymentCard/trandata?", while the relying party requires the claim e.g. "http://schemas.xmlsoap.org/PaymentCard/trandata?price=2700EUR". These claims do not match and thus CardSpace marks the paymentCard as not applicable.

Here is the same card, that I previously imported into CardSpace, used in the openinfocard id selector:


Please note that the value of the variable claim is displayed to the user.

shortening the wishlist

A new version of the openinfocard id selector (0.9.9.20071206) is in the download area of the project.
The oldest card that was once sent to a relying party is now ensured to be visible by scrolling it into view.

Here a picture after using the infocard login at signon.com:

xmldap.org RP XHTML 1.0 strict

The xmldap.org relyingparty is XHTML compliant. This is important because triggering the id selector is hard enough with "legal" HTML.

And: Always nice to see the site and/or cards issued by the xmldap STS in other posts:

• OpenSSO secure token service
• Barcelona calling cards

New Versions for Firefox 2.0.0.9

Please find the new version of the openinfocard id selector for Firefox 2.0.0.9 in the project's download area.
It is best used with the new version of the identity selector selector which can be downloaded from this project's download area.

I tested both with most of the relying parties in the table "I2 Relying Party results with Identity Selectors". First the id selector selector with CardSpace 1.0, then with the latest openinfocard id selector.
I did not test RPs that bugged me with certificate issues.
The ping identity advanced RP is Firefox unfriendly as ever, but it worked.
I did not test the no-SSL Microsoft RP with CardSpace 1.x because I don't have that installed. I tested the no-SSL xmldap relyingparty with the openinfocard id selector which works fine!



You might want to know what changed...
Well, to bad I did not take notes. I noticed that Firefox 2.0.0.9 works with IdentitySelector-1.0.1.xpi! From there I - very carefully and slowly - redid all the changes and feature integration again. In the end it worked. This is not really satisfying from a software engineering and quality assurance point of view... but who cares?!
<update> The major change with the id selector selector is that is now leaves the type of the object untouched. Formaly the type was set to "" to remove the dreaded browserNotification "Addidional plugins are required ...". I think changing the type of the object is dangerous and yields unpredictable results.</update>.
The major change with the openinfocard id selector is that it now detects the id selector selector and leaves the 'object type="application/x-informationcard"' handling to it. The id selector selector was better in handling the objects since it exists.

Next steps regarding object handling:

• I would like have the DigitalMe id selector integrated into the id selector selector. And I would like the openinfocard id selector to handle the objects alone if the id selector selector is not installed, but currently I don't know how to achieve both goals simultaneously.
• Test RPs with multiple objects outside of forms.

Thanks to Andrew Hodgkinson and especially to Boris Zbarsky (Mozilla guru) who asked the right questions.

Supporting Information Cards with Browsers as of the Information Card Profile V1.0

While investigating the issues described in my former post I began to wonder why this all has ever worked... You had this feeling in your computer science life too now and then, right?

My personal history regarding this is: Chuck designed the code of the openinfocard id selector in a way that it worked with early relying parties according to the examples given in THE GUIDE. Our relying party at xmldap.org is designed excactly along the examples from the guide. When I joined the team I did not have to bother with the particular code that did the HTML-object handling. I changed this code several times but I was only adding code needed for e.g. correct/better PPID computation and lately no-SSL support. The major workings of the code were not changed because it handled the examples given in the guide ok. Later new relying parties appeared with javascript triggering and I used Kevin Miller's extension because it handled most of these cases correctly.

After having spent some hours to find the reason why the id selectors stopped to work in some cases I began to think that the behavior of IE7 might not be standard HTML (what ever that is). I think that the examples given in the guide expect the browser to retrieve the value of the object when it is inside a form and pass this value to the RP in the post data. Is this HTML standard behavior expected from browsers?

The Microsoft relying parties listed in OSIS - Relying Party results with Identity Selectors currently use another approach.

function InformationCard1OnClick(doNotSubmit) {
  try {
    var token = icardInformationCard1.value;
    if (!token) {
      throw 'ID5006: No token is returned from InformationCard.';
    }
    document.getElementById('InformationCard1_TokenId').value = encodeURIComponent(token);
  } catch (ex) {
    document.getElementById('InformationCard1_ErrorId').innerText = encodeURIComponent(ex.number + '::' + ex.description);
  }
  if (!doNotSubmit) {
    formInformationCard1.submit();
  }
}

THIS MAKES SENSE!

• get the object value
• copy it to the form field
• and submit

Not only does it make sense it still works with Firefox 2.0.0.[8|9]!



My suggestion: Somebody should write a new version of the guide and change the code of relying parties to this scheme!

I consider some of the other schemes currently in use just tricky/wrong/complex/false.
One relying party, which can not find anymore, changes the object parameters in the submit function. What sense does this make???!!!

To sum it up: It would be nice if having the object inside the form and having the browser add the object's value to the posted data would work, but I am not sure whether this is _standard_. Requiring javascript is maybe not _friendly_, but maybe inevitable. I think that HTML object was invented to handle media types and this does not imply that a parent form should submit the object's value. Doing this explicitly might be better.
Just my 0.2 cent.