So lets assume that one installs (for load) the muscle applet to reference
ones own security domain, previously loaded and instantiated on the card.
Using the install [for install] command, we denote the muscle applet now as
the default select.
Unfortunately, libmusclecard attempts to do a select file, when
imple,menting MuscleConnect(), assuming that its talking to a card manager,
after poweron. If it fails to get the approprate response, it assumes that
the conenction (to the applet) has failed.
To address this,
(1) should we simply allow the muscle applet to implement the select file
method, as a stub, for frameworks that assume that they will initially talk
to a card manager/security domain?
(2) Or should I create a new musclecard plugin, to libmusclecard - one whose
MuscleConnect command does not attempt to interact with a card manager?
(1) is an easy hack. (2) is more correct.
From: "Peter Williams" <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: [email protected]
Subject: Re: [Muscle] muscle applet as a cardmanager?
Date: Thu, 15 Sep 2005 12:07:05 -0700
ok
the process indicated below works (on my GP card) if one ensures that the
install [for install] parm references a unique instance AID, when having
the ISD delegate the default select app priv.
This makes a lot more sense now.
The MS CCID, upon enumeration, does a poweron; CCID itself performs no
select file operation.
If one is using the PC/SC and smartcard fraemwork, the resource
manager/smartcard pluginmay or may not inspect the card, to determine its
interfaces. If it does, presumably it MUST explicitely select the security
domain of its choice, to perform card management queries. It canno assume a
ISD or particular security domain is default selected.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
