Policy on new card driver based on reverse engineering

Hi,

To start with, I apologize for any etiquette or usage issues here on
the mailing list on my behalf - I think I've only ever used a mailing
list once before.

I've got a question in regards to implementing a new driver for a card
that's currently unsupported by OpenSC, but one that I have a
proprietary PKCS#11 module for. I don't have the source code, nor any
technical documentation that would describe the workings of the
driver, but using the module I can successfully interact with the card
using pkcs11-tool.

The card in question is a Gemalto Instant EID IP10, a card commonly
used by Swedish authorities (including the military) and as a
bank-issued electronic identification card. It's a JavaCard v2-based
platform, with Gemalto's IDPrime applet (as far as googling has told
me, anyway). I'm quite new to the world of smartcards, but it would be
a great help if this card had support in OpenSC. BankID has become the
de facto standard for electronic identification here in Sweden, and
I'd be very helped at my workplace if the card was supported.

What is the OpenSC policy on reverse engineering a new driver from a
proprietary module, either by decompiling the binary itself, or by
sniffing the traffic between the driver and the card? I'd be up for
implementing it myself or providing as much assistance as I can,
provided I get some guidance on how to actually do that - I've got
access to both a compatible reader, a set of IP10 cards (which I
bought because I thought they were of a different model, go me), as
well as the PKCS#11 module that talks to them.

The module can be downloaded freely from Secmaker, the company behind
a fair bit of the technology involved, as "Net iD Access" for Linux,
Mac, Windows, iOS, and Android at
https://service.secmaker.com/access/apps.aspx.

Thanks!