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.

Issuer Logo

The Firefox id selector (0.9.4) now displays the issuer logo from the relying party's X509 certificate again. I had added that code last autumn but the code calling this code was lost when Chuck redesigned the GUI in preparation of an IIW. I never cared much to put it back in, because I was kind of frustrated with EV certificates. I tried really hard to generate an EV certificate; I generated a CA certificate and put in the "trusted" store. Next I used that to generate a SSL server certificate which had everything in it what is required to comply to the Certificate Guidelines. But neither IE7 nor Cardspace accepted this as an EV certificate. Then I learned that being an EV certificate is not a matter of the certificate but a matter of the certificate store. Microsoft developers have a custom tool to turn a certificate inside the store into an EV certificate :-{
Well, this weekend I put the code back in. Here are two pictures of the Firefox id selector displaying the issuer logo from my own local relying party

and the issuer logo from verisign's PIP relying party.

The logotype ASN.1 stuff is here. The java code to generate my own SSL server certificate with logotype support is here in org.xmldap.util.CertsAndKeys.java.
Example code how to use the code is in the JUNIT test org.xmldap.asn1.LogotypeTest.java.

jinformationcard improved minishop

In yesterdays post I wrote that the jinformationcard minishop does not accept the security tokens generated by the Firefox id selector.
Today Steffen Konegen sent me an email that he fixed this in the jinformationcard relyingparty. Cool.

Microsoft CardSpace Demo Site is not working with Firefox Id Selector

I just tried to login using my self-issued informationcard


at Fabrikam Friends. But it throws an error page at me.


My guess is that Fabrikam Friends can only handle bearer tokens not holder-of-key tokens. I noticed the same behaviour at the jinformationcard demo shop.
The internal STS in Windows CardSpace issues bearer tokens


while the Firefox ID selector issues holder-of-key tokens.


Bummer!
Kim's Identityblog is still accepting my tokens. Good.

Though I won't rule out that something is wrong with the Firefox id selector tokens. When 's the next interop?

New Version of the Firefox ID Selector

Today I committed new code to the openinfocard repository.
This has the version number 0.9.3.

• It improves support for managed claims in the Firefox ID selector


• It implements a sample relying party and STS for geopriv claims (civic address)
  

First a managed cards is created, that holds the civic address of my office:

Then the relying party is visited:

The managed card is chosen:

Here are the provided claims:

The managed claims url's are "inspired" by rfc4119.
Besides serving static addresses the new geopriv_sts could issue a security assertion that is based on the current location of the requestor. For this the STS should be operated by the access provider. The authentication to the STS should be by self-issued information card and/or IP-Address (The usual NAT/STUN problems/solutions have to be considered, of course). The client could be a VoIP phone.
In my opinion many topics in the ECRIT mailing list could be addressed by this kind of STS.

FireFox Identity Selector Selector

"This is not the Firefox Identity Selector, I used" I heard this morning and not for the first time. People try Kevin Miller's Firefox extension to get CardSpace support in the best available browser on their Windows PC and come to think that this extension is the identity selector. Well, Kevin never made the claim that his extension is the identity selector. He wrote: "The FireFox Identity Selector extension implements support for CardSpace on Windows". Which means: it handles the embedded html object and calls the Windows CardSpace identity selector. Kevin continues: "Additionally, the extension provides the ability to plug-in other Identity Selectors".
This is true. THE Firefox identity selector can be found here: http://www.xmldap.org/

So, if your Firefox identity selector does not look something like this, then you are not using the Firefox identity selector. Try it:

Firefox ID Selector and J-Informationcard RP

Today I noticed that the demo site of the Microsoft sponsored project J-Informationcard did not work with the Firefox ID selector. I suggested to Steffen Konegen to use the HTML Kit provided by Microsoft to detect CardSpace support and he promptly did. The image shows their login page.
Nice to have new relyingparty.

Proof Pudding: Identity Metasystem and CardSpace Interop in Action

I missed this video because I was on vacation when it was released.
Great stuff about the Bandit-Project ID-selector interoperating with CardSpace and a nice demo of CardSpace on a mobile phone (Windows operating system, of course).

eCards and CardSpace

Yesterday, Friday 13th July 2007, I attended a workshop "Biometrics and eCards".

My main interesst was the "eCard API" which is currently standardized in Germany. This API is intendet to standardize the access of applications to the cards issued by the German government. My first impression of the eCard API was that it is quite (!) complex. Building a complying smartcard, reader and dll/jar/so looks challenging.
Several participants from the industry complaint that the standardization process is not open enough, to late and that the dead-lines are too short. My impression was that everybody exept delegates from the BMI and BSI seemed to agree.

Why am I blogging about this here? Because I was happy to learn that Identity Management and Privacy could be found everywhere. It was certainly not the main focus of many talks but CardSpace and SAML and WS-* etc popped up here and there and people I talked to during the breaks all had profound knowledge of this.
This gave me the thought that current and future projects envolving smartcards are not doomed from the beginning.
Germany was one of the first countries to have laws regarding electronic/digital signatures, but all projects (e.g. e-Vergabe) trying to utilize this and/or to make money from it (eCommerce/eGovernment) currently live in the dark and remote parts of public attention and economic success. By which I don't want to say that this projects are not necessary. They are important projects but people and companies are reluctant to use them until they are forced to by law.

One new project I found especially interessting. Mr. Thomas Biere (BSI) gave a talk about "Bürgerportale" (citizen portal). One of the functions of the portal is that of a identity/attribute/claims provider. The federal government plans to have these portals be operated by private companies which are certified by the government. Interessting. Mr. Biere said, that they are talking to major ISPs about this.
I am curious how this will work out in the end. Will the Id/STS primarily issuing the claims _it_ knows about a subject or will the main focus be on the usage of government issued/asserted claims. Id/STS interoperability is planned to be left to the operators... Interoperabilty to the portals of germany's states is an open issue too. Integration of emerging other solutions like openElster are open too.

There is a lot of work to do to make the identity revolution happen ;-)
But we will certainly by part of it. (Hm. Don't interprete this post too much in term s of what subsidiaries of Deutsche Telekom will do. These posts are _my_ posts)

identity.xsd glitch

While applying xmlbeans to identity.xsd I noticed that an imported schema could not be found. "http://www.w3.org/2005/08/addressing/addressing.xsd" does not exist.

My guess was that this is like the claims URL-change. http://schemas.xmlsoap.org/ws/2004/08/addressing/addressing.xsd does exist.
This looks similar to the URL-change CardSpace enthusiasts had to endure when the claims where changed from e.g. "http://schemas.microsoft.com/ws/2005/05/identity/claims/" to "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/". This introduced some work in the openinfocard project.

Microsoft says:
"The schema location for namespace http://www.w3.org/2005/08/addressing should be http://www.w3.org/2006/03/addressing/ws-addr.xsd.

The schema at http://schemas.xmlsoap.org/ws/2005/05/identity/identity.xsd will be fixed."

A quick search using Eclipse throug the openinfocard source code found 12 matches for the current URL...

It seems we need to introduce a new constant:
static final String WSA_NAMESPACE_06_03 = "http://www.w3.org/2006/03/addressing";
static final String WSA_NAMESPACE_04_08 = "http://schemas.xmlsoap.org/ws/2004/08/addressing";
static final String WSA_NAMESPACE_05_08 = "http://www.w3.org/2005/08/addressing";
static final String WSA_PREFIX = "wsa";

CardSpace' Dimensions

While thinking about how Windows CardSpace could be used and extended I came up with this graphic.



Thus the dimensions of Windows CardSpace are:

1. Cardstore: Where is the cardstore?
   Service Providers store the information cards and facilitate the use through different devices.


2. CredentialStore: Where are the credentials?
   Storage of credentials and engine for cryptographic operations.


3. UI Generation: Where is the UI generated?
   The UI could be generated on a server but be displayed on one of the user’s devices.


4. Identity Selector (UI): Where is the UI displayed and where is the Information Card selected?


5. STS: Where is the STS?


6. STS Authentication: Authentication Technology


7. Browser: On which device is the authentication needed?

Now imagine all the combinations of the coordinates which span "use case space". My colleague Jochen Klaffer designed and implemented a tool which helped us a lot to find relevant use cases in our "CardSpace for Telcos" project which we are doing for Deutsche Telekom Laboratories' Jörg Heuer.

This is of course only a selection of possible dimensions. Others were excluded for simplicity and because there are strong indications that they will never be relevant. Kim Cameron said e.g. about using different protocols instead of WS-*: "This will not happen".
So the "Trust Protocol" dimension is not shown in this graphic.

Other dimensions missing are new transport protocols like SIP instead of HTTP to transport the RST/RSTR. So the "Transport Protocol" dimension is not shown in this graphic.

You will probably notice that there are points on the axis that are not part of CardSpace version 1.0...
Let us look at CardSpace 1.0.

1. Cardstore: local (secure desktop).


2. CredentialStore: local (secure desktop).


3. UI Generation: local (secure desktop).


4. Identity Selector (UI): local (secure desktop)


5. STS: local or network


6. STS Authentication: fixed set of four technologies


7. Browser: PC

So this the current state, but the universe is expanding, right?

Interpretation of the axes and the new points the axes is left to the reader ;-)

jinformationcard and openinfocard "in the house"

Yesterday I learned that the team of the new java CardSpace project jinformationcard works in the same building as I do. As I am a contributor to the openinfocard project we now have two independent java CardSpace projects "in the house".

The new project is run by the Fraunhofer Institut for Open Communication Systems while I work for T-Systems.

Joining forces seems easy.