2011/10/10 Martin Paljak <[email protected]>: > 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 :)
The specifications are MS WORD documents. We are in a corporate world here. The documents have a "Revision History" section at the beginning listing the major changes. I agree, a diff-able format would be cool. But I do not expect any change on this. > 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) OK Can you give me the different options you have seen in the field? > - Who actually defines the SCard* API? What about the "card groups, > reader groups, card databases" and whatnot is in MS SCard* scope? The PC/SC workgroup defines "abstract" function like EstablishContext in PC/SC v2 part 5 page 11 as: RESPONSECODE EstablishContext ( IN DWORD Scope, // A scope indicator (see below) IN DWORD Reserved1, // Reserved for future use to allow privileged // administrative programs to act on behalf of // another user IN DWORD Reserved2 // Reserved for future use to allow privileged // administrative programs to act on behalf of // another terminal ) Then Microsoft implemented it as SCardEstablishContext(). Notice the name change. Some people in the workgroup to not want the specification to be tied to a specific language like C. It is very strange. So the real API "specification" is Microsoft MSDN. What is you real question? > - 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. PC/SC defines methods to access key pressed events using FEATURE_GET_KEY_PRESSED from PC/SC v2 part 10. For digits you only get the same value 0x2B. The idea is to be able to display a star character and have some feedback for the user. This service is NOT defined in the CCID specification. One reader manufacturer implemented it and another just copied the implementation. But this is not publicly documented (AFAIK). So it is not yet available in my CCID driver. PC/SC defines FEATURE_WRITE_DISPLAY to display a message. But I don't know any reader supporting it. And this is not defined at the CCID layer. The CCID workgroup is now closed. It would be a lot of paper work to resurrect it. My proposal would to document the CCID extension by the PC/SC workgroup as a "de facto" standard. > - 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. Microsoft has a "certification" program. But this program has been defined 10 years ago and have not really changed. For example I don't think pinpad features are in the program. Can you list the "limitations" you would like to be listed? I think of: - min PIN size - max PIN size This is something I could add in my reader list. Thanks -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
