Subject: [saag] Interest COVID-19 'passport' standardization?

From: Harry Halpin <[email-masked]>
Date: Fri, 30 Jul 2021 20:17:21 +0200

Everyone [and apologies if you already got this message on CFRG or
SECDISPATCH],

While the research community and industry was very quick to work on
privacy-enhanced contact tracing, I've seen very few people taking the much
more pressing issue of COVID-19 passports.

If this IETF111 was in person, we could have done an informal BoF, but as
its' not, I'm sending out an email to gauge interest.

I've earlier seen some very badly done academic work using W3C "Verified
Credentials" and W3C Decentralized Identifier (DID) standards [1]. However,
while a bunch of sketchy blockchain technology has not been adopted (so
far, although I believe IATA and WHO are still being heavily lobbied in
this direction), there has been the release of the EU "Green" Digital
Credentials that actually uses digital signatures.

However, there's a number of problems:

* No revocation in case of compromise
* Privacy issues, i.e. leaking metadata
* Limited key management (booster shots might require)
* No use of standards for cross-app interoperability

Furthermore, there appears to be differences between countries, and some
countries do not use cryptography at all (the US). Therefore, as an
American in France who flew home ASAP to get vaccinated in the US, as a
consequence of this lack of interoperability I can't travel on trains or
eat at restaurants easily, despite being vaccinated. I imagine this will
become a larger problem.

I have a report I'm willing to share, but I'd first like to know if there's
any interest in standardization on this front at the IETF despite this
topic being, I suspect, a bit of  astretch of our remit. However, we live
in interesting times.

I don't think the W3C (or the ITU, etc.) has the security expertise, and
while the crypto and security/privacy here is pretty simple, I think it
should happen somewhere.

While I originally polled it by CFRG IRTF to see if there was any interest
whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better
places to start. I'd like to know what others think.

          yours,
             harry

[1] https://arxiv.org/abs/2012.00136

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jul 2021 11:29:49 -0700

To recap my comments on CFRG:
There seems to be a lot of enthusiasm for this in various forums, and it's
largely not well coordinated, with each group (the EU, VCI, etc.) doing
their own thing, and producing work of various levels of quality. Before
the IETF got involved, I'd want to see some evidence that the various
players are interested in a common standard and want to do one here, lest
we end up with XKCD 927.

FWIW, I've spent a bunch of time looking at the various proposals. If
people are interested they can find it at:
https://educatedguesswork.org/tags/vaccine%20passports/

-Ekr

On Fri, Jul 30, 2021 at 11:18 AM Harry Halpin <[email-masked]> wrote:

> I have a report I'm willing to share, but I'd first like to know if
> there's any interest in standardization on this front at the IETF despite
> this topic being, I suspect, a bit of  astretch of our remit. However, we
> live in interesting times.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Volker Birk <[email-masked]>
Date: Fri, 30 Jul 2021 20:57:49 +0200

> more pressing issue of COVID-19 passports.

Hi,

is it really needed to support something evil like the end of all
freedom?

It is bad enough having to deal with this pandemic. But supporting the
people trying to make the maximum profit out of it and at the same time
enslaving all others is disgusting.

Yours,
VB.
-- 
Volker Birk, p≡p project
mailto:[email-masked]
https://pep.software

---

From: Harry Halpin <[email-masked]>
Date: Fri, 30 Jul 2021 22:40:13 +0200

On Fri, Jul 30, 2021 at 8:59 PM Volker Birk <[email-masked]> wrote:

> enslaving all others is disgusting

Volker,

While I support your sentiments (in fact, I warned against the persistence
and abuse of COVID-19 related infrastructure as soon as the pandemic hit
[1]) and do note that the COVID-19 passports have already happened in most
countries, particularly in the EU. If they were built with open source and
open international standards, with actual privacy and security, then it
would be harm minimization.

So I'd like to keep this discussion to the technical level if possible, to
see if there is any technical interest. Wish we could be doing this as an
actual BarBOF in IETF 111!

  yours,
     harry

[1]
https://cointelegraph.com/news/this-is-our-last-chance-to-protect-our-privacy-amid-the-covid-19-crisis

> .

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Jul 2021 22:57:17 +0200

On 2021-07-30, at 22:40, Harry Halpin <[email-masked]> wrote:
> 
> While I support your sentiments (in fact, I warned against the persistence and abuse of COVID-19 related infrastructure as soon as the pandemic hit [1]) and do note that the COVID-19 passports have already happened in most countries, particularly in the EU. If they were built with open source and open international standards, with actual privacy and security, then it would be harm minimization. 

There are some components in the EU DGC that we might want to extract and properly specify.

Grüße, Carsten

---

From: Henry Story <[email-masked]>
Date: Fri, 30 Jul 2021 23:19:01 +0200

I doubt that the problem with Covid credentials has to do with the 
format of the credentials, or even the signature technology used to 
sign them.

The knowledge about the virus and the responses to it are evolving
very quickly, and so the flexibility of W3C Verifiable Credentials 
comes in very handy here, as it is built on semantic web standards
built on top of first order logic, hypergraphs, and designed for 
decentralisation, and evolvability. 

This flexibility is particularly important in a geo-political reality 
that covers many nations, with many different languages, different laws 
and no center of control. 
 
The verifiable Credentials standards do provide one important element
of the puzzle, but it does not solve help to tell which institutions 
are authorized  by a country to give out such credentials. That is something each 
country can only decide for itself, each differently as each country 
has different health systems, regulations, policing, etc… 

So what is needed is a way to link these countries together so that 
a verifying software can tell at any time if the institution that signed
a credential is entitled to make such claims by its country, and a way
to allow different vocabularies to evolve in a way that makes convergence
possible.

This requires a Web of Nations (WoN), which I wrote up here:
https://co-operating.systems/2020/06/01/

Technologically we have all the pieces to build such a system.
But it requires many different parties to come together to get it to work.

Henry Story

> On 30. Jul 2021, at 20:29, Eric Rescorla <[email-masked]> wrote:
> 
> There seems to be a lot of enthusiasm for this in various forums, and it's largely not well coordinated, with each group (the EU, VCI, etc.) doing their own thing, and producing work of various levels of quality. Before the IETF got involved, I'd want to see some evidence that the various players are interested in a common standard and want to do one here, lest we end up with XKCD 927.
> 
> FWIW, I've spent a bunch of time looking at the various proposals. If people are interested they can find it at:
> Everyone [and apologies if you already got this message on CFRG or SECDISPATCH],
> 
> While the research community and industry was very quick to work on privacy-enhanced contact tracing, I've seen very few people taking the much more pressing issue of COVID-19 passports.
> 
> If this IETF111 was in person, we could have done an informal BoF, but as its' not, I'm sending out an email to gauge interest. 
> 
> I've earlier seen some very badly done academic work using W3C "Verified Credentials" and W3C Decentralized Identifier (DID) standards [1]. However, while a bunch of sketchy blockchain technology has not been adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU "Green" Digital Credentials that actually uses digital signatures.
> 
> Furthermore, there appears to be differences between countries, and some countries do not use cryptography at all (the US). Therefore, as an American in France who flew home ASAP to get vaccinated in the US, as a consequence of this lack of interoperability I can't travel on trains or eat at restaurants easily, despite being vaccinated. I imagine this will become a larger problem. 
> 
> I have a report I'm willing to share, but I'd first like to know if there's any interest in standardization on this front at the IETF despite this topic being, I suspect, a bit of  astretch of our remit. However, we live in interesting times. 
> 
> I don't think the W3C (or the ITU, etc.) has the security expertise, and while the crypto and security/privacy here is pretty simple, I think it should happen somewhere. 
> 
> While I originally polled it by CFRG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better places to start. I'd like to know what others think.
> 
>           yours,
>              harry
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jul 2021 14:23:09 -0700

> decentralisation, and evolvability.

I don't really agree with this claim. Some of the proposals here use
VC and some do not, but they all seem roughly equally capable and
flexible to me.

-Ekr

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 30 Jul 2021 23:23:46 +0200

> There are some components in the EU DGC that we might want to extract and properly specify.

First - a word of caution - these standards were developed as the pandemic evolved - and are very narrowly tailored to a very specific compromise w.r.t to time, scope and what was legally possible quick enough.

Secondly be also aware that the EU DCC has a very specific and narrow use case - cross border travel; and is used in a setting where a traveler is generally also required to carry a passport or similar. As they are crossing borders. 

With that caveat - privacy impact is minimised in that setting - but by design it still reveals identity and some medical details to the verifier[1]. As that is core to that use case.

Conversely domestic implementations (like the one in the Netherlands) that are designed for use in the private sector (e.g. by a bouncer in the bar) are designed against different use cases. 

And, taking NL as an example again, may use selective disclosure, ZKP and other techniques to frustrate or prevent surveilance or tracking (i.e. not being able to recognise a person as they move around and see scanners at different bars).[2]

Most of this is quite akin to verifiable credentials - or borrows heavily from it. 

However both the EU and domestic approach allows for fully off-line use (i.e dynamically generated Qrs and verifiers with a static trust list). With absolutely no need to verify something ‘on line’ — not even something like an OCSP-ish revocation at Qr level. This is to minimise surveillance. 

Both approaches have been heavily optimised for size - as Qr are challenging in the field if they contain more than 1200 8-bit byte equivalent or so.

Standards can be found at https://github.com/ehn-dcc-development

If you are curious - most countries opensource their code (also to help with trust in society) - and joint European effort (by something called the eHealthNetwork) base implementations are also open source[3].

With kind regards,

Dw.
— 
Dirk-Willem van Gulik (currently helping the Ministry of Public Health in the Netherlands out as their CTO).

1: For the technology see: https://ec.europa.eu/health/ehealth/key_documents_en#anchor0 and specially https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v3_en.pdf.  

In short; it is an Qr code that can verified fully offline (both for scanner and citizen) that consists of a JSON payload, CBOR packaged, COSE signed, zlib-defalte compressed and base45 transport protected with the prefix ‘hc1’.

The JSON payload consists of the persons name and DoB and a medical block - that contains things like the vaccination used, the date, manufacturer and medically/responsibly entity. It does not have things like a passport or citizen number; the name and DoB is all that ties it to some other identity document.

The signature is verified against a trustlist of public keys; the latter is much alike to the ICAO masterlist commonly used for passports; a per country CA signing shorter lived digital signing certificates (ECC is mostly used).

Use this tool to decode your own: https://github.com/ehn-dcc-development/ehn-sign-verify-python-trivial

2: e.g for the Netherlands (https://github.com/minvws/nl-covid19-coronacheck-app-coordination) this is Idemix ZKP based approach; with a Qr code that changes every few minutes - with identity binding limited to just a few initials of the persons last or first name and the day/month of birth (the exact mix coded depends on the prevalence).

3:  Joint standard development: https://github.com/ehn-dcc-development, code NLhttps://github.com/minvws code eHealth Network collaboration: https://github.com/eu-digital-green-certificates

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 30 Jul 2021 23:29:40 +0200

> a verifying software can tell at any time if the institution that signed

..snip..
> Technologically we have all the pieces to build such a system.

Indeed.

> But it requires many different parties to come together to get it to work.

The DCC / European system (well, eHealth Network to be precise) consists of a technical system (code at https://github.com/eu-digital-green-certificates/dgc-gateway) that collects ‘root certificates’ of each countries within the context of the pandemic. These sign document signer certificates - which in turn sign the Qr codes. This is very similar to the ICAO master lists used for electronic cross board passports.

Joining this network is a technical and legal/governance process: 

	https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certificate_equivalence-decision_en.pdf

> to allow different vocabularies to evolve in a way that makes convergence

And this is handled by the technical working groups; with the vocabulary, schema and similar kept at:

	https://github.com/ehn-dcc-development/ehn-dcc-valuesets
	https://github.com/ehn-dcc-development/ehn-dcc-schema
	https://github.com/ehn-dcc-development/dgc-business-rules

And changing/evolving almost as rapidly as the pandemic response.

Dw

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 30 Jul 2021 23:35:57 +0200

On 30 Jul 2021, at 23:23, Eric Rescorla <[email-masked]> wrote:
> On Fri, Jul 30, 2021 at 2:19 PM Henry Story <[email-masked] <mailto:[email-masked]>> wrote:

From an implementor/designing perspective (both the NL domestic version -and- the EU DCC version)  — and although we tried very very hard - the absolute need for totally off-line use & preventing surveillance*, also, or especially by the issuing entities  (or blind trust in) combined with the inflexible state of the available semi-usable VC implementations and the very strong desire to have nothing ‘central’ and no ‘central trust’ - had us gradually evolve to something not quite VC. Despite this being the stated goal.

So I think we have some useful lessons learned w.r.t. the importance of off-line / totally local validation.

Dw

*:  e.g. spiked certificates with something unlikely to be cached or requiring a very unique lookup/OCSP, etc.

---

From: Volker Birk <[email-masked]>
Date: Fri, 30 Jul 2021 23:45:51 +0200

> would be harm minimization.

Dear Harry,

thank you for taking this serious! But I fear you're mistaken. Let me
explain:

The major problem is not the passport itself. It is who checks it in
which situation: commercial enterprises checking access to cultural
events, but as we saw in Israel while the test also to food supply and
education.

So it will be a corporation deciding if you get education for your kids
and if you're qualified to buy food.

Let's illustrate this with a live example:

Even if you're willing to take your vaccine and you're compliant with
all government rules, what if you're rejected at the gate in spite of
this?

Then you can go to court and sue a commercial enterprise for doing this
mistake – or for abusing their power, because you may be just a person
the owners dislike. Then you can sue them over years. And while this
time you cannot bring your kids to school and you cannot go to a
supermarket and buy food.

Sorry, this is way too much power to the wrong people.

While the pandemic the super rich became so much richer. And the
corporations' shares went through the roof.

It must be enough feeding them now. We need to take care of all those
people, who lost their business and who lost their loved ones in the
pandemic. Creating a power tool to suppress all resistance to the
government and handing over this tool to the corporate world will not
help here. And unfortunately, it does not matter how much good will and
intentions will be spend on this.

Yours,
VB.

---

From: Harry Halpin <[email-masked]>
Date: Sat, 31 Jul 2021 00:09:11 +0200

Everyone,

Good to see this conversation, and the contributions from Dirk have been
exceptionally relevant. In particular, I would put out of scope requiring
any verifier to be online and I would also put out of scope data formats
with limited real-world uptake, like W3C RDF and Verified Credentials. I
would focus on widely deployed standards, such as JOSE/COSE and TLS. In
this regard, the EU DGC has done well. I'd like to see international
comparison though, as I can imagine many other "proposals" or even working
systems are not using modern cryptography. I suspect there is definitely a
need for a privacy analysis that is more thorough than DGC has done
(surprised to see linkable signatures, centralized databases, and so on and
so forth) when we know how to build better and more in the EU
GDPR-compliant standards - although I suspect COVID-19 falls under a
national security derogation and so GDPR does not apply.

Not sure how many people are actually interested in chartering something
and the scope, but I'd be happy to host a meeting if someone is attending
IETF 111.

Although it may be rather late for some, I will be hosting a "side meeting"
virtually at the IETF 111 meeting today right after the CFRG IRTF meeting
ends. See the wiki for the link:
https://trac.ietf.org/trac/ietf/meeting/wiki/111sidemeetings

  yours,
    harry

On Fri, Jul 30, 2021 at 11:39 PM Dirk-Willem van Gulik <[email-masked]>
wrote:

> From an implementor/designing perspective (both the NL domestic version
> -and- the EU DCC version)  — and although we tried very very hard - the
> absolute need for totally off-line use & preventing surveillance*, also, or
> especially by the issuing entities  (or blind trust in) combined with the
> inflexible state of the available semi-usable VC implementations and the
> very strong desire to have nothing ‘central’ and no ‘central trust’ - had
> us gradually evolve to something not quite VC. Despite this being the
> stated goal.
>
> *:  e.g. spiked certificates with something unlikely to be cached or
> requiring a very unique lookup/OCSP, etc.
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Sat, 31 Jul 2021 12:02:22 +0200

On 31 Jul 2021, at 00:09, Harry Halpin <[email-masked]> wrote:

> working systems are not using modern cryptography. I suspect there is definitely a need for a privacy analysis that is more thorough than DGC has done

Fully agreed -and with the worst of the crisis over - this is a good time. Also as it is very likely that this is the time for changes/fixes. 

We are getting the first from the field experience, mis-implementations (e.g. the UK got the KeyIdentifier wrong, some countries have URNs that are not valid URIs, etc), the type of fraud that makes economic or political sense and start to see where the trust model is hard from a national governance perspective (e.g. due to delegation of sovereignty of overseas territories). But also as the DCC system is now pushed beyond its design - from a governance perspective (the majority of countries using it may soon well be non EU/EC & EEA /), from a  technical perspective (as countries are now considering boosters & similar) and from a use case perspective - - domestic / private sector scanning is now becoming a thing. 

So the timing is right to address this. And the IETF would be a good & neutral place - as this is first and foremost a standards exercise (actual code is almost laughably trivial[1] - so it is not a essential to start own the open source / code side).

> (surprised to see linkable signatures, centralized databases, and so on and so forth) when we know how to build better and

Note tha the DCC does not have a centralised database (and in fact, a lot of countries do not have any central database either - but rely on very distributed, delegate and often offline/non-API approachable data holdings in the country. Nor is the trust list centralised - each member state manages this essentially itself. The main central elements are the design, the joint list of ‘valid’ (that include “valids” that are not generally accepted; e.g. the codes for Sinovac en Sputnik) that is jointly maintained and a convenience ’trust list’ that is jointly managed for countries that are under the (privacy) regulation or have some adequacy/equivalence regulation or law in place.

> more in the EU GDPR-compliant standards - although I suspect COVID-19 falls under a national security derogation and so GDPR does not apply.

Currently - the engineering design assumption is that the GDPR fully applies - and both EUPD and the various national privacy regulators are heavily involved/heavily influenced the design. The final regulation actually goes quite a few steps further than the GDPR - and disallows certain things (around PII handling, revocation lists and especially the retention of any data post scan) that could conceivable be reasonable and proportional under the GDPR for certain goals.

> Not sure how many people are actually interested in chartering something and the scope, but I'd be happy to host a meeting if someone is attending IETF 111.

Happy to help out / provide information on what was done & why. As I realise that both speed and the international collaboration processes used were not that easy to follow from afar.

With kind regards,

Dw

1: Basically line 126 in https://github.com/ehn-dcc-development/ehn-sign-verify-python-trivial/blob/main/hc1_sign.py — CBOR package your JSON, COSE sign it; Zlib-deflate compress and put it into Base45[2] so it becomes Qr friendly (QRs then have a a 5.5bit efficient mode that is more scanner in the field-resistant than a raw 8bit Qr - yet is almost the same # of pixels).

2: https://datatracker.ietf.org/doc/draft-faltstrom-base45/

---

From: Volker Birk <[email-masked]>
Date: Sat, 31 Jul 2021 12:29:20 +0200

On Sat, Jul 31, 2021 at 12:02:22PM +0200, Dirk-Willem van Gulik wrote:
> Note tha the DCC does not have a centralised database (and in fact, a
> lot of countries do not have any central database either

No, they don't.

But there is zero chance that the enterprises, which do the checks,
haven't.  Founders of id2020:

https://id2020.org/alliance

Microsoft, Accenture, GAVI Alliance (Bill & Melinda Gates Foundation),
Rockefeller Foundation. See their invests.

Among General Partners:

Mastercard

Who could be the profiteers? Microsoft and Mastercard are already at the
Point of Sale. And the “Covid Pass” is useless without identifying the
person who's showing it.

This will be a gateway tracking of world's population, giving the
gatekeeper role to the corporate world.

BTW: having a central database will be perfectly legal for the
enterprises. “It is needed to do the identification of the person who is
showing the Covid Pass” is excuse enough in most if not in all legal
systems.

You're building dystopia.

Yours,
VB.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 31 Jul 2021 06:50:27 -0400

While a standard may very well emerge and the IETF is more than capable of ensuring the security and privacy are specified to high standards, this feels like overall it would be helping use cases similar to ones in RFC2804. I think we’d have a hard time ensuring the uses of a specified format and protocol to avoid falling into privacy violations. At some point, how it’s used would be out of our hands. 

I’m not sure the IETF would be able to constrain what is shared with whom as that will go beyond on the wire communications. While we could specify object level encryption, I’m not sure this type of protocol is a fit for the IETF given RFC2804 and other similar agreements. 

Best regards,
Kathleen 

Sent from my mobile device

> On Jul 31, 2021, at 6:29 AM, Volker Birk <[email-masked]> wrote:
>

---

From: Volker Birk <[email-masked]>
Date: Sat, 31 Jul 2021 13:08:09 +0200

On Sat, Jul 31, 2021 at 06:50:27AM -0400, Kathleen Moriarty wrote:
> how it’s used would be out of our hands. 

You named the problem in a nutshell. I will stop now. I made my point. I
have no power to stop you.

Yours,
VB.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 31 Jul 2021 15:44:07 +0100

I don't believe the IETF ought be active in this space.

For their originally designed purpose (cross border travel),
these systems seem mostly ok as traditional passports will
also be shown at the same time. I don't see that the travel
authorities need help from the IETF for that.

We are seeing significant feature-creep e.g. these QR codes
are now being required for indoor dining here in Ireland at
the moment. The scanning technology offered to venues by the
Irish govt at the moment is an awful online web page [1] to
which all the QR code data is sent (so govt servers get to
see who enters where, when, even though they say they don't
store any of that). That system is likely (IMO) to be widely
ignored within weeks of it's unwise introduction. We'd be far
better to stay uninvolved there too IMO.

Cheers,
S.

[1] https://app.digitalcovidcertchecker.gov.ie

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Jul 2021 17:17:55 +0200

> better to stay uninvolved there too IMO.

I don’t understand why the fact that governments buy inane applications (*) should prevent us from thinking about this space.  Patrik’s base45 draft is a nice example where we knew from the outset that the spec was suboptimal (in deployability, fortunately not in security).

Just because, er, foobook.com is reached via TLS doesn’t mean we have to stop supporting TLS :-)

Grüße, Carsten

(*) here in Germany we have the “Luca” app with an abysmal privacy design, which is often called “Luca-schenko” (schenken = giving a gift to someone) because some federal states paid huge amounts of money for no good reason to the instigators, which include a hip-hop star; you couldn’t make this up.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 31 Jul 2021 16:42:22 +0100

On 31/07/2021 16:17, Carsten Bormann wrote:
> I don’t understand why the fact that governments buy inane
> applications (*) should prevent us from thinking about this space.
Nor would I. Luckily that wasn't my argument.

For international travel: we're not needed.

WRT feature creep: we shouldn't help.

For those reasons, IMO the IETF shouldn't touch this topic
with a barge-pole.

WRT incompetent implementation: it's slightly useful to name
and shame.

S.

---

From: Metapolymath Majordomo <[email-masked]>
Date: Sat, 31 Jul 2021 11:14:51 -0500

Hi All,

Standardization of specific disease Electronic Medical Record (EMR) secure
clearinghouses is Out of Scope for the IETF. Vendors must be at liberty to
develop their own method if required by their sponsor or government and if
a solution becomes adopted which uses open source, then widely accepted by
other vendors /and/ is utilizing a non-standard method which proves
successful, then and only then should that Method should be discussed as
allocating a standard for the method, never the specific disease. We would
need more than one use case (more than COVID-19 vaccination EMR) to have a
balanced discussion about what's working and what's not. We should not be
steering into conversations about what policy companies and governments
should be allowed to make as it is not an Engineering topic.

I am interested in EMR in general, but as I'm actively working in this
space, I suggest we focus on broader security applications. When I look at
my alerts from USCERT a larger issue affecting the entire Enterprise
infrastructure is phishing and zero day issues. I'd rather see more
examination on what existing standards are in need of review given the
current rate of penetration.

With Regard,

Kronah Wood, CPhT
Metapolymath, LLC
PO Box 19236
Lenexa, KS 66219-9236
+1.2139158297

Sent from Mobile

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Jul 2021 18:28:00 +0200

On 2021-07-31, at 17:42, Stephen Farrell <[email-masked]> wrote:

Hi Stephen,

probably we are agreeing but just talking about different parts of the elephant.

> For international travel: we're not needed.

Apparently we were — there is lots of tech in there that the IETF standardized.  (If that tech works well and solves the problems, we are indeed not needed any further.)

> WRT feature creep: we shouldn't help.

Maybe unless the features actually are about areas where the tech also needs features, e.g., for privacy.

> For those reasons, IMO the IETF shouldn't touch this topic

Most certainly we don’t want to be the entity that standardizes the actual system (DGC/ehealth or whatever) or how to decide who gets to be trust anchors, etc.

But I still don’t understand why a topic that comes up in such a system (e.g., how to interface QR-Codes with our representation formats) can’t get IETF attention, in particular if it already came up in other contexts (e.g., IoT initial security setup (“onboarding”)).

Of course, the current systems are a done deal.  But we should listen attentively what will be needed for any 2.0 (or 1.1) — in the end we don’t want limitations in our tech to be the reason the upgrades don’t exhibit properties that one would want to have (data minimization etc.).
Establishing communication is a good step in that direction.

> WRT incompetent implementation: it's slightly useful to name

Which each of us can do but the IETF as an org can’t really.

Grüße, Carsten