Andreas Jellinghaus wrote: > > We need a "category" string that covers both and use it for both, > > otherwise we will have problems in defining generic rules (especially in > > case, when we know, that it is ISO 7816 device, but don't know, which > > one). > > > > Possibilities: > > iso7816 = smart_chip* > > ok, but then please name it "smart_card_reader". > the chip type depends on the card, th reader can talk to memory cards > too usualy.
Here is the last problem: How to name the main category "smart_card_reader or crypto_token"? 1) Invent a good word for it. 2) Use "smart_card_reader" and invent a different name for "the one with slot for cards". > btw, is there some central site where policies like this will be kept and > published? hald source / freedesktop / somewhere else? AFAIK only FDI files of HAL package itself and http://people.freedesktop.org/~david/hal-spec/hal-spec.html HAL has often surprising results: Several totally different USB devices use the same USB ID: GPS/scanner, MP3 player/Memory stick. > > iso7811 = magnetic_stripe* (serial protocol, probably no connection with > > smart_chip* devices). > > iso7810 = identification* (we probably don't need this vague category) > > I have no clue about them. ISO 7811: defines magnetic stripes. Most readers are serial character devices sending characters from the stripe directly. ISO 7810: Mechanical definition of both magnetic and chip cards. I have no clue about them as well, but our POS team could have several such readers. > > - What type of device is it (smart card reader, smart token) > > Possible proposal: capabilities = { 'smart_token', 'smart_card_reader' } > I never read "smart_token" before. so my suggestions are smart_card_reader > or usb_crypto_token - the later is a name I invented I guess, but it works > quite well and emphasises the difference to usb (memory) sticks. I am OK with usb_crypto_token or crypto_token (usb is part of the path). > > - Optionally (for openct package), a keyword, that will be used for > > calling hald-openct-addon (HAL specification proposes separating of > > information and policy, so one of possible implementation would be > > adding a keyword in information phase and calling addon in policy > > phase. Another solution is all-in-one - call addon for selected USB > > IDs.) > "driver:openct" and "driver:ccid" (or "driver:libccid" or "driver:pcscd"?) > would be fine with me. also it gives the reader a clue what the keyword > is about. is ":" legal in such names? Keys in HAL use dot convention. To prevent naming clash, we need to prepend either category name or any other unique string. For example kernel uses "info.linux.driver", X11 uses "input.x11_driver". > > - Optionally PC/SC driver > > Possible proposal: info.pcsc.driver = 'ccid' (istring) > hmm, we should find a concept so openct can have a driver coded in there too, > so we can remove internal / config file databases with driver maps. info.pcsc.* info.openct.* would never conflict. > > For slot: > > - Form factor > > Possible proposal: smart_chip.reader.form_factor = 'ID-00' (string) > not really important, maybe skip this? at least make it optional, Surely optional. > (eutron gave me a two in one reader, one > for sim size and one in credit card size). Two slots or one slots with two sizes? > > For cards and token chips: > I see no reason to put every info we somewhere have into hald. > sure, we could. but what happened to "keep it simple"? :) There is no need for it. You can understand it: "Once in future, you may define card info here." This is our starting point: No changes in pcscd or openct. When it will work in _may_ be used there. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
