Subject: [urn] Request for a Namespace Registration for Unique (Vaccination) Certificate Identifier

From: Dirk-Willem van Gulik <[email-masked]>
Date: Sun, 1 Aug 2021 15:37:16 +0200

Namespace Registration for Unique (Vaccination) Certificate Identifier

Namespace ID: UVCI (requested of IANA, case insensitive)
 
     Version: 1.01

        Date: 2021-07-28

  Registrant: eHealth Network 
        
Post address: The eHealth Network,
              eHealth Network Secretariat
        p/a:  Directorate-General for Health and Food Safety
              European Commission
              1049 Bruxelles/Brussel
              Belgium

       eMail: eHEALTH-NETWORK(at)ec(dot)europa(dot)eu

Requesting entity is a network of national authorities responsible for 
eHealth established pursuant to Article 14 of Directive 2011/24/EU and 
the European Commission Implementing Decision 2019/1765. It essentially 
consists of the representatives of Ministries of Health or the equivalent 
national Public Health Authorities of the EU and EEA Member States.

Overview: 

In response to the COVID-19 Pandemic the public health authorities of 
the EU Member States collaborated on a single-purpose, cross-border, 
interoperable, digital health certificate specific to COVID-19[1]. 

This certificate takes the form of a paper or digital document, that 
may also be displayed in a mobile app. In its digital version[2] it is 
a QR code that contains Base45 encoded, Zlib compressed, digitally 
signed (COSE) structured block (CBOR) of medical and citizen 
identifying data. An out of band trust management mechanism provides 
the ECC public keys for (offline) signare validation and key revocation.

Regulation 2021/953[4] prohibits the storage or retention of data 
following verification. The exchange of Personally Identifiable 
Information is not necessary for the purposes of the Regulation. 
However in certain cases (e.g. to prevent or detect fraud) it may still 
be essential to exchange lists of revoked certificates.

For this reason the design[2] calls for a Unique (Vaccination) 
Certificate Identifier (UVCI) that uniquely identifies a specific test, 
vaccination or recovery certificate. The format chosen for this UVCI is 
that of a Universal Resource name or URN that follows the best current 
practices (BCP: 66, RFC8141). The NID selected is ‘UVCI’.

The NSS[3 annex 2] consists of a version and country/issuing entity 
prefix followed by an opaque unique string, an opaque unique string 
prefixed by a regional Issuing Entity or a triplet of entity, 
vaccination and again an opaque unique string. This latter format never 
saw any use  - and may be dropped from future versions of the standard.

When used in print it may be followed by a ‘#’ and a LUHN based 
checksum.

To further ease of reliable manual entry the character set is limited 
to A-Z and 0-9, case insensitive. Elements are separated by a slash 
within the main block; and a colon for the version and country.

It is up to each Member State to manage this space well and ensure that 
the URN as a whole stays unique. Some countries have opted for a single 
space for the whole country; others have delegated parts of the space 
to nations or regions within the member state; each with their own 
prefix or range. 

Examples are:

        urn:uvci:01:BG:UFR5PLGKU8WDSZK7#0
        urn:uvci:01:PT:SPMS/TRC01234567890123456#1
        URN:UVCI:01:PL:3/655052DD53A649E897FA10AC9C175654
        URN:UvCI:01:NL:2WC7BASRIALG5FBUHLNNNX3A42#:
        URN:UVCI:01:GB:112739138279141HSFJYRDT#R
        
The syntax of the NSS (i.e. the string past the URN prefix and NID, 
‘urn:uvci:’) is defined in [3]; and can be paraphrased as:

        VERSION ':' COUNTRY ':' C_NSS [ '#' LUHN ]

With:

        VERSION      version number. Currently set to the string '01'.

        COUNTRY      Issuing entity, in general a country. The 
                     ISO3166-1 character code must be used. Other codes
                     (3 characters, and longer, e.g. 'UNHCR' or 'WHO' 
                     are reserved for future use))

        C_NSS        Country specific/managed/delegated NNS

        LUHN         OPTIONAL checksum for print.

The country specific NSS, C_NSS is one of the following 3 formats:

1)      ALPHANUMSTR 

2)      ISSUER '/' ALPHANUMSTR  

3)      ISSUER '/' VACCINE '/' ALPHANUMSTR

With:

        ALPHANUMSTR  A string consisting of A-Z, 0-9 (case insensitive).

        ISSUER       An ALPHANUMSTR that denotes an issuer specific 
                     to the Country.

        VACCINE      An ALPHANUMSTR that denotes a vaccine or similar
                     sub grouping.

None of these strings can be empty. All are case insensitive (as they 
may be entered from a printed document). 

Appendix 1 contains a ABNF of above.

Exceptions and Legacy:

At this time there are two known deviations. 

Firstly - there are two suffixes in use; the original UVCI and a newer 
UCI. The reason for this was that during the design and first roll-outs 
the pandemic evolved; and it became clear that not just vaccination 
certificates would be issued - but also test and recovery certificates. 
So some countries started to use the more generic UCI.

However - UCI is already in use (RFC4179). So this newer UCI will need 
to be phased out; with UVCI remaining (only 1 or 2 countries appear to 
use this).

Secondly - a few countries have issued abbreviated UVCIs; which lack 
the URN:UVCI prefix. An example of this is: "01/LU/2O1I84U8U12I5#UK".

Rules for Lexical Equivalence:

The URN should be compared case-insensitive in its entirety; from (and 
including the ‘URN:’ up and until, but not including the optional ‘#’ 
and optional checksum. The optional checksum is not part  of the URN 
(or its comparison). It is however recommended when the URN is printed.

If the context allows for it - the removal of the 'urn:uvci' from the 
printed (and human entered) string is allowed. And should be restored 
prior to digital handling, comparisons and transmission (e.g. in a 
QR code).

Assignment:

Assignment of the URNs is delegated to each of the member states; who 
may delegate this within their state - e.g. to a regional health 
authority or to a nation within their state. The Secretariat of the 
eHealth Network maintains a list of contacts for each State.

Each Member State is responsible for managing this space well and 
keeping the entries overall unique (some States may have multiple 
ISO3166-1 entries; these, and the version number, are considered an 
integral part of the identifier, also for uniqueness purposes).

Security and Privacy:

This URN is classified as a piece of Personally Identifiable 
Information (it references a medical 'fact' about a person; about 
the traveler) and, for this reason subject to the regulation[4] 
and national law.

Interoperability:  

The UVCI is a unique and persistent identifier.  An UVCI, once it has 
been assigned, must never be reused.

There are no characters in UVCI which would require percent-encoding. 

Persistence of the resources: 

The UVCI pertains to a specific (medical) record about a specific 
person’s vaccination, test or recovery at event level [1,2]. This 
record is subject to national legislation and regulation.

Persistence of the identifier: 

The UVCI as an identifier is persistent in the sense that once 
assigned, an UVCI will never be reassigned. 

Resolution:  

For URN resolution purposes, all elements up to, but not including the 
'#' and checksum must be taken into account.

Persistence of the remote/public resolvers: 

At this time there are no remote or public resolvers -- the cross border
continuity of care scenario referenced in below documents has not been 
implemented at this time. No timeline (or a decision) to implement such
has been taken.

Documentation/References:  

1: COMMISSION IMPLEMENTING DECISION (EU) 2021/1073 of 28 June 2021 
   laying down technical specifications and rules for the implementation 
   of the trust framework for the EU Digital COVID Certificate established 
   by Regulation (EU) 2021/953 of the European Parliament and of the 
   Council, <http://data.europa.eu/eli/reg/2021/953/oj>

2: eHealth Network, Guidelines on Technical Specifications for EU 
   Digital COVID Certificates, Volumes 1-5, 
   <https://ec.europa.eu/health/ehealth/key_documents_en>

3: eHealth Network Guidelines on verifiable vaccination certificates - 
   basic interoperability elements, Release 2, 2021-03-12,
   <https://ec.europa.eu/health/ehealth/key_documents_en>

4: Regulation (EU) 2021/953 on a framework for the issuance, 
   verification and acceptance of interoperable COVID-19 vaccination, 
   test and recovery certificates (EU Digital COVID Certificate) to 
   facilitate free movement during the COVID-19 pandemic, 
   <https://eur-lex.europa.eu/eli/reg/2021/953/oj>

Additional Information:  

    See: https://ec.europa.eu/health/ehealth/key_documents_en

Revision Information:  

    Version 1.00 -- This registration is based on the 2021/1073 of 
                    28 June 2021 implementing decision. (2021/07/20)

    Version 1.01 -- Add legacy/exception example (LU), several typos
                    Fixed, URLs added (2021/07/28).

Appendix 1 - RFC5234 Augmented BNF of the URN

This is a non-normative ABNF derived from [2,3]. The definitions for 
ALPHA and DIGIT are from RFC5234. The NID or NSS are conform RFC8141.

       URN = "URN" URN_SEP NID URN_SEP NSS

       NID = "UVCI"; note that an ABNF string is case _in_ sensitive.

       NSS =  VERSION NSS_SEP COUNTRY NSS_SEP C_NSS [ CRC_SEP LUHN ]

   VERSION = 2*DIGIT  ; only the value "01" is defined at this time.

   COUNTRY = 2*ALPHA [ *ALPHA ] ; only 2 char from ISO 3166-1 defined 
                                ; at this time.

     C_NSS = OPTION1 / OPTION2 / OPTION 3

   OPTION1 = AZ09STR 

   OPTION2 = ISSUER CNTRY_SEP AZ09STR

   OPTION3 = ISSUER CNTRY_SEP VACCINE CNTRY_SEP AZ09STR ; not observed 
                                                        ; in active use.

   URN_SEP = ":"

   NSS_SEP = ":"

 CNTRY_SEP = "/"

   CRC_SEP = "#"

      LUHN = 1*ALPHANUM

    ISSUER = AZ09STR

   VACCINE = AZ09STR

   AZ09STR = 1*AZ09 [ *AZ09 ]; non empty arbitrary len alpha numeric 
                             ; ascii string

       AZ09 = ALPHA / DIGIT

Although commonly used software imposes a limit of around 2kByte on 
the length of a URI, implementers are advised to stay below the 60 
characters for usability reasons (they may need to be routinely entered 
from a paper travel document by hand).

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 4 Aug 2021 08:09:04 +0000

Dear Mr. van Gulik,

thank you for sending this request. I received my own certificate a couple of weeks ago, and was surprised to see an unregistered URN namespace being used in the identifier. I am glad that the request has now been sent, and that it is well written.

I accept this request, but have a comment and two questions about it.

It is unfortunate that some parties have used namespace UCI, which was registered in 2005 by Korean National Computerization Agency (NCA). The parties who have used UCI should contact NCA and make sure that their usage of UCI will not cause problems either for themselves or NCA.

Since the COVID-19 pandemic is likely to continue for some time, and the virus may never be eradicated totally, it is likely that some or all people may receive a COVID-19 vaccine booster shot or shots in the future. How will the identifier take this into account?

COVID-19 will not be the last pandemic. There will be more, and researchers will again develop vaccines against the viruses causing them. People may be required to have certificates of two or more vaccinations at the same time. The syntax presented will still work, at least if NSS contains the vaccine identifier, but is that the only way to accomplish this? And should the registration say something about this kind of future proofing?

All the best,

Juha Hakala

Lähettäjä: urn <[email-masked]> Puolesta Dirk-Willem van Gulik
Lähetetty: sunnuntai 1. elokuuta 2021 16.37
Vastaanottaja: [email-masked]
Kopio: the eHEALTH-NETWORK Secretariat <[email-masked]>
Aihe: [urn] Request for a Namespace Registration for Unique (Vaccination) Certificate Identifier

     Version: 1.01

        Date: 2021-07-28

Overview:

Examples are:

With:

1)      ALPHANUMSTR

With:

Exceptions and Legacy:

Assignment:

Security and Privacy:

Interoperability:

Resolution:

Additional Information:

Revision Information:

   OPTION1 = AZ09STR

   URN_SEP = ":"

   NSS_SEP = ":"

 CNTRY_SEP = "/"

   CRC_SEP = "#"

      LUHN = 1*ALPHANUM

    ISSUER = AZ09STR

   VACCINE = AZ09STR

       AZ09 = ALPHA / DIGIT

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 4 Aug 2021 14:31:15 +0200

Thanks for your thoughtful reply. 

As to the UCI - we have internally been setting a process in motion (and the earlier the better - as there is quite a bow-wave of additional countries and nations that do not just want to use this standard - but also enter into the equivalency agreements) to phase out UCI. Given the limited validity ranges often involved and the fairly closed cross border setting*- I am not expecting surprises for now. 

We had not thought of your suggestion to contact the NCA - and will follow up on that forthwith.

As to your question with regard of the booster shot, additional shots (AKA known as bonus shots), the entry on the market of multi vendor shots and the increasingly complex mix of test & recovery information also being valid grounds for travel - we fully expect that the payload will need to evolve over time. It borrows enough of the medical standards and has in key places the option of an Array - that we have some room. 

Hence the versioning in both the URN and in the payload.

Limiting factors right now are the EU regulation / legal framework (that evolved in tandem; but not quite aligned with the technical standard — and as a result disallows effective array use) and the size of a Qr code (in conjunction with the absolute requirement to be able to do this off-line and with the desire for nations of having the option of having no central (or decontrol) copy the data (other than on the citizens phone, etc). The latter as quite a few countries (e.g. The Netherlands) simply do not have such; nor do they  always desire to have such a central database.

As to your final question - with regard of future proofing - I’ll pass this question on to the semantic working group of eHealth — as enough of the standard is FHIR based/inspired to make a lot possible in theory. But I personally would expect that in reality we again run into two very hard limits; the legal framework is very very narrow; just for the COVID crisis in time and scope -and- the size of a QR — more than a 5 to 10 medical facts simply do not fit. 

With kind regards,

Dw.

*: and for any Private sector use - the regulation prohibits any retention; processing or storage.

On 4 Aug 2021, at 10:09, Hakala, Juha E <[email-masked]> wrote:

> Lähettäjä: urn <[email-masked] <mailto:[email-masked]>> Puolesta Dirk-Willem van Gulik
>    Council, <http://data.europa.eu/eli/reg/2021/953/oj <http://data.europa.eu/eli/reg/2021/953/oj>>
>  
>    <https://ec.europa.eu/health/ehealth/key_documents_en <https://ec.europa.eu/health/ehealth/key_documents_en>>
>  
>    <https://ec.europa.eu/health/ehealth/key_documents_en <https://ec.europa.eu/health/ehealth/key_documents_en>>
>  
>    <https://eur-lex.europa.eu/eli/reg/2021/953/oj <https://eur-lex.europa.eu/eli/reg/2021/953/oj>>
>  
> Additional Information:  
>  
>     See: https://ec.europa.eu/health/ehealth/key_documents_en <https://ec.europa.eu/health/ehealth/key_documents_en>
>  
> Revision Information:  
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Aug 2021 17:07:12 -0600

Hallo Dirk-Willem! Thanks for submitting this registration request,
which is quite thorough. Overall this looks good. I've provided a few
comments inline.

> Namespace ID: UVCI (requested of IANA, case insensitive)

This is the version of the registration with IANA, not the version of
the documentation. Thus this should be "1" and if in the future the
registrant submits an updated registration, it should be incremented.

> the ECC public keys for (offline) signare validation and key revocation.

s/signare/signature/

> practices (BCP: 66, RFC8141). The NID selected is ‘UVCI’.

In your reply to Juha, you said:

"As to your question with regard of the booster shot, additional shots
(AKA known as bonus shots), the entry on the market of multi vendor
shots and the increasingly complex mix of test & recovery information
also being valid grounds for travel - we fully expect that the payload
will need to evolve over time. It borrows enough of the medical
standards and has in key places the option of an Array - that we have
some room."

However, the foregoing paragraph seems to indicate that a URN would
identify a test, vaccination, or recovery certificate. That could be
taken as implying one URN for each "event" (one URN for an initial shot
or set of shots, one URN for a booster, one URN for each test
administered, etc.) - that is, not one URN per person encapsulating
numerous events in an array or what have you. That also doesn't seem

> record is subject to national legislation and regulation.

Could you clarify this aspect?

Peter

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 11 Aug 2021 13:25:14 +0200

> registrant submits an updated registration, it should be incremented.

Thank you - corrected in the next version of this document.

...

>> the ECC public keys for (offline) signare validation and key revocation.

Thanks. Fixed.

>> vaccination or recovery certificate. 
...
> identify a test, vaccination, or recovery certificate. That could be
....
> Could you clarify this aspect?

You are correct - this is wrong and badly written. 

It is an identifier  for a specific assertion (e.g. this person was 
vaccinated; this  person was tested) rather than something tied to 
the person; it is inside the elements of arrays of such assertions
 about 'a' vaccination, test or recovery statement*.

We've tried to clarify this in the next version of the draft.

With kind regards,

Dw.

* Earlier versions of the design called for a 'per event' identifier; e.g. 
  one for every shot in a sequence -- but while desirable for some of the 
  business rules countries wanted to apply on inbound - this turned out 
  to be impractical given the date available in practice).

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 11 Aug 2021 13:32:37 +0200

L.S.,

Updated registration request below; with comments and suggestions received sofar all included.

With kind regards,

Dw.

 
     Version: 01

        Date: 2021-08-11

              1049 Bruxelles/Brussels
              Belgium

consists of the representatives of Ministries of Health or equivalent 

Overview: 

the ECC public keys for (offline) signature validation and key 
revocation.

For this reason the design[2] calls for a Unique (Vaccination) 
Certificate Identifier (UVCI) that uniquely identifies a, specific 
test, vaccination or recovery certificate assertion by the issuing 
authority.  The format chosen for this UVCI is that of a Universal 
Resource name or URN that follows the best current practices (BCP: 66, 
RFC8141). The NID selected is ‘UVCI’.

Examples are:

With:

1)      ALPHANUMSTR 

With:

Exceptions and Legacy:

prior to digital handling, comparisons and transmission (e.g. in a QR 
code).

Assignment:

Security and Privacy:

This URN is classified as a piece of Personally Identifiable 
Information (it references a medical 'fact' about a person; about the 
traveler) and, for this reason subject to the regulation[4] and 
national law.

Interoperability:  

The UVCI pertains to an set of (historic, mostly medical) assertions,
e.g. this person had 2 shots of Vaccine X or a Test by manufacturer
Y on a certain date and under the governance of a certain body[1,2].

It is NOT a persistent identifier of a persons entire vaccination 
record or the citizens medical record. Instead it is a unique identifier 
for the data contained in the record; and the link to the provenance
of that data as under the governance of the issuer.

These records are  subject to national legislation and regulation.

Resolution:  

At this time there are no remote or public resolvers -- the cross 
border continuity of care scenario referenced in below documents has 
not been implemented at this time. No time line (or a decision) to 
implement such has been taken.

1: COMMISSION IMPLEMENTING DECISION (EU) 2021/1073 of 28 June 2021 
   laying down technical specifications and rules for the 
   implementation of the trust framework for the EU Digital COVID 
   Certificate established by Regulation (EU) 2021/953 of the 
   European Parliament and of the Council, 
   <http://data.europa.eu/eli/reg/2021/953/oj>

Additional Information:  

Revision Information:

    1.00 -- This registration is based on the 2021/1073 of 
            28 June 2021 implementing decision. (2021/07/20)

    1.01 -- Add legacy/exception example (LU), several typos
            Fixed, URLs added (2021/07/28).

    1.02 -- Fix version (of the URN, not this document), correct
            typo, clarify that UVCIs are for single assertions
            at a specific time; not tied to a state of a citizen.

   OPTION1 = AZ09STR 

   URN_SEP = ":"

   NSS_SEP = ":"

 CNTRY_SEP = "/"

   CRC_SEP = "#"

      LUHN = 1*ALPHANUM

    ISSUER = AZ09STR

   VACCINE = AZ09STR

       AZ09 = ALPHA / DIGIT

Although commonly used software imposes a limit of around 2kByte on the 
length of a URI, implementers are advised to stay below the 60 
characters for usability reasons (they may need to be routinely entered 
from a paper travel document by hand).

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Aug 2021 11:41:21 -0600

> We've tried to clarify this in the next version of the draft.

Thanks for the clarifications.

As I understand it, the URN identifies a vaccination event, a test
event, or a recovery event. The URN itself does not associate the
assertion with a particular person (there is no "person" construct built
into the URN). For instance, if I get a test, that test is assigned a
URN. If I receive documentation (physical or digital) of the URN that's
been assigned and I present such documentation, the assocation comes
from the fact that I'm the one presenting the documentation. Some other
system (say, a medical records system) could formally associate that URN
with some other identifier for me as a person within a given nation or
region, but that kind of association is out of scope for the URN definition.

If this is correct, I think we could slightly adjust the wording to make
it fully clear.

Peter

---

From: Ed Guy <[email-masked]>
Date: Wed, 11 Aug 2021 17:57:44 +0000

Dirk,

    >>> record is subject to national legislation and regulation.

#Pedantic mode on

While you're updating this section, you probably should include the broader term

'immunization' although in the last year the terms have become nearly interchangeable.

/ed

