Re: The XML-file of an eID card with special status "WHITE_CANE" can be written by the eID viewer, but cannot be read by that same viewer

[Frank Marien]

Jan,

It's what I would call an "attempted bit field" represented as a string.

The XML represents the value from the card, in this case, which is

"0" no special status
"1" white cane (this citizen is blind)
"2" extended minority (this citizen is considered to be a minor regardless of their age)
"3" both "1" and "2" (blind person that is also a minor regardless of age)
"4" yellow cane (this citizen has bad eyesight - but is not blind)
"5" both "2" and "4" (person with bad eyesight that is also a minor regardless of age)

See

http://code.google.com/p/eid-applet/source/browse/trunk/eid-applet-service/src/main/java/be/fedict/eid/applet/service/SpecialStatus.java#31

WKR,
Frank.

On 09/21/2012 10:14 AM, Jan Vandenbussche wrote:

User the eID viewer that comes with the middleware version 4.

The steps to reproduce I used:

1. Read a physical eID card with the viewer.
2. Write to XML.
3. Change the XML manually by adding the identity attribute specialstatus="WHITE_CANE".
4. Open the XML file with the eID card viewer.
5. Write to XML. 
   => This identity attribute has been added: specialstatus="whitecane".
   => Trying to open the XML file with the eID card viewer does not work.

I encountered this problem while trying to write a program that can produce exactly the same XML as the eID viewer that comes with the middleware version 4.

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'eID Middleware' van Google Discussiegroepen.
Ga naar https://groups.google.com/d/msg/eid-mw/-/mf_pFepswdMJ om deze discussie op het internet te bekijken.
Als je een bericht in deze groep wilt plaatsen, stuur je een e-mail naar eid...@googlegroups.com.
Als je je wilt afmelden voor deze groep, stuur je een e-mail naar eid-mw+...@googlegroups.com.
Bezoek deze groep op http://groups.google.com/group/eid-mw?hl=nl voor meer opties.

[Jan Vandenbussche]

Frank,

What is the correct XML representation of an eID card of a citizen with a white cane?

The eID viewer outputs the identity attribute specialstatus="whitecane", but it cannot read back its own output. It only accepts as input the identity attribute specialstatus="WHITE_CANE".

This seems to be a bug in the eID viewer, doesn't it? Which leaves us unable to create a program that outputs exactly the same XML as the eID viewer would, while making sure the XML can be read by the eID viewer.

Regards,

Jan

Op vrijdag 21 september 2012 10:57:11 UTC+2 schreef Frank Marien het volgende:

[Frank Marien]

Jan,

<blushes> You are so right.. The viewer loads using SpecialStatus.valueOf() which accepts the enum constants

NO_STATUS
WHITE_CANE
EXTENDED_MINORITY
WHITE_CANE_EXTENDED_MINORITY
YELLOW_CANE
YELLOW_CANE_EXTENDED_MINORITY

.. but writes it as a comma-separated list of

whitecane
yellowcane
extendedminority

which it cannot read..

I appartently introduced the easier-to-parse list but did not make it consistent.. My apologies. I'll fix this, and I'll let you know when and where to get the continuously-built version. It'll also make it into the upcoming 4.1 release, then.

But this does not have to block your development: the viewers currently in the field correctly read the enum constants from SpecialStatus, so you can write those there, as in

http://code.google.com/p/eid-applet/source/browse/trunk/eid-applet-service/src/main/java/be/fedict/eid/applet/service/SpecialStatus.java#31

NO_STATUS
WHITE_CANE
EXTENDED_MINORITY
WHITE_CANE_EXTENDED_MINORITY
YELLOW_CANE
YELLOW_CANE_EXTENDED_MINORITY

What I'll do is change the XML output to use the same enum constants instead of the comma-separated list.

If we do it like that, your code will immediately work with current viewers as well as the fixed ones.

Ok for you?

-f

[Jan Vandenbussche]

Ok, no problem, thank you.

What else can we expect in the 4.1 release?

Regards,

Jan

2012/9/24 Frank Marien <fr...@apsu.be>

