KDE and smartcard support

[Aaron J. Seigo]

On Wednesday 23 May 2007, Oswald Buddenhagen wrote:
> On Wed, May 23, 2007 at 12:10:11PM -0600, Aaron J. Seigo wrote:
> > let's say that this ends up with us using QCA everywhere. who knows,
> > that might be the solution. to reach that one can rewrite all pieces
> > of KDE crypto all at once in some massive branch in svn (which, i hope
> > you'll agree, unrealistic and silly) or we can work things out piece
> > by piece.
>
> hmm? who exactly said everything needs to migrate to QCA immediately?
> alon just wants a verdict "yes, we want this", so he can start
> contributing code which he knows won't go down the drain.

so i think we're actually all on the same page. great =)

> > prove the possibilities by solving the issues of getting
> > KPasswordDialog to have a token input mode;
>
> that one doesn't make too much sense. KPD cannot provide a universal
> token input mode - if this was possible, the entire kdm greeter plugin
> stuff would be thoroughly pointless.

what i mean is that KPD should be able to not only provision passwords from 
the user to the application, but also it (or an analog of it) should provide 
a user interface as well as an API for application developers to easily 
request credentials via hardware based systems (smartcard, fingerprint 
scanner, whatever) ...

> requesting tokens is the task of the particular provider. it might use
> KPD or whatever else it deems appropriate. technically this is an almost
> trivial issue - just like the implementation of KPD.

agreed. i was attempting to point people to the low hanging fruit that are 
obvious and easy entry points from which we can start to talk about things in 
concrete terms. e.g. patches. that is why i keep bringing up something that 
is technically a trivial issue.

> really work - the configuration framework needs to cover everything, so
> in any case we have to endorse the framework we are using internally -
> and if we switch, 3rd party developers (or rather, the users) would be
> pretty much screwed.

we've been there and done that already, just not with crypto but with 
multimedia, hardware awareness, PIM data, etc. maybe we could learn something 
from those lessons?

i'd also be cautious about falling into the "perfect solution" trap. this may 
be a case where "incremental deployment", whilst imperfect along the way, has 
the best chance of getting results (including a "perfect" solution) quicker 
due to less friction (c.f. 90% of this thread) =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070523/06750899/attachment.sig>