> 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.
> 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.
> - Define policy for ACL (see freedesktop Bugzilla)
root,root 0600 is fine with me. distributions could create some system account,
and use that system account for such usb devices and run pcscd and openct
under these accounts (if that works, not 100% sure here - never tried).
> - 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.
> - 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?
> - 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.
> 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, I doubt
many people are interested in filling out the details. also some readers
support several form factor (eutron gave me a two in one reader, one
for sim size and one in credit card size).
> 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"? :)
also we have no events for "card inserted" or "card removed",
so unless there is some application that blocks the reader and monitors
it (and thus makes it unavailable for everything else), we can't monitor
this information.
> Form factor is specified in ISO 7810. ISO 7816 specifies chip.
> And it is a property of slot, not the reader (I can imagine a reader
> with one SIM and one card slot).
hmm, ok. so lets keep it simple?
btw, is there some central site where policies like this will be kept and
published? hald source / freedesktop / somewhere else?
> So, it will be again presented to USB as one device? And CCID will
> present contact and contactless chip similarly as two slots?
the two device I have are both not ccid I think. you need extra protocols
etc. to talk to wireless readers. (librfid is the software, openct needs
(or needed?) to be patched, the readers I have are the openpcd reader
and some omnikey reader).
> I guess, that ISO 7816 covers this as well. I was able to re-insert my
> mobile phone SIM card to the plastic I purchased it with and then insert
> to smart card reader. pcscd is capable to talk with that card, opensc is
> not.
wireless readers isiso 14443 A/B and other protocolls like mifare, as far as I
remember.
> We just should be ready to future extensions.
good idea. maybe start small and put people interested in discussing
extensions into a comment of the spec?
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
