On Feb 11, 2011, at 9:10 PM, Andre Zepezauer wrote: > On Fri, 2011-02-11 at 11:24 +0200, Martin Paljak wrote: >> On Fri, Feb 4, 2011 at 01:19, Andre Zepezauer >> <andre.zepeza...@student.uni-halle.de> wrote: >> >>> BTW: The main handle in OpenSC is 'sc_pkcs15_card_t' and not >>> 'sc_context_t'. In fact 'sc_context_t' is really unimportant. But >>> sc_pkcs15_card_t holds all the operational state the is required to make >>> things working. Have a look at VENDOR_SPECIFIC, there is only one OpenSC >>> specific field needed. >> >> This is actually a very good idea. >> sc_pkcs15_card_from_handles(hContext, hCard) -> pkcs15_card_t or NULL >> is a sensible thing to expose, in pair with >> sc_pkcs15_card_from_reader(reader_name) (used by Tokend) > > What's about sc_pkcs15_card_from_reader(sc_reader_t *reader)? Seems that > this could work for both. How that reader becomes instantiated depends > on the requirements/environment of the particular "application".
Yes, something along the lines. Hosting the wrappers inside "libopensc" would not hurt either. The idea would be to hide the libopensc internals inside libopensc and expose only sc_pkcs15_* for applications tha are only interested in PKCS#15 objects. > Additionally it could also be usable for secure messaging, when > providing custom reader implementations. [ยง] https://github.com/martinpaljak/OpenSC.tokend/blob/master/OpenSC/OpenSCToken.cpp#L222 -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
