The PC/SC workgroup, November 2011 meeting is now over. The meeting minutes are available to PC/SC members. But this document is not public.
Here are the results about issues I reported for the meeting.
The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
The application uses
This proposal has been accepted.
The documents will be available as Word files in the member only area of the web site. Changes will be available as track changes.
No good news for non PC/SC workgroup members. You will have to compare two versions of the specification by hand (as before).
This is outside the scope of the PC/SC workgroup.
A subcommittee will be created to work on the question.
The other requests have been discussed but rejected. It is not really surprising since the proposals were not described in details. For example the code returned by PC/SC when a command is refused by a firewalled pinpad may be accepted at a later meeting if correctly presented and described.
Here are the results about issues I reported for the meeting.
Extended APDU support reported by PC/SC
See the previous article Extended APDU support reported by PC/SC. The idea to for an application to be able to know if a reader+driver do support extended APDU.The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
- The application uses
SCardControl(FEATURE_GET_TLV_PROPERTIES, ...)and look for the tagdwMaxAPDUDataSize. - The value of
dwMaxAPDUDataSizegives the maximum APDU data size supported by the reader+driver.
Identifying a reader model
See the previous article Identifying a reader model. The idea is to be able to precisely identify a reader model before sending (potentially dangerous)SCardControl() commands.The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
The application uses
SCardControl(FEATURE_GET_TLV_PROPERTIES, ...) and look for the tags PCSCv2_PART10_PROPERTY_idVendor and PCSCv2_PART10_PROPERTY_idProduct. These are the USB vendor ID and product ID of the device.This proposal has been accepted.
Changes in PC/SC workgroup documents
Request: The PC/SC workgroup specifications contain a "Revision History" section with a brief description of the changes. It would be even better to have all the changes directly visible within the document.The documents will be available as Word files in the member only area of the web site. Changes will be available as track changes.
No good news for non PC/SC workgroup members. You will have to compare two versions of the specification by hand (as before).
Firewalled pinpad
Request: The PC/SC workgroup should define the status word (SW1 and SW2) to be reported by the reader if a command is rejected by the firewall.This is outside the scope of the PC/SC workgroup.
FEATURE_WRITE_DISPLAY, FEATURE_GET_KEY and FEATURE_VERIFY_PIN_START
Request: Document how FEATURE_WRITE_DISPLAY, FEATURE_GET_KEY and FEATURE_VERIFY_PIN_START should or could be implemented at the CCID level.A subcommittee will be created to work on the question.
Unblock PIN feature and PIN merge feature
This is outside the scope of the PC/SC workgroup. You should contact the manufacturer if the reader is not working as expected.Conclusion
My two main issues have been accepted.The other requests have been discussed but rejected. It is not really surprising since the proposals were not described in details. For example the code returned by PC/SC when a command is refused by a firewalled pinpad may be accepted at a later meeting if correctly presented and described.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon