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.