Hi Merlin, On Thu, Feb 04, 2021 at 03:00:53PM +0100, merlin.chlosta+simtrace(a)rub.de wrote: Great to hear, and thanks for sharing your experience. This has been raised before, but unfortunately nobody has yet contributed in that area. See https://osmocom.org/issues/3886 from two years ago. The initial design idea was to not interfere on a protocol layer with the cards, to make sure it will work for any type of smart card, not just SIM cards (EF.IMSI) or ETSI UICC compliant cards (EF.ICCID). However, I do see the usability improvements to have ICCID and/or IMSI available. It should be possible to make this completly optional, so you could enable it if you wanted, or disable it if you have a non-SIM/UICC use case. It should be implemented with the following approach: * remsim-bankd reads EF.ICCD and/or EF.IMSI at start-up (or card insertion) from every card, before the slots are used by clients * RSPRO is extended for a new, optional "CardIdentityIndication" or the like, containing those values, reported unilaterally from remsim-bankd to remsim-server * remsim-server information model is extended to keep the last IMSI+ICCID ever received for any bankd+slot tuple * RSRES JSON extended to report IMSI+ICCID whenever it lists slots One could also think of implementing this in a generic way, i.e. not have new explicit fields for IMSI + ICCID in the ASN.1 definitions and the code base, but introduce some kind of general "named attributes" whihc remsim-bankd can pass to the remsim-server. This way it would also work for any other identifiers users might want for other types of smart cards in the future. All that would be needed is to add the generation of this new "named attribute" on the bankd side. The protocol and the server would then not have to change for any new/future attributes communicated that way. Unfortunately any mechanism requires one fundamental change to how bankd works today, see https://osmocom.org/issues/3884 - but it's also "just" some work, no big challenge there... Indeed, it should be fully integrated. unfortunately not. However, libosmosim (part of libosmocore.git) already contains everything needed in terms of C language library routines to perform the respective SELECT + READ BINARY commands on the cards. So at least that part doesn't have to be re-invented. The second step would go one step further beyond what I described above (merely exposing the information, but not making it a selector). I haven't yet thought on implication to RSRES interface. I guess the best approach there would be to make a proposal either here or in readmine as a feature request. In any case, we need to stay backwards compatible, so selection by additional keys such as IMSI or ICCID must be an optional addition. Are you referring to indicies for slots within one reader (like OCTSIM or the ACR 5-slot reader)? I haven't seen those change at all. Or are you referring to indicies for the actual readers? In that case, the recently merged https://git.osmocom.org/osmo-remsim/commit/?id=753c8aa87a2c4ad25a50230d07b1… should be of interest to you - it introduces regex matching for PCSC reader/slot names to remsim-bankd. I'm not sure what exactly you are asking here, maybe you could elaborate a bit. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)