Hi, >If, as an PC/SC application author, you think something is missing in >the PC/SC standard just tell me. I will try to propose it for >inclusion.
Just my 3 cents: - A standard way to specify the messages to be written on the pinpad reader (for readers with a display, of course) - A 'pin merge' feature: part of the PIN is provided by the app and the other part is entered on the pinpad reader. (Some readers already allow this: you just put part of the PIN in the APDU -- but some readers seem to overwrite the APDU's PIN buffer with padding bytes..) - Currently, only Verify and Change pin commands exist. On most readers, you can (ab)use them to do an Unblock without resp. with pin change; but some readers check the INS byte during a Verify command -> so it's not possible to do an Unblock without pin change. Hope it's clear, and that those features aren't in already (didn't do my homework either..) Br, Stef On 10/10/2011 10:16 AM, Martin Paljak wrote: > Hello, > > On Sun, Oct 9, 2011 at 20:10, Ludovic Rousseau > <[email protected]> wrote: >> One particularly missing member is Microsoft. Microsoft was a core >> member for a long time but has now disappeared from the PCSC workgoup >> list. > Doesn't this seriously decrease the workgroup's ability to influence > things, given the current practice and status quo of pcsc-lite vs MS? > >> If, as an PC/SC application author, you think something is missing in >> the PC/SC standard just tell me. I will try to propose it for >> inclusion. > Organizational: > - provide the specs in a way that can be diff-ed for changes. Would > be lovely :) > > Meaningful questions/suggestions (some probably reflect my bad > homework on the subject, as they might not be in the scope of this > workgroup): > - Work out firewalling and settle on a specific SW for "command > firewalled" status (intersection between CCID/firmware level and > PC/SC) > - Who actually defines the SCard* API? What about the "card groups, > reader groups, card databases" and whatnot is in MS SCard* scope? > - Bridging with USB/CCID folks to define and enable features and > requirements coming from applications (through PC/SC, like OpenSC et > al) and uniformly take them to the device firmware (things like custom > display texts, feedback on keypresses (dangerous!) etc) by extending > CCID. > - Creating some kind of standard/certification for smart card readers > that is a mark of quality and interoperability, setting certain > requirements for qualification that can be verified by independent > third party validators (maybe something like FIPS, but with less heavy > impact on cost and deadlines) so that there would be no bogus readers > on the market in the future. Buying a 50€ smart card reader and > discovering that it does not accept my 10 digit PIN code is not nice. > Or finding that a "secure PIN entry" device is actually pushing data > to USB bus is also a bad sign. > > Best, > Martin > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle > . > _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