[Frank Marien]

Jan,

Generally, 4.1 is mostly about installation and installers, who get a profound makeover.
As for the crypto module ("middleware") and viewer, it's just a maintenance & fixes release.

Serious feature changes there will be for 2013 (but no date yet). You may want to follow those here,
since we intend to build an entirely new viewer based on commons-eid instead of eid-applet.

-f

[Frank Marien]

Jan,

Could you please try with

http://eidfiles.be/continuous/viewer/eid-viewer-4.0.4-153-win32.exe

change is:

http://code.google.com/p/eid-viewer/source/diff?spec=svn153&r=153&format=side&path=/trunk/eid-viewer-lib/src/main/java/be/fedict/eidviewer/lib/file/Version4XMLFileIdentity.java

.. and let me know.. 

What I may do is lowercase the enum names when writing, since the rest of the XML is lowercase, also. But then I'll convert files read to uppercase before calling the valueOf(), so that case doesn't matter for your code. Please keep writing uppercase for now, since all existing viewers in the field will accept this.

-f

On 09/24/2012 10:15 AM, Jan Vandenbussche wrote:

[Frank Marien]

On 09/24/2012 01:25 PM, Frank Marien wrote:
> But then I'll convert files read to uppercase

I mean "that attribute" not "files" which is meaningless in that context..

[Jan Vandenbussche]

Frank,

Why did you change the code so that the specialstatus attribute is always set, even if the specialstatus is NO_STATUS? I feel this change is not necessary to fix the bug.

Otherwise, the bug cannot be reproduced with the originally posted steps:

Read a physical eID card with the viewer.
Write to XML.
Change the XML manually by adding the identity attribute specialstatus="WHITE_CANE".
Open the XML file with the eID card viewer.

1. Write to XML.   
   => This identity attribute has been added: specialstatus="WHITE_CANE".
   => Trying to open the XML file with the eID card viewer does work.

Opening an XML file that was previously written by an unfixed version of the eID viewer still does not work, but that does not matter for our use case.

On the side: The dependency on eid-applet instead of eid-common did strike me as odd while browsing through the code of the eID viewer.

Regards,

Jan

[Frank Marien]

On 09/24/2012 02:25 PM, Jan Vandenbussche wrote:

Frank,

Why did you change the code so that the specialstatus attribute is always set, even if the specialstatus is NO_STATUS? I feel this change is not necessary to fix the bug.

It makes the code "as simple as possible" :-)

I'll could treat the absence of the the attribute as NO_STATUS and not write the attribute if there is no status.. You're
right that this would be cleaner from an XML perspective.. specialstatus is supposed to be optional after all..

But this does not affect you, right now, I think: the viewer will treat a missing specialstatus as NO_STATUS, so you
can still do this, if you like.

Otherwise, the bug cannot be reproduced with the originally posted steps:

Read a physical eID card with the viewer.
Write to XML.
Change the XML manually by adding the identity attribute specialstatus="WHITE_CANE".
Open the XML file with the eID card viewer.
1. Write to XML.   
   => This identity attribute has been added: specialstatus="WHITE_CANE".
   => Trying to open the XML file with the eID card viewer does work.

Opening an XML file that was previously written by an unfixed version of the eID viewer still does not work, but that does not matter for our use case.

No, I was just attempting to unblock you, the fix will not be public until 4.1 is released in any case.

On the side: The dependency on eid-applet instead of eid-common did strike me as odd while browsing through the code of the eID viewer.

commons-eid did not exist at the time.. I used eid-applet-core and and eid-applet-service because that was mature code,
and I did not want to reinvent the wheel. But that code is really too applet-specific and I've had to "stretch" my use of it in some places,
wrap it, trick it, etc.. where the applet way of working is at odds with what I wanted to do in an application..

This is one of the reasons why Frank C. started commons-eid,

http://code.google.com/p/commons-eid/source/browse/

.. to become a basis for java-based eid-related software:
We intend to base both the future applet and the future viewer on it, and we're experimenting with presenting it as a set of web
services, even.