openinfocard 0.9.8 relying party test results

xmldap.org
live id
FriendsWithCards
higgins (left button)
IBM RP	Selector does not start when icon is clicked. Though the debug output of the selector shows that the object is found.
IC-Ruby	Could not login with information card. The selector starts, I choose a card, then the error message is displayed. No reason for failure is given. Selector debug output looks ok.
IC-Java	This works. I don't feel like registering right now, so the error message is correct.
Pamela Project
Ping Identity Simple RP	tbd
Ping Identity Advanced RP	tbd
CA Siteminder RP	tbd
Bandit Trac	tbd
Oracle RP	tbd
Bandit Podcasts PW RP Word Press	tbd
IC-C	tbd
Siemens DirX RP	Firewall problems. Can not access port 9443.
WSO2-IS Java RP
MS RP for MS IdP	symmetric binding is not supported by the openinfocard id selector.
MS Any Issuer RP
MS no-SSL RP

Good-Bye XBL

I just uploaded a new version (0.9.8) of the openinfocard id selector. You can find it in the project's download area.

Finally we got rid of the XBL code. There are several problems with XBL; the most notable beeing that bindings are not applied to objects in the head section of the html code on the relying party.

Andrew Hodgkinson had the idea to replace the XBL by a progress listener. The progress listener gets every event while the html code is parsed and the page constructed. Clever!

I tweeked Andrew's code a little bit, but all credit goes to him. Thanks.

Further new but somewhat experimental features in this release:
- the cardstore can now be where ever the user chooses it to be (as long as Firefox can treat it like a nsILocalFile). Everything that looks like a file-system should work.
- the cardstore is now encrypted with the Firefox master password (if one is set)
- the cardstore can be on a webserver (GET and POST). This is not tested.

BTW: There is a new version (1.0.4) of the CardSpace4Firefox extension.

Special thanks to Rob Richards too. Rob was the first to adapt Andrew's code for the openinfocard selector and he tested it againt many relying parties. He built a selector selector Firefox extension that calls the actual id selector. The id selectors implement Kevin Miller's API.
I think this is a good idea but somewhat inconvenient for the user because this concept requires two extensions to be installed.
I choose another way and implemented the selector selector in both extensions: openinfocard and CardSpace4Firefox. This way each selector is self contained and does not depend on other extensions. Each extension is programmed to be "friendly" to the other extensions that use the same progress listener scheme.

My plan for the next days is to integrate DigitalMe into the selector selector. Then we have all three id selectors in one instance of Firefox. Nice.

Corrupted Card Collection for CardSpace

After installing .NET3.5:


So if you *really* need your cards then make a backup before installing .NET3.5.

The new - polluted - IE7 user agent string:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; 
  .NET CLR 1.1.4322; .NET CLR 2.0.50727; 
  InfoPath.1; .NET CLR 3.0.04324.17; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

I copied it from the latest xmldap.org relyingparty. It outputs the user agent string to make documenting the interop tests easier.

Please notice that this is no-SSL.

Downloading The New Version Of CardSpace

Right after I saw Mike Jones' post that a new version of CardSpace is available I started to download "it". Well, first a download for dotNetFx35setup.exe of about 3MB size started and I thought: "Hey, they really boiled this down from the over 50MB to a manageable size". But then the disappointment… The setup application does not setup .NET35 but downloads another 67MB of hopefully useful and necessary code.
Probably it is still to early in the morning and my skepticism is still sleeping... Call me naive.
Maybe I am an eternal optimist...

Anyway; I think that Microsoft should split this up so that I can get only what is needed for CardSpace and only that code that is not already on my machine. Maybe this will all be already installed in Windows8?!

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

Sea of Change

Paul Madsen found this periodic table of diagrams.
Which reminded me (somehow) of this map of Online Communities:

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.

Firefox 2.0.0.[8|9] xbl problem

There seems to be a bug/problem with the DigitalMe id selector, the openinfocard id selector and the perpetual-motion id selector selector and Firefox 2.0.0.[8|9]. Others report problems too.

If you want to use our id selector extensions please use Firefox 2.0.0.7 for now.

Curious what is going on inside the extensions? Then you should configure Firefox to show you. Please follow the instructions given here: Setting up extension development environment. Setting the preferences is easy. Just enter about:config into the address bar and go for it.
The current xbl problem is not visible here though, but sometimes a lot of warnings regarding faulty css .

One item from my relying party wishlist: Please adhere to standards XHTML, HTML, CSS! Sometimes it is hard to see the debug messages in all the warnings caused by the relying party code.

Codeplex IdentitySelector 1.0.2

I just uploaded a new version 1.0.2 of the identity selector selector Firefox extension.

You can find the XPI and the source code zip-archive on the Codeplex IdentitySelector release page. Please click the "IdentitySelector-1.0.2.xpi" link to install this extension into Firefox.

So, what's new?

• issuerPolicy is now supported
• no-SSL should now be supported. Not tested. You need .NET 3.5 (CardSpace 1.x) to test this.
• report errors to javascript console
• tokenType may be null
• requiredClaims may be null
• javascript errors in InformationCard.xml are fixed

Here are two pictures showing Microsoft's ageSTS before and after login using this new version of the Firefox extension with CardSpace 1.0 as the identity selector:




This needs more tests and sometimes shows the dreaded "Additional plugins are required to display all the media on this page" status bar.



Please try it and report issues to me.

openinfocard no-SSL

I just uploaded a new version with initial no-SSL support to the openinfocard download area.

The relyingparty at xmldap.org is not yet updated but this will happen soon.

ID Selector Beta Version Regression

How and when to trigger the id selector is --- complicated ---.
Two beta versions back I introduced primilary code to handle javacript triggering better. Well, since then the openinfocard id selector started to dislike our own xmldap.org relyingparty, which uses the plain old style recommended in "A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0". Thanks Pamela for notifying me.
After two nights of fruitless tries to fix this I decided today to go back two steps.
I made a backup of my current local code repository and retrieved a fresh copy from the public google code repository to build a "working" version again.
You can download it (xmldap-0.9.8.200710291053.xpi) here.

As I am considering myself as an eternal optimist... here a small outlook which features might make it into the next (sans-micro-)version.
- no-SSL support
- better javascript id selector triggering

information card web integration complexity

During the interop id selectors were, among many others, tested against this relying party: MS no-SSL RP.

As you can see in the results table every other than the CardSpace selectors failed. At first glance this is no wonder because the no-SSL feature was just resently introduced.
BUT there are other reasons why this failures occur. One thing that really annoys me: Somebody found it cool to put the object element of type application/x-informationcard into the head part of the html document!
Well this may be perfectly legal, but why don't "they" adhere there own "A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0"?
Keep it simple! What is the reason to do this? Please enlighten me!

We all want information cards to be a success but doing all kind of possible tricks does not help. Giving guidelines to relying parties is good, but maybe this should not be just guidelines but a "standard"?!

Interop I2

There has been some blogging about the interop event at Burton Group's Catalyst Conference EU07 already.

• Bob Blakley
• Eve Mahler
• Mike Jones
• Ashish Jain
• Gerald Beuchelt

It has been a lot of work to test all this. For me I tested the openinfocard id selector against all IdPs and all RPs. Next the result tables for the xmldap IdP and the xmldap RP waited to be filled. Some server's even needed to be tested several times because issues were found. Specials thanks from me to Microsoft's Age STS team. It took us some time to notice that they use the 'issuerPolicy' parameter which caused the trouble.
My opinion is: don't use issuerPolicy except you have good reason. And don't use symmetric binding except you have good reason. I would prefer it if we would concentrate on the "standard" use cases for now.

Another point: One thing I missed during the interop. We forgot to create tables for the handling of privacy statements. I put this feature into the openinfocard id selector just recently...


This leaves us some work for the next interop. If you think that this an id selector feature and not an interop issue, then try to view the privacy statement from xmldap's relyingparty using CardSpace.

A final word: Alles wird gut.

Card Import Issue

I just uploaded a new version of the openinfocard id selector to
http://code.google.com/p/openinfocard/downloads/list

The XML library of Firefox's javascript seems to dislike xml processing instructions.
Now I remove them before importing the card...

They did it again ;-)

The interop event at Burton Group's Catalyst Conference Europe 07 in Barcelona just started and guess who has no nice poster provided by Burton Group? All the other participants have one, but xmldap's / openinfocard's is missing again.

They did this to us in the first interop too.

Update: Somebody brought the xmldap sign later. Thanks.

Here is a picture (courtesy of Charles Andres) showing me and Steffen Konegen from the jinformationcard team. (Still without the sign)

xmldap.org update

Today I updated the relyingparty and the sts at xmldap.org.



This was long overdue and I am happy that I could improve the deployment process to make this possible. The WAR files are now self-contained. The only file accessed outside the applications is the J2EE container's keystore.
There is not much to see on the surface though, but now it is easier for me to demonstrate new features and improvements on this internet accessible site.

Please test it and send bug reports, feature request...

Codeplex IdentitySelector

I am proud to present a new version 1.0.1 of Kevin Miller's Firefox extension.

You can find the XPI and the source code zip-archive on the Codeplex IdentitySelector release page. Please click the "IdentitySelector-1.0.1.xpi" link to install this extension into Firefox.

So, what's new?

• privacyUrl and privacyVersion are now supported
• the preferences page now allows to choose between CardSpace and the openinfocard id selector
• the preferences button in the Add-ons window is disabled. Please use Tools->Options instead.
• the target platform for this extension is restricted to WINNT_x86-msvc
• the updateUrl is disabled for now
• javascript errors in InformationCard.xml are fixed

Here are two pictures showing the preferences pages of the IdentitySelector extension and the openinfocard extension. Chuck's code to choose between CardSpace and openinfocard was moved from the openinfocard extension to the IdentitySelector extension:

If you use the openinfocard Firefox extension too, then please update to the latest version.

Please try it and report issues to me. I am now a coordinator for this project too.

Internet Identity Workshop (IIW 2007b)

The registration is now open for the Internet Identity Workshop (IIW 2007b).

Dec 3-5, 2007
Computer History Museum
Mountain View, CA

openinfocard 0.9.8 release candidate

I just uploaded a new version of the openinfocard id selector to http://code.google.com/p/openinfocard/downloads/list.

It has

• color coded card background
• green - card has been sent to this site
• yellow - card token type matches, but has not been sent
• red - token type does not match
• shows the privacy statement, if available
• has checkboxes to choose optional claims
• shows a warning on first time visits to a site

.




This should resolve some points from the interop feature list...

Having this done I hope that I can implement more interessting features...

Please try it out!

;rm -rf /usr/local/blogs/

Hope this post's title does no harm...
http://xkcd.com/327/

Firefox extension dependency

Some have noticed it: The openinfocard id selector currently seems to need Kevin Miller's id selector selector extension on some operating systems.

With Rob Richards help I was able to fix this. The openinfocard id selector now does not depend on Kevin Miller's extension anymore. This is important for "alternative operating systems".
The dependency wasn't really well documented. Sorry for that.

PHP Guru Rob Richards noticed a bug related to this. The chain of certs and the chainLength of the relying party were only intialized in the perpetual-motion glue and not in the openinfocard id selector's own object handling routine.

I fixed this in the latest 0.9.8 release candidate that can be downloaded here:
http://code.google.com/p/openinfocard/downloads/list

I am not sure whether we should stick to this dependency or revert to a self contained extension. Our own object handling was a little neglected in the last months; but it should be easy to spruce it up.

----------------------------------------------------

Rob Richards has an IdP and RP demo site too (no frills). I tried the openinfocard id selector there and it worked fine. You need to get a managed card here:
https://www.ctindustries.net/icard/index.php
That is because Rob's site uses it's own tokentype: http://cdatazone.org/preferences
Then navigate to his relying party to use that card.
https://www.cdatazone.org/demostore/index.php



The following image shows the lastest id selector in action at this RP.

Cards are now shown with background colors depending on their matching at the current RP. Red background denotes a not matching card. You might also notice the new checkbox in front of the claim(s). "checked and disabled" is a required claim. "unchecked and disabled" is an unwanted claim. "unchecked and enabled" is an optional claim. "checked and enabled" is an optional claim that was sent the "last time".
All this will be features of the next 0.9.8 version. This is not fully functional yet.

CardSpace Team Blog

You will find this interessting: http://blogs.msdn.com/card/

2007 IDDY Award goes to Rearden Commerce

Chuck Mortimore today received the 2007 IDDY Award of the Liberty Alliance Project on behalf of Rearden Commerce. Chuck is the original author of the openinfocard id selector and the xmldap STS an RP. Congratulations!

Win an iPhone

The Bandit Project gives you the chance to win an iPhone if you get an Information Card here: https://cards.bandit-project.org/

So... You don't care about Information Cards and just want that iPhone? What is the shortest way to this goal?

If you have Windows Vista, then this is easy. Everything will just work out of the box.
If you have an older version of Windows or an "alternative operating system", then download the best browser on earth: Firefox and get an Id Selector e.g. the openinfocard id selector or something from here.

If you have Windows XP, then as an alternative way you might get IE7 and .NET3. And don't forget to visit update.microsoft.com afterwards.

Thanks to the Bandit Project for this promotion of information cards.

BTW: If I win, I would prefer the T-Mobile version. :-)

DIDW 2007 09 24 WLAN

This is off topic, but I am astonished by the number of WLAN access points "visible" in my hotel room. Maybe an error in my WLAN software?

IA Management

The openinfocard id selector now has a "Manage Cards" button on its preferences page.

The preferences are displayed when you choose the menu item "options" from the "tools" menu. Pressing the "Manage Cards" button opens the same window that pops up when you visit a relying party. You can create and delete self-issued cards from here and you can import and delete managed cards from here. You can't (currently) retrieve the values of a managed card from this dialog.

The new version (xmldap-0.9.8.200709212108.xpi) of the openinfocard id selector can be found here. I will update the version number to 0.9.8 after I added some more features; like displaying the privacy statement. This can't currently by done because Kevin Miller's Firefox extension uses privacyPolicy instead of privacyUrl and privacyPolicyVersion instead of privacyVersion. (And because the openinfocard id selector uses Kevin's selector selector.) I hope that either Kevin or Garrett will fix this soon.

Another needed feature for the openinfocard id selector is "phishing defense". This should not be too complicated to implement, but will make an update of the internal card store format necessary.

Anyway: Manage your cards!

Smartcards as a trusted security anchor

Today I am attending a CAST workshop about smartcards and their use to solve security problems.

The first talk is held by Michael Senkbeil from the Sparkassen Informationszentrum.
They have 64 million smartcards issued in Germany.
These cards are mandatory in Germany if you want to buy cigaretts. The card is used to proof that the buyer is old enough to buy cigaretts.
Mr. Senkbeil will tell us today how this scenario can be transferred to Internet usages.

First the user needs a smartcard reader and a browser plugin. Get the Plugin for Firefox here.
The browser plugin is triggered by the relyingparty. It contacts the smartcard and gets encrypted data from the card that it transfers to the relying party. The relying party has (multiple) server cards that decrypt the data and present the readable content to the RP. The server card(s) are issued by the Sparkasse too.
Phishing protection is not a main feature of this solution.
Mr. Senkbeil recomments to add this mechnism to the "normal" username/password scenario. If the card gets lost then there is no additional security on the card. It is not PIN-protected. So everybody can use the card. To minimize this risk he proposes to use a password in combination with this new scheme.

Feature list:

• age verification
• Laden der Geldkarte
• Internet Login

Q&A:

Q: Is this a Sparkasse only solution?
A: No. Every german "EC-Card" should work.

Q: API
A: PC/SC

Q: Demo had no password input
A: Card number is the userid. The password is the password of the relying party.
The password needs not be used.

Q: is the plugin signed
A: Yes it is.

Q: Profiling? Linkability.
A: is possible. The card number is a unique number.
My comment: This is not good. We need to integrate this with CardSpace.

Q: How does the user recognize the server? How does he verify that the server is the true one?
A: SSL. The proposed solution has no mutual authentication.

Q: How does the challenge-response mechanism work?
A: The RP generates a challenge that is used by the card. The plugin transfers the challenge to the card and receives an encrypted block of data. The RP has cards too, that decrypt the data and compare the challenge.

Q: Sparkassen Internet Banking: Will the Sparkassen use this mechanism to secure it's own internet banking?
A: A new class of smartcard reader is currently worked on. This will be released to the public next year.
Comment: This answer means: No.

Q: Is the cryptography symmetric or asymmetric?
A: Symmetric with derived keys.

Smartcards for Tachographs

The second talk is held by Mr. Klaus-Peter Schmidt from Sagem-Orga GmbH.

Security Evaluation of Smartcards

The third talk is held by Mr. Detlef Kraus from SRC Security Research & Consulting GmbH.

Crypto Algorithms for Environments with limited resources

The fourth talk is held by Mr. Axel Poschmann from the Ruhr-University of Bochum.
CPU-Market: PCs 0,2% -- embedded systems 99,8%

Smartcards: 8Mhz, 8bit, a few kilobytes memory

Metrics and tradeoffs for light-weight crypto

• security
• low cost
• performance

Mr. Poschmann explains the features of PRESENT (an ultra-lightweight block cipher).

The Identity of the Connector

Talk by Dr. Jens Urmann from InterComponentWare AG about a part (the connector) of the German health care system infrastructure. -> This usally gets messy really quick if you dive into the details... (not blog compatible)

Security anchors for mobile devices

Mr. Michael Kasper gives an overview over xSIM architectures.

• USIM
• MegaSIM
• Dual Trust-Anchor Architecture using (U)SIM and MTM (mobile trusted module)
• Single Trust-Anchor Architecture using virtual SIMs and a MTM

Next he gives an introduction to the Trusted Computing Group's Mobile Phone Working Group (https://www.trustedcomputinggroup.org/groups/mobile).
Then he describes his work about virtual SIM cards that are based on a MTM.
-> OpenMTM http://sourceforge.net/projects/openmtm/
EMSCB Turaya http://www.emscb.com/

SIM and USIM Application Toolkit

Talk by Mr. Harald Summer from Giesecke & Devrient.
Mr. Summer explains the file system of the SIM. He shows a tool by G&D to view the file system. Next he shows the internals of a SAT application and explains what bytes flow from where to where. Hard core tech talk.

Enabling Trusted Mobile Applications with the SIM

Talk by Mrs. Stephanie Manning from Vodafone Group R&D. The focus of the talk is about how to integrate NFC and mobile phone technology. She describes her projects and the techonological challenges. Applications/Products are to be expected in the first half of 2008... They are using Global Platform 2.2 for their projects. Vodafone and Deutsche Bahn will have a trial this year: http://www.touchandtravel.de/. Mrs Manning does not expect that Vodafone will deploy applications to the phone's SIM because then application providers would have to have contracts with every mobile operator. Trusted Services Providers will take the role of deployer of applications to "rented" space on the (U)SIM.

Multi-application security platform UICC

Talk by Mrs. Chen Hao from Giesecke & Devrient GmbH.
Mrs. Chen Hao talks about the single wire protocol and the new developments in UICC technology in general. A further example of these new technologies is the definition of a USB 2.0 interface directly to the UICC. This will allow for having gigabytes of memory on the UICC.

openinfocard id selector for Firefox signature validated

Finally! The signatures generated by the openinfocard id selector and the openinfocard STS are now accepted at relying parties that are based on Microsoft code. Mark Oluper from Microsoft's CardSpace team put the generated SAML assertions under his microscope and found the offending byte.

Axel,

The issue is that the key length doesn't match the signature length. The Windows CryptVerifySignature API verifies that the key length in bytes matches the signature length in bytes.

If you look at the modulus value for the Firefox identity selector generated assertion you will note that the value does not have the base 64 padding character whereas the signature value does. This results in a key length of 1032 bits (129 bytes) whereas the signature value is 1024 bits (128 bytes).

For the CardSpace generated assertion both the key length and signature length are equal to 2048 bits (256 bytes).

Regards,
Mark

So, what is the reason for this extra byte and why are the signatures accepted by relying parties that are Java based? Well, Java's BigInteger class introduces an extra null byte as the first byte when it converts a BigInteger into a byte array. I removed this extra null byte before base64 encoding the modulus of the signature key and now it works! AND the Java signature validation still works too!
Why does it work? Because Java just decodes the base64 encoded modulus and the constructor of BigInteger ignores extra null bytes but does not require them. There could be hundrets of null bytes and Java would still construct the same BigInteger modulus.

I did a quick check with self-issued and managed cards at several relying parties and all looks good.

- openinfocard RP (Java): local installation

- Bandit Project RP: https://wag.bandit-project.org/BanditIdP/index.jsp

- jinformationcard demo shop (Java): https://zeno.fokus.fraunhofer.de/MiniShop/home.jsp

- FuGen Solutions' Demo RP: Microsoft Code https://socialphotos.federationportal.com/

- FriendsWithCards RP: Microsoft Code https://www.cardspacedemos.com/FriendsWithCards/

The new - latest and greatest - version of the id selector is here in the openinfocard download area.
Thanks again to Mike Jones and Mark Oluper for helping with this issue!

Populate Attribute From Infocard

This is the real application for information cards. Using them for authentication purposes is fine, but the transportation of claims/attributes is the real thing.

The id selector used here was, of course, the xmldap id selector for Firefox in its latest version 0.9.7.200709111523. I used a self-issued card and a managed card from the current openinfocard STS. The RP used was the Bandit's project server for the next interoperathon (sorry, you have to login at OSIS to read this. Don't ask me why.) in Barcelona.

