Luhn mod N algorithm for checksum in UVCI #38
Comments
|
I guess that tthe |
|
More than that: in medical data, different delimiters are used as standard: ' ^ ' and ' | ' being the most standard and most common. These need to be included. Codepoints should indeed be defined for Luhn-mod-N and I think the charset description is an attempt at that.
eHN Vacc Interop spec, Annex 2:
(Note that the example given in #15 (comment) does NOT conform to the issued guidelines in Annex 2 as the example uses ' : ' explicilty as the field separator and is also in the regex pattern, but the eHN guidelines explicitly state that '/' is the separator) |
I don't understand how we ever will achieve interoperability if the specifications aren't clear and consise. So you mean that we shouldn't use what stated in annex 2?
No. Option 2 states: " But it doesn't explicitly state that '/' should be used as a delimitter.
Actually, what option 1 and 3 says is that '/' should be used as a delimitter for the blocks: issuing entity, (vaccine) and opaque unique string. It doesn't specify the delimitter for version and country. So. The spec needs to be updated. |
|
(Note that the example given in #15 (comment) <#15 (comment)> does NOT conform to the issued guidelines in Annex 2 as the example uses ' : ' explicilty as the field separator and is also in the regex pattern, but the eHN guidelines explicitly state that '/' is the separator)
Ok - so my _intention_ was that the colons would separate between the colours in a URI fashion. And within the colours (i.e. green) we'd use a URI path spec separator. To stay close to the spirit of the URI definition. So
01:AR:<opaque with / as needed>
what exactly do we need to change in the document to fix this ? As I read it as pertaining to the green bits (which was what we intended).
|
Annex 2 explicitly excludes it - as you quote:
|
|
Yes. No other characters are allowed in the actual opaque string. But there is nothing to delimit in opaque string. |
|
|
The opaque unique string should consist of alphanumeric characters exclusively; no other characters (e.g. “/”) are allowed."
But it doesn't explicitly state that '/' should be used as a delimitter.
Ok - so we need to clarify that this refers to the opaque string. (That is how it is intended, and that is how I read it).
Annex 2 explicitly excludes it - as you quote:
no other characters (e.g. “/”) are allowed
Right - so we need to clarify that this refers to the green section. (That is how it is intended, and that is how I read it - but it is clearly not clear enough).
Will you make a pass ?
|
|
On 29 Apr 2021, at 09:35, Gaby Whitehead ***@***.***> wrote:
what exactly do we need to change in the document to fix this ?
fully-defined codepoint set for UVCI
would be good to have a clear choice for Option 1 or 2 or 3. From internal discussions, SemanticSG had a preference for Option 3.
re-issue either a corrigenda or new doc - I suspect corrigenda? But I'll leave that to the process people to decide
I'd go back to the original version which was stripped. That had exact code points and a whole lot more detail in it.
|
Indeed, those are missing in the doc but present in example #15
Agree. |
|
@dirkx Could you post an example of how a dutch ID would look like (including the Luhn control char)? |
|
some cert examples in: https://github.com/ehn-digital-green-development/ehn-dgc-schema/tree/main/examples |
|
Will close this one as we now just need the charset defined for Luhn-Mod-N, as per #45 |
Annex 2 in the eHN Vacc Interop spec specifies that the UCVI should have a checksum suffix according to the Luhn mod N-algorithm.
However, for interoperability, we need to be clear of the order of the allowed character set (A-Z 0-9 and '/', '#' and ':'). Each character needs to have code-point, and the spec isn't clear here. Should we read the following text:
and understand that the order should be:
ABCDEF....XYZ0123456789/#:Or should use Ascii-ordering?
The text was updated successfully, but these errors were encountered: