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

Dirk-Willem van Gulik <dirkx@webweaving.org> Thu, 12 August 2021 08:29 UTC

Return-Path: <dirkx@webweaving.org>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D5E3A3C94 for <urn@ietfa.amsl.com>; Thu, 12 Aug 2021 01:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfSMK4gVCqT for <urn@ietfa.amsl.com>; Thu, 12 Aug 2021 01:29:40 -0700 (PDT)
Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E193A3C91 for <urn@ietf.org>; Thu, 12 Aug 2021 01:29:39 -0700 (PDT)
Received: from smtpclient.apple (94-210-134-94.cable.dynamic.v4.ziggo.nl [94.210.134.94]) (authenticated bits=0) by weser.webweaving.org (8.16.1/8.16.1) with ESMTPSA id 17C8SGcw043551 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Aug 2021 10:28:16 +0200 (CEST) (envelope-from dirkx@webweaving.org)
X-Authentication-Warning: weser.webweaving.org: Host 94-210-134-94.cable.dynamic.v4.ziggo.nl [94.210.134.94] claimed to be smtpclient.apple
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Message-Id: <5FDA06EB-3EE2-407B-962C-8032820081D1@webweaving.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6B2EA5D-6F59-4EA4-BB8D-E61588B2C1B9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 12 Aug 2021 10:28:09 +0200
In-Reply-To: <7cd1750c-0c5f-42b8-6608-9287d594079f@mozilla.com>
Cc: urn@ietf.org, the eHEALTH-NETWORK Secretariat <eHEALTH-NETWORK@ec.europa.eu>
To: Peter Saint-Andre <stpeter@mozilla.com>
References: <3053F7E9-7C6A-4AAB-AC87-63DC1D6A58D7@webweaving.org> <b74e2e97-3fd3-d24a-3844-4b6ffef821d1@mozilla.com> <36DA5C85-D4D9-4257-9050-304E0BB2C714@webweaving.org> <7cd1750c-0c5f-42b8-6608-9287d594079f@mozilla.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Thu, 12 Aug 2021 10:28:17 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/VbL6c3qUnwOWKWT15v1-Wmebgpc>
Subject: Re: [urn] Request for a Namespace Registration for Unique (Vaccination) Certificate Identifier
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2021 08:29:43 -0000

On 11 Aug 2021, at 19:41, Peter Saint-Andre <stpeter@mozilla.com> wrote:
> On 8/11/21 5:25 AM, Dirk-Willem van Gulik wrote:
>> On 11 Aug 2021, at 01:07, Peter Saint-Andre <stpeter@mozilla.com> wrote:
>>> On 8/1/21 7:37 AM, Dirk-Willem van Gulik wrote:
>> 
>>>> For this reason the design[2] calls for a Unique (Vaccination) 
>>>> Certificate Identifier (UVCI) that uniquely identifies a specific test, 
>>>> vaccination or recovery certificate. 
>> ...
>>> However, the foregoing paragraph seems to indicate that a URN would
>>> identify a test, vaccination, or recovery certificate. That could be
>> ....
>>> administered, etc.) - that is, not one URN per person encapsulating
>>> numerous events in an array or what have you. That also doesn't seem
>>> quite consistent with this later paragraph:
>>> 
>>>> 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.
>>> 
>>> 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.
> 
> 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

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. 

> 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.

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

With kind regards,

Dw.