DIDW 2007

Meet me there.

OSIS Identification Required

Why do I have to identify myself when I just want to view the new OSIS timeline?

What about "Minimal Disclosure for a Constrained Use"?! Or the German Bundesdatenschutzgesetzt §3: Datenvermeidung und Datensparsamkeit?

And then this:

I can not view the new OSIS timeline because my IdP is offline.
This should never happen ;-) /* my favorite comment in C programs */

But then you think "pseudonyms are cheap". Let's just choose another openid. BUT:

Signon.com tells me that this is my openid: ignisvulpis.signon.com


Just in case somebody thinks this might be Firefox specific or has anything to do with the xmldap id selector (0.9.6). It has not. Here is the IE7 result:

Stranded in the Metasystem.

Openidcards

Thanks to Johnny Bufu's help I finally improved the xmldap Firefox id selector to be able to handle openidcards.



The id selector was retricted to SAML assertions as token type and could not handle "AppliesTo" correctly.
The new version can be downloaded here. Try it!

Again I want to thank Johnny for his patience and support. Without him I would not have found out about the wrong namespaces, missing elements etc. Thanks to Mike Jones too who did, as always, a great job bringing parties together.

AudienceRestriction

The xmldap relyingparty (svn version 339 or newer) now displays the subject's confirmationmethod:

urn:oasis:names:tc:SAML:1.0:cm:bearer or urn:oasis:names:tc:SAML:1.0:cm:holder-of-key

and the audience restriction.

...
<saml:Conditions 
 NotBefore="2007-08-21T07:18:50.605Z" 
 NotOnOrAfter="2007-08-21T08:18:50.605Z">
 <saml:AudienceRestrictionCondition>
  <saml:Audience>
   https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/
  </saml:Audience>
 </saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
 <saml:Subject>
  <saml:SubjectConfirmation>
   <saml:ConfirmationMethod>
    urn:oasis:names:tc:SAML:1.0:cm:bearer
   </saml:ConfirmationMethod>
  </saml:SubjectConfirmation>
 </saml:Subject>
 ...

Here are two screenshots of the relying party:
First the assertion generated by the Firefox id selector:

Second the assertion generated by Windows CardSpace:

The scrupulous reader of this blog will notice that this Firefox id selector generated a bearer token, while I claimed here, that it generates holder-of-key tokens. I am still investigating why the Microsoft Demosite FriendsWithCards does not accept my tokens :-| It still says that the signature is wrong... That's why I want the token to be as similar to the CardSpace one as possible.
Anyways, with the help of Microsoft we will find the reason for this. Thanks to Marc, Mike and Kim.
Back to the topic of this post: It is good that the xmldap relyingparty now shows the audience restriction.

LiveId not supporting Firefox Id Selector (or vice versa?)

Christian Arnold reports that Microsoft Live is now supporting (beta) Information Cards.
I tried this with the Firefox Id Selector but...


Well, I don't know what's wrong here. Maybe it is the same issue as with FriendsWithCards...? Mike Jones told me he will have somebody look into the FWC issue. I fixed the computation of the thumbprintsha1 inside the Firefox Id Selector, which now computes the digest of the entire certificate bytes (instead of the digest of the public key bytes). FWC could not find the certificate, while other relying parties just use the certificate of the SSL connection, instead of searching for the certificate.
But still FWC does not like the SAML assertion generated by the Firefox Id Selector :-(

Besides: LiveId is no major Internet business according to Microsoft CardSpace:

BTW: How do I remove my information card from the LivID profile? Could not find this option. Maybe a typical user management one way street?

Self-Issued Cards, SIC!

I feel that the focus of Windows CardSpace changed from providing claims to be a mere login mechanism with claims dangling behind it.

Are relying parties really using the provided claims? Will relying parties use the provided claims in the future?

I think that enabling the user to control the claims provides a way to get rid of most of the user management at the RP.
No more "Edit your profile" webpages which are different from site to site.
Just edit your information card and use it. All sites will get the new updated information about you.
But what if the RP needs more/different claims than the standard self-issued ones. Today we would need to introduce an identity provider that issues managed cards with that set of claims.
Why are we not extending the self-issued token server to serve any set of claims?

The user would still be in control of his claims.

Habits

Yes, I read xkcd and hope the author does not mind my abuse of this comic strip.
Read this to understand the tooltip in the original comic.

Presentation of Claims

As I wrote in a previous post I added a demo geopriv STS to the openinfocard code repository which manages civic addresses. As claim's identifiers I used URLs inspired by rfc4119 e.g.
urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc:A6 (street name without number)
You might have seen here and in the image above that the presentation of these claims in the id selectors GUI is, well, not satisfying.
The displaytag and the claim's description from the information card are not very helpful in the case of civic addresses. Maybe the rendering information should be attached to the DisplayToken instead of to each DisplayClaim.
The format of an rfc4119 civic address was designed to work around the globe which makes it a little bit difficult to handle.

Which choices do I have as an id selctor and/or STS?

• I could use a (deep versus flat) claim: ietf:civicaddress which has an XML civicaddress as it's value.
  Current id selectors would display this in one line... Not pretty
  Future id selectors would know that the value of the claim ietf:civicaddress is not a plain text but XML which should be rendered as a user expects it.


• I could enhance the id selector to render claims of this kind appropriately.
  I would have to do this for every new set of claims. -> not elegant


• The STS could include an XSLT (XML geopriv civicaddress to HTML) script to render the claims in the id selector.
  Maybe the RP does know how to render the claims better?
  Maybe the user knows how to render the claims better?


• The RP could render the claims while I chose which card to present.
  This is not desirable, because the RP would learn about all my cards.


• The id selector could render the claims using CSS/XSLT provided by the RP
  Do I trust the RP this much?


• The id selector could render the claims using it's own (provided by the user?) CSS/XSLT script.
  Only a few users will be able to understand this.

More questions than answers. Sorry.

The flat versus deep claim's value needs more discussion too. Maybe it is another side of the same coin? Not.
Mark Wahl has put this far better than me in this short post. His posts are here and here.