Instant Managed Cards

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

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

• self issued cards
• X509 certificates
• kerberos

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

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

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

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

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

Alles wird gut.