On 8/11/21, 1:41 PM, "urn on behalf of Peter Saint-Andre" <[email-masked] on behalf of [email-masked]> wrote:

    it fully clear.

    Peter

    _______________________________________________

    urn mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/urn

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 12 Aug 2021 10:18:47 +0200

> 'immunization' although in the last year the terms have become nearly interchangeable.

Grin :) danger territory here :). I'll check with the medical expert - but suspect that given that the URN defines a fact about what happend (the application of a product (vaccine) that stimulates the immune system to produce immunity to a specific disease,

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 12 Aug 2021 10:19:55 +0200

>> 'immunization' although in the last year the terms have become nearly interchangeable.
Grin :) danger territory here :). 

I will check with the medical experts - but suspect that given that the URN defines a fact about what happend (the application of a product (vaccine) that stimulates the immune system to produce immunity to a specific disease - rather than knowing that that person was succesfully immunized; I am guessing that the 'V' will be the preferred term in this context.

With kind regards,

Dw.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 12 Aug 2021 10:28:09 +0200

> from the fact that I'm the one presenting the documentation. Some other

Yes - -and- the fact that outside the data element(s)_ that the URN uniquely identifiers - there is some PII (name, DoB, but no things such as passport numbers) that is signed by the digital signature that is part of the QR.

So the structure is

      some meta data for the signature, version, etc
      . SIGNATURE over:
	... some issuance/expry(medical)/authority data
        ...... data about the bearer (DoB, Name, Transliterated name in ASCII)
        .... vaccination section
        ...... array of elements
        ......... vaccine used, brand, batch number, medical institution, # of doses, date, etc.
        ......... URN for just this element.
	....  test section
        ...... array of elements
        ......... est used, brand, medical institution, date, etc.
        ......... URN for just this element.
	....  recovery section
        ...... array of elements
        ......... medical institution, date, etc.
        ......... URN for just this element.
So indeed there is no URN for the person - nor is there one for this aggregation of elements. That said - at _this_ time - the only structure issued/permitted by the regulation is that of a SINGLE element with a Single section (Test Or Recovery Or Vaccination).

So it is easy to conceptional associate  or confuse the URN present within the structure with the entire record. 

> If this is correct, I think we could slightly adjust the wording to make

We'll try to update and will sent a version 3 once we have also done the other comments.

With kind regards,

Dw.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Aug 2021 10:12:55 +0100

On Wed, Aug 11, 2021 at 6:41 PM Peter Saint-Andre <[email-masked]>
wrote:

> event, or a recovery event.

I'm not entirely sure where to insert this comment, so this placement may
not be ideal, but I hope it makes some sense.

In my layman's understanding, test events fall into two broad classes:
tests which indicate the presence of active disease (viral) and tests which
indicate antibody presence (serological).  It may be useful to separate
those into two different classes in the URN, because there will likely be
future situations where the chain of tests include antibody presence tests
after vaccine or recovery events.  Having a series of events that include
viral tests, vaccination and then serological tests (to indicate or
contraindicate the need for a booster) could become common.  Being able to
distinguish those events from viral tests quickly and simply might be
useful.

My apologies if this is already covered; I didn't see that distinction made
in the template or later discussion.

regards,

Ted Hardie

> The URN itself does not associate the

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 23 Aug 2021 22:09:18 -0400

The proposal looks fine to me.  I see that others have noted some
editorial corrections/improvements.  I do want to emphasize:

> vaccination or recovery certificate.

UVCI URNs are essentially serial numbers for certificates, which
conveniently avoids them containing any particularly sensitive
information, as long as they are constructed properly.

And since the format contains a version number, the system can be
redesigned to accommodate new requirements.

Dale

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Tue, 24 Aug 2021 12:18:29 +0200

> redesigned to accommodate new requirements.

That is correct. WIth the addition that, given that most countries operate under the GDPR or similar, the actual 'serial number' is typically not sequential nor a derivative of some other citizen/health-care identifier; but typically generated randomly to preserve privacy. 

I am using the word typically here - as while the technical standard and the GDPR calls for this - ultimately sovereign states have the last call. And with many countries outside the EU either going through the legal equivalency process or just technically building it as they see fit - it is hard to be definitive.  I.e. while countries that join the trust-framework need to have an equivalency decision on record; there is nothing stoping a country to build a system against these technical standards (that is fully interoperable) outside the trust framework without such safeguards; nor stopping countries to bi-laterally decide to recognises each others trust anchors.

With kind regards,

Dw