Re: [eid-mw-dev] How to read an .eid file (TLV format) with the new middleware

[Frederik Vernelen]

Hello Kevin,

In the eID SDK 4.0 we do no longer include document parsers, as there are many of those available by third parties.
If an approriate TLV parser cannot be found for C#, perhaps a solution could be to translate the .eid files into xml files (use the SDK 3.5, or manually using the eID Viewer) ?

Wkr,
 Frederik

On Thu, Jul 5, 2012 at 12:16 PM, Kevin Smet <kevi...@gmail.com> wrote:

In the past you could save the data that's on the eid card to an .eid file (that's an TLV format).

Then in C# you just had to type:

BEID_ReaderContext rc = new BEID_ReaderContext(BEID_FileType.BEID_FILETYPE_TLV, path);

and you could proceed with reading the data from that .eid file.

How can we read the data from that file now? Because we saved a lot of .eid files from our customers, but we can not process them anymore with our software.

Thanks,

Kevin

[Frank Marien]

Kevin, Frederik,

I also favour this solution. For example, in the eid-viewer 4.x.x series, we only save in XML because the other formats (TLV, CSV) have dramatically less support in libraries and tools, these days, while XML parsers are now a dozen a dime, giving developers a lot more options, and marshalling from and to files can be done declaratively. Most developers I talked to so far preferred their own choices in solutions to how to store things in files, to having a build-in implementation..

How many would you have to convert? If there are e.g. >50 I would strongly suggest you write a quick converter, rather than use the eid-viewer for this. This gives you the advantage of
1) less drudge work, 2) having exercised the marshalling method you will later use to read those files.

WKR
Frank.

[Jan Vandenbussche]

Is there an XSD available for the XML files in the middleware version 4 format?

As I understand, we have to parse and build the XML files ourselves in C#. A formal description of the format would be nice (other than the Java source code of the EId-viewer).

Op donderdag 13 september 2012 schreef Jan Vandenbussche (jan.vand...@gmail.com) het volgende:

Op donderdag 5 juli 2012 12:16:37 UTC+2 schreef Kevin Smet het volgende:

[Jan Vandenbussche]

Frederik, Frank,

 

I extracted my own XSD using visual studio: see attachment. Would this XSD be correct?

 

Regards,

Jan

Op donderdag 13 september 2012 15:18:01 UTC+2 schreef Jan Vandenbussche het volgende:

[Frank Marien]

Jan,

Thank you for contributing!

The main reason why there is no official schema is that we want to have the URL that this is published at actually respond and return the definition, so for it to be active and useful, not just a unique id. This is subject to some discussion as to what the appropriate way to host this would be in a goverment context. Also, there are many
types of card, and we're not sure if the best course of action would be to attempt to capture their differences, formally (a pretty complex XSD), or keep it simple and advise everyone to account for the differences in their code (as below). The eid/card/documenttype may well become the key to those differences, and may have to move to become eid/documenttype, or be replicated there for backward compatibilty. Hence the delay.

That being said, about your XSD:

I wouldn't interpret nationalnumber, dateofbirth, cardnumber, validitydatebegin, validitydateend and zip as numbers:

They're formatted strings, and some may have leading zeroes.

For example, for someone born between 2000 and 2009, nationalnumber will have one or 2 leading zeroes. Date of birth may contain just a year (when dob is unknown - this is rendered as YYYY0101 for now but that may change).. Chip en Card-numbers may change length and suddenly become too long for the chosen binary format, and e.g. Card numbers may contain letters (one type starts with "B"). I would say none of the elements can safely be interpreted as numeric. Perhaps zip code, but that is so short as to present very little to gain, *and* who knows what the postal services will do in the future.

Please interpret them all as xs:string for XML purposes.

Then, I would not use xs:sequence since that implies order, and there is no guarantee of element ordering. While this happens to be stable using the currently used technologies, this is by no means certain in the future, please don't count on it.

As for presence: Please take a look at the annotations in the classes at:

http://code.google.com/p/eid-viewer/source/browse/trunk/eid-viewer-lib/src/main/java/be/fedict/eidviewer/lib/file/

Version4XMLFile*

Notice the optional fields. We're thinking about making "firstname" optional as well, as some people turn out not to have one (!), and it's cleaner not to have the field than to make it empty, IMHO.

Not all 5 certificates are present on all cards. For example, some have no signing cert, some have no signing and no auth cert, we've tested with such cards, and other combinations may occur in the future.

So: Interpret as string, don't count on order, don't count on presence (see sources)

I would say: If you can, don't formally validate the XML for now, parse and then see which elements you have, and keep an eye on this list, we'll announce the formal XSD with it's there, and your work helps, thanks!

If you have to formally validate the XML now, please take my comments above into account.. We'll try to not break the XSD taken from yours + my remarks, but we cannot guarantee that.

WKR,
-f

[Jan Vandenbussche]

Frank,

Thank you for the feedback.

Our goal is not to formally validate the XML files that are produced by the e-ID viewer that is included with the version 4 middleware. We are aiming to produce XML files that are identical to those produced by the e-ID viewer. As we are working in .Net it looks like we will have to base our code on the Java code of the e-ID viewer instead of on a description of the format, or won't we?

The XSD is used to generate the .Net classes that we fill up with the data retrieved from the e-ID card through the middleware and then serialize to XML.

Regards,

Jan

Op woensdag 19 september 2012 11:36:27 UTC+2 schreef Frank Marien het volgende:

[Jan Vandenbussche]

Frank,

I updated the XSD using your feedback, see in attachment:

1. everything is xs:string
2. no xs:sequence is used
3. every field has been marked as either optional or required based on the Java source files

Regards,

Jan

Op woensdag 19 september 2012 14:32:34 UTC+2 schreef Jan Vandenbussche het volgende: