Yes. The openinfocard selector remembers passwords too but
this is not the same as "instant cards".
I think remembering passwords is infact something very
different than what instant cards are trying to achieve.
The deployment of the managed card is the problem. Users
just don't understand backed-by-a-self-issued-card or backed-by-a-X509-cert. I
think that storing the ad-hoc STS-credentials inside the card private data is
adequate.
Sure these credential should be protected as all
credentials should be protected. Whether this is by means of a masterpassword
for the cardstore or PIN-protecting the card... (Maybe we need a SAML
authncontext)
-Axel
The
Higgins Firefox-Embedded Selector and the Higgins AIR selector both already
support “remember password” for m-cards. They don’t solve the first-time-use
problem, but the overall experience is not too bad, and very similar to other
familiar systems, like the FireFox password manager, where you do need to type
the un/pw on the first use, but then have a checkbox for ‘remember’, so that
you never need to type it again.
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On
Behalf Of Nennker, Axel Sent: Thursday, May 22, 2008 4:54
AM To: higgins-dev@xxxxxxxxxxx Subject: [higgins-dev]
Instant Managed Cards
I am in discussion
with Microsoft about the instant card but would like to hear what you
think of it.
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.
|