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

Ted Hardie <ted.ietf@gmail.com> Thu, 12 August 2021 09:13 UTC

Return-Path: <ted.ietf@gmail.com>
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 F3CCD3A3E41 for <urn@ietfa.amsl.com>; Thu, 12 Aug 2021 02:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 YIlML2jU3rsC for <urn@ietfa.amsl.com>; Thu, 12 Aug 2021 02:13:23 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A0E3A3E40 for <urn@ietf.org>; Thu, 12 Aug 2021 02:13:23 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id v10-20020a9d604a0000b02904fa9613b53dso6917913otj.6 for <urn@ietf.org>; Thu, 12 Aug 2021 02:13:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UraetyH2L6txpxrGOmFsSQJu00GzGh9fDyDPPf7Q1+Y=; b=aHk/g9LQy4gQoa+KSe3v+nUGcXcNWQUyX6HCjFHvCMonBx9K3J33shkWtmDbYytkqs VV1zq2770Irv+chb+5eRPiITJS/3QHg8sDajXyoiQY5lPyop4g1KwtzPdCrefOir8hF3 GStQsUugLIPdJvWiHA3uS9qqmGiyohy89kQ9XcFLXe6oQoL5bEjFs8h/RfqOp3Q80IRB 4tH2+50EpXBa8TMXXLtfbuYBkwQG9DSjsHMS2B+JhWjBH6gTG8f2aSTk3LY10xYJjMke 0Zcz/yPzACzSc7fDX3u9i/xOo9HgwlyN5WYkeJYXXN0pnNp2fEvfDfhMjv1andfSpvwu tprw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UraetyH2L6txpxrGOmFsSQJu00GzGh9fDyDPPf7Q1+Y=; b=sJ2fY9OspC8uem9/VexrfAfsFBxVru+CpTXlCRwoWjcsMCWOPzabyqHSfFqtiFEbs9 XJgVsPUCz1Zosx9WEc+c1bhkiBlBVVZy0OXVieDxzQwmNIQadYPhe4lpK14ZxnAM2s3n hnVYJz8X4rgM3aWp95U7URrBZ2SjOwkA/hWnbNZzNworVik3R36IfDZwSDqj154MWJvk nh2mxOd8JL1s6a5N0z+JwTyiMmSky3GdMh8Wv+X7pPH2CwCtEVW5VoQYwRG94eCUqFQl dVwEcvg6FYdXSWEkzz1XDlLitC8hQzHkSjBJfqQW8j4K1BL3Id8yQVagN2B2cSaDmtg5 dLjQ==
X-Gm-Message-State: AOAM5324DvIAtOt2wgUkzWHnCb2gSLwo+oq6Zw1p7ME/TE7qo74WiHhP uYalwZTSoALp93DjxUvciWihELKqUj/qzmTnmFs=
X-Google-Smtp-Source: ABdhPJwnZwyNCv9B+tJp7/PYxiUvGPtZezlGUO0pGn/kmTZy//WLfaEBncLKY0wCHgTgLFcwXe7PFz9McnJta54GdJ0=
X-Received: by 2002:a05:6830:82c:: with SMTP id t12mr2678665ots.165.1628759601890; Thu, 12 Aug 2021 02:13:21 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <7cd1750c-0c5f-42b8-6608-9287d594079f@mozilla.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 12 Aug 2021 10:12:55 +0100
Message-ID: <CA+9kkMBK4C8NK_h=nXN_Z-1ogA6H5Z91oNVWRAySESaEkob_qw@mail.gmail.com>
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Dirk-Willem van Gulik <dirkx@webweaving.org>, urn@ietf.org, the eHEALTH-NETWORK Secretariat <eHEALTH-NETWORK@ec.europa.eu>
Content-Type: multipart/alternative; boundary="0000000000007ec89b05c9592517"
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/C3HRQIfZk-2wir5gv7yOiXxhSAw>
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 09:13:28 -0000

On Wed, Aug 11, 2021 at 6:41 PM 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.


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
> 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
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>