Im not sure I have addressed the full set of issues - even within the muscle
community. My only goals was to to get a faster reader/card setup, not to
address norms and standards.
If I put on my old OSI standards hat:
The host-side muscle provider only bothers to Identify the card (i.e.
attempt to bind to a card manager or applet) if the PC/SC context is NOT
direct.
Lets turn that around: if the context is direct, the host application is
responsible for make an explicit bind to the cardmanager/applet of its
choice.
So, we could retain the traditional behaviour in muscle (bind to cardmanager
on connect), unless the application has created required a direct channel =
specifically in order to take control over the initial security context
issue itself.
I dont know if these "direct" semantics used by Muscle are infact consistent
those ordained by PC/SC for "direct" connections, but they make a certain
sense.
If I were couseling a std.s track effort, I suspect Id mandate that
applications correctly use direct channels, rather than use the hack I am in
fact applying.
From: Peter Tomlinson <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: MUSCLE <[email protected]>
CC: Teresa Schwarzhoff <[EMAIL PROTECTED]>
Subject: Re: [Muscle] muscle applet as a cardmanager?
Date: Fri, 16 Sep 2005 07:14:29 +0100
Karsten Ohme wrote:
Peter Williams wrote:
Karsten,
you might consider including the following code modification (note last
line), in the musclecardApplet.c plugin. If the length of the default
applet AID is 0, for the AID one looks up in the service.plist having
determined the coldreset ATR, then no further identification is required.
OK, thanks, I applied the patch. This would mean that the
programmer/installer of the card must know if the card has the default
selected privilege and is already selected by default. I addition to
this I could implement a handling of SELECT commands in the CardEdge
applet, so that is can execute the SELECT command and will not fail.
Karsten
ISO SC17 WG4 TF9 is developing an interoperability standard (to be ISO/IEC
24727) intended to do two things:
- define a deterministic method for reliably starting up a card
- provide standard methods for finding card contents
The aim of course is that the problem of the terminal having to know about
the card before it starts it has to go away. Note that I appreciate that
some developers want to have a specific app default selected - if that is
to continue, then there has to be a command (and its implementation in the
card) included in the startup sequence to allow the terminal to determine
what app is default selected (card manager or a user app) - that may affect
JCRE which, if I read it correctly, says that SELECT on AID is intercepted
by the card OS, but all other commands get passed to the currently selected
app (although there are of course some other card management commands
expected to be intercepted).
So to questions to the list (and TF9):
- are MUSCLE developers, GP, JCRE, and WG4 TF9 working together here?
- is WG4 TF9 outlawing default user app select at card startup?
Peter
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
