is there any esablished tagging scheme to tag that a facility supports end-to-end encrypted email communication, e.g. using OpenPGP standard? (I just came to it by mapping a amenity=doctors, healthcare=doctor, who actually offers OpenPGP encrypted email ).
If not, what about introducing
email:encrypted=* or contact:email:encrypted=* (as synonymous meaning),
e.g.:
email:encrypted=yes (to indicate that encrypted email communication is supported, but no further details given),
email:encrypted=optional (to indicate that encrypted email communication is supported but not required),
email:encrypted=mandatory (to indicate that encrypted email communication is required),
email:encrypted:type=smime or email:encrypted:type=pgp (to indicate the type: S/MIME or OpenPGP),
email:encrypted:pgp:keyid= tp specify the OpenPGP key ID
email:encrypted=no to explicitly say that it has been checked weather encrypted email is supported by the facility and the answer is “no”.
(Synonymous: Using the contact: prefix before all those suggested keys.)
Tags 101: Never start inventing more meaningless *:type= suffix
Already have 6+1 contact:email:pgp=
You should try to explain how OpenPGP work in short to everyone to inform a decision. They use a different format. I would need to know what’s a “key” or “fingerprint”. From what I can read, there is a fingerprint, long key id, and short key id.
Considering you already need to use *email:encrypted:pgp:keyid= , *email:pgp= would be shorter. Or *email:encryption=pgp , but the word form against *:email:encrypted= needs to be decided. So could also be *email:encryption= + *email:encryption:protocol= etc.
As a very general concept, I would try to keep OSM about “where something is” and “what something is”. This is a doctor’s practice, the name is so-and-so, and it is located here.
We are not, and should not aim to be, a business directory (“where can I find a doctor who offers procedure X for people with insurance Y with opening times after 16:00, a special waiting area for people with an aversion to noise and who offers gluten-free snacks while you wait”).
These business details are prone to changing more frequently than we can notice and map. If the practice closes or moves, that’s something a mapper is likely to notice when passing by, but if they change their PGP key, we’ll have the old one in our data for ever. (And worse, people might trust OSM and send sensitive information with a compromised key, instead of checking with the practice before.)
There’s a tendency for OSMers to record more and more detail about a place (like where exactly in a supermarket the cereals aisle is or whether the supermarket participates in some sort of marketing scheme), and I don’t feel good about that. For everything you add, ask yourself: Can you shoulder the responsibility of keeping that current? Because someone has to.
You’re free to map anything you like that’s verifiable. But that also means, that not everything that’s currently mapped can and should serve as an example of what’s considered good, meaningful, and easy to maintain. I’m not saying opening hours shouldn’t be mapped (I tend to rely on them a lot), just that because something is actively mapped, doesn’t mean it makes sense to do so. So “whataboutism” doesn’t really help here.
).