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.

How to sign a J2ME midlet with a Verisign code signing certificate using EclipseME

Get a code signing certificate
This can be from Verisign. The certificates issued by Verisign have the special "feature" that they are issued by an intermediate certificate authority. The certificate of the intermediate CA is unknown to your phone and thus the signature verification fails :-(
The following steps describe one way to make it suceed.

Configuring Eclipse to sign your midlet

See also: http://eclipseme.org/docs/refSigning.html

- Open the project properties and select j2meCheck the box "sign midlet" and enter the path to your keystore and the alias of the key.

Up to here everything is well documented in various places in the web.
MIDP_2_0_Signed_MIDlet_Developers_Guide_v2_0_en.pdf.html
Chapter 4.3 talks about intermediate certificates.

Now for the not so well documented issues

- Open the jad file in Eclipse

Select the "optional properties" tab to enter the "midlet permissions".
In my example these are "javax.microedition.io.Connector.serversocket"

Now the essential bit. Open the user defined tab and create a new entry named "MIDlet-Certificate-1-2". The value is the intermediate certificate (in one line and without the "-----BEGIN CERTIFICATE-----" and the "-----END CERTIFICATE-----").


-----BEGIN CERTIFICATE-----
MIIEvzCCBCigAwIBAgIQQZGhWjl4389JZWY4HUx1wjANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDQwNzE2MDAwMDAwWhcNMTQwNzE1MjM1OTU5WjCBtDELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMlVmVyaVNpZ24gQ2xhc3Mg
MyBDb2RlIFNpZ25pbmcgMjAwNCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAL687rx+74Pr4DdP+wMQOL4I0ox9nfqSfxkMwmvuQlKM3tMcSBMl6sFj
evlRZe7Tqjv18JScK/vyZtQk2vf1n24ZOTa80KN2CB4iJyRsOJEn4oRJrhuKof0l
giwQMOhxqyjod0pR8ezN+PBU1G/A420Kj9nYZI1jsi1OJ/aFDv5t4ymZ4oVHfC2G
f+hXj61nwjMykRMg/KkjFJptwoRLdmgE1XEsXSH6iA0m/R8tkSvnAVVN8m01KILf
2WtcttbZqoH9X82DumOd0CL8qTtCabKOOrW8tJ4PXsTqLIKLKP1TCJbdtQEg0fml
GOfA7lFwN+G2BUhSSG846sPobHtEhLsCAwEAAaOCAaAwggGcMBIGA1UdEwEB/wQI
MAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDEGA1UdHwQqMCgwJqAkoCKG
IGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDAzAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4QgEBBAQD
AgABMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFDbGFzczNDQTIwNDgtMS00MzAd
BgNVHQ4EFgQUCPVR6Pv+PT1kNnxoz1t4qN+5xTcwgYAGA1UdIwR5MHehY6RhMF8x
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMu
Q2xhc3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIQ
cLrkHRDZKTS2OMp7A8y6vzANBgkqhkiG9w0BAQUFAAOBgQCuOhe4SntV+mRV7ECk
7UlBkJmcibyvLh3KeCP5HBkPf+tovDLZiDje3D/TibQ/sYKW8aRauu0uJtPefAFu
AAoApAaSEUgJQPkcGHlnIyTgu9XhUK4b9Q7d4C6BzYCjbFJPkXVViroi8tLqQXWI
L2NVfR5UWpVZytk0gcBfXvZ6tQ==
-----END CERTIFICATE-----


In the Verisign case you can obtain the intermediate certificate from here: http://www.verisign.com/support/verisign-intermediate-ca/
code-signing-intermediate/index.html



The resulting jad file should look something like this:
MIDlet-1: ServerSocket,,ServerSocketTest
MIDlet-Certificate-1-1: MIIE1jCCA76gAwIBAgIQG5t/GM10hgvEMeYewFYfOzANBgkqhkiG9w0BAQUFADCBtDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMlVmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAwNCBDQTAeFw0wNzAzMTYwMDAwMDBaFw0wODAzMTUyMzU5NTlaMIGnMQswCQYDVQQGEwJERTEPMA0GA1UECBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xKzApBgNVBAoUIlQtU3lzdGVtcyBFbnRlcnByaXNlIFNlcnZpY2VzIEdtYkgxHDAaBgNVBAsUE1N5c3RlbXMgSW50ZWdyYXRpb24xKzApBgNVBAMUIlQtU3lzdGVtcyBFbnRlcnByaXNlIFNlcnZpY2VzIEdtYkgwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK0FJv9g3xIFUFYMSZ7wfrX3N+X4UHlrWVDsdKQ3DJ2tXdnY9OaocSMp4lb5UqjPZxQvHUo5ogJs8jgSB2yp5OWH6DCYfIR6rxxuKI5evNhOwX3nuoyd5L/S2NmPHLig384XdPKjFBSjZUbOpWvofHMwcRvs380LdUe2K99hnuEHAgMBAAGjggFxMIIBbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIHgDBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vQ1NDMy0yMDA0LWNybC52ZXJpc2lnbi5jb20vQ1NDMy0yMDA0LmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMDMHUGCCsGAQUFBwEBBGkwZzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMD8GCCsGAQUFBzAChjNodHRwOi8vQ1NDMy0yMDA0LWFpYS52ZXJpc2lnbi5jb20vQ1NDMy0yMDA0LWFpYS5jZXIwHwYDVR0jBBgwFoAUCPVR6Pv+PT1kNnxoz1t4qN+5xTcwEQYJYIZIAYb4QgEBBAQDAgQQMA0GCSqGSIb3DQEBBQUAA4IBAQBGd+ZCppyQvEPvedj7FMl/nwUa/alEsr8XdOP1MzaueUsZeUAykg1uGow9Cey4pbw7NNTg1C8nKHvf652gSixMJjsESpfXqbkSRnPNZl/bu4zm8yWcg1G89ZaxndKqLdr+ww5jmHCsQyRh6Nurj6bTZNtXGdo2VMFpUWqZbCZjD0PsQa4ObZuyoIC4UTy2oTl3paKJhsaoBZLD/P2v6X6+R34GU/dz0QaT1ChlrwMrWJXYCLb4eL1YSIu44r7u5yKhLZBCWFGgDpZjh8tWJihOrq93tWE+yoO9c4eabNT8d3T4stxUo82pN140om64bgVU6Y8A6ZhrLJ5C/Fzqfdf+
MIDlet-Certificate-1-2: MIIEvzCCBCigAwIBAgIQQZGhWjl4389JZWY4HUx1wjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQwNzE2MDAwMDAwWhcNMTQwNzE1MjM1OTU5WjCBtDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMlVmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAwNCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL687rx+74Pr4DdP+wMQOL4I0ox9nfqSfxkMwmvuQlKM3tMcSBMl6sFjevlRZe7Tqjv18JScK/vyZtQk2vf1n24ZOTa80KN2CB4iJyRsOJEn4oRJrhuKof0lgiwQMOhxqyjod0pR8ezN+PBU1G/A420Kj9nYZI1jsi1OJ/aFDv5t4ymZ4oVHfC2Gf+hXj61nwjMykRMg/KkjFJptwoRLdmgE1XEsXSH6iA0m/R8tkSvnAVVN8m01KILf2WtcttbZqoH9X82DumOd0CL8qTtCabKOOrW8tJ4PXsTqLIKLKP1TCJbdtQEg0fmlGOfA7lFwN+G2BUhSSG846sPobHtEhLsCAwEAAaOCAaAwggGcMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgABMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFDbGFzczNDQTIwNDgtMS00MzAdBgNVHQ4EFgQUCPVR6Pv+PT1kNnxoz1t4qN+5xTcwgYAGA1UdIwR5MHehY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIQcLrkHRDZKTS2OMp7A8y6vzANBgkqhkiG9w0BAQUFAAOBgQCuOhe4SntV+mRV7ECk7UlBkJmcibyvLh3KeCP5HBkPf+tovDLZiDje3D/TibQ/sYKW8aRauu0uJtPefAFuAAoApAaSEUgJQPkcGHlnIyTgu9XhUK4b9Q7d4C6BzYCjbFJPkXVViroi8tLqQXWIL2NVfR5UWpVZytk0gcBfXvZ6tQ==
MIDlet-Jar-RSA-SHA1: kR0z1GiL6cZ7D+cQSjVYpI2zT5IGpOGZ6FVEF2VnVOwwVm+aQywWZkKDxKB6IgoiCcnqCqD7fTAAyHhrMvcqzW5CHpJ3uvmwvXhTdKRhBRWtra4C0e+lzBSzmD6ET+8bZaweFjmp4uxzGzH/0YMFnJFzrzLcYa0R1jDz01xANG4=
MIDlet-Jar-Size: 4334
MIDlet-Jar-URL: ServerSocketTest.jar
MIDlet-Name: ServerSocket
MIDlet-Permissions: javax.microedition.io.Connector.serversocket
MIDlet-Vendor: T-Systems Enterprise Services GmbH
MIDlet-Version: 1.0.9
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0



Now signing your midlet should work and the phone should be able to verify the signature.

New openinfocard INSTALL file

prerequisites
java and probably JAVA_HOME set
ant and probably ANT_HOME set

Firefox Identity Selector
Firefox (tested with 2.0)

Relyingparte and STS
tomcat or jboss or...

Installation procedure
Firefox Identity Selector

cd ant && ant
// currently 7 warnings

cd ../build
open xmldap.xpi with Firefox and restart Firefox
navigate Firefox to https://xmldap.org/relyingparty/ to test

If something does not work...
Look at the Firefox javascript console!

STS and Relyingparty
Install your application server (AS)
Edit server.xml to enable SSL/TLS
Create a self-signed cert and test your AS with https.
keytool -genkey -alias xmldap -keypass password -keystore keystore.jks -storepass password -keyalg rsa -validity 1000 -sigalg SHA1withRSA

Please note: the default keyalg for keytool is DSA. DSA is not supported by CardSpace and not by this relyingparty.
The default sigalg for RSA is MD5withRSA. This is not supported by CardSpace and not by this relyingparty.


Now your application server is ready to serve https. Good.

Edit mex.xml, rp-web.xml and sts-web.xml and
- replace xmldap.org by your AS domainname and port
e.g.: xmldap.org -> w4de3esy0069028.gdc-bln01.t-systems.com:8443
- change the name of the keystore, alias, keystorepass and keypass
to appropriate values for your environment
Copy build/sts.war and build/relyingparty.war to the
deploy directory e.g. $JBOSS_HOME/server/default/deploy
Start your AS. $JBOSS_HOME/bin/run.bat (or run.sh)

Navigate Firefox to your https://domainname:port/sts/ and
create a managed card.
Navigate Firefox to your https://domainname:port/relyingparty/
Click "New Card", choose "managed card" and import the created card.

Now everything should work. Add a comment at http://xmldap.blogspot.com/
how cool this all is.


If something does not work...


Look at the AS logs!
If its something with "keystore not found" or the like, then check
rp-web.xml and sts-web.xml

If the AS complains about "/Users/cmort/..." not found, then check
rp-web.xml and sts-web.xml again. If these are clean, edit ServletUtil.java
and insert your keystore, password etc. Sorry. Somebody should fix this...

- Axel Nennker

If you are using SUN One Applic

Firefox 2.0 Identity Selector

The current version (0.6.0) of the Firefox Identity Selector for Firefox 2.0 can be found here:
ftp://mailer.berkom.de/pub/nennker/xmldap.xpi

It supports the display of an issuer logo. An issuer logo is specified inside the relying party's X509v3 certificate (http://www.ietf.org/rfc/rfc3709.txt). The current version extracts the issuer logo URL from the certificate and displays the logo.

This work is based on Charlie Mortimore's Firefox Identity Selector: https://xmldap.org/