I’m looking for some sort of supplement to `access:` to describe whether using a feature requires handing over Personally Identifying Information. This is different from eg.: “barrier=biometrics” in that it’s not about the machinery, but rather about permission or availability.
The motivating factor in my case is documenting changes to policy to the usage of publicly available (municipal) infrastructure to require handing out additional identifying information that is more verifiable (and thus more Personally Identifiable) compared to previous policy. Does this exist, or should I raise a proposal?
I’m looking for something that allows me to document conditions such as use of a given feature or facility requires things as, with varying degrees of severity:
showing, or fully handing out, a national ID document or passport
submitting to a biometric exfiltration (fingerprints, iris, gait, etc)
providing verifiable live contact (eg.: a phone number that is immediately checked)
providing proof of residence (eg.: payment voucher in the corresponding jurisdiction)
It might help to give some actual examples what you are talking about.
Usually you need a passport to enter an embassy, though I’m not aware we add this information to our data, it might be access=private in case it’s a larger area.
Companies might also use biometrics as access control within the facility, which would also be access=private.
At airports you might need at some point an ID, if I recall it correctly, we map the facilities after security as access=customers, but I don’t think we differentiate whether you actual need an ID or just a boarding pass.
Yeah, I suppose for some facilities, the kind of information requested is “expected”.
One example I was thinking of was our municipal libraries. In order to account for usage and to help keep them funded, visitors were previously requested(1) to register some information such as their name, national ID number, and “a means of contact” (some people would put, say, their Instagram). However starting last year some changes were made: the policy was made mandatory register instead of optional, the ID number and the person’s signature are checked against one’s ID card, and the “means of contact” has to specifically be a telephone number or e-mail. This for a facility intended for public usage.
In other example, some of our local universities establish access controls to buy stuff from lounge and lunch area, but those methods diverge across operators. (I guess this has some sense to it: the intended audience is the students) One of our universities allows some of the general public by way of checking the national ID card whereas another requires registering an account on their online service, the process of which does require usage of “Clave Única”, our national online token for government services.
Finally, in the context of some privately-operated-with-fiscal-backing cybercafes and “cowork areas”, it is necessary to register one’s name and signature plus contact info; however the name and signature are not checked against one’s actual ID card but instead the information plus contact info are passed down to a third-party which performs monthly checks on customers and attendants, so the contact info has to be verifiable.
Libraries I know, you just need such kind of stuff if you want to borrow something, not to get in, but maybe that’s different in your case? I’m not aware of a tag describing what you need in order to borrow a book from a library. Though I think there are so many different systems that a systematic tag might be not really beneficial and description will do )or just a link to the website.
I would use access=private in case you only can use the facility as a member and not everyone can just be a member. For example, a supermarket, where you need to purchase a membership card in order to shop I would not consider as private.
There’s a post_office:id_check=* key but the wiki documentation is fairly unclear on what it means. I’m assuming the description is just translated from German, but I didn’t find further explanation there either. Is that something that could/should be generic?
I think there are some further uses for a tag that describes (unexpected?) access restrictions based on identification method. E.g. fully automated shops / vending machines might only accept a locally-issued id, local phone number, local credit card etc. even though there’s no official written “no foreign people” policy. (And indeed such might not even be intended.)
The types you mentioned are still very few, but it should be no problem to extend this by new subkeys like id_card, biometric, fingerprint, passport, iris_scan, proof_of_residence.
I agree with this. I don’t really see a need for a new generic key when the exact method of verification can be coded under a subkey.
Only now it occurred to me that there’s one case very nearby me where @lambalicious’ question applies (depending on what one considers Personally Identifiable Information): the Kaisantunneli Bicycle Garage in Helsinki.
Even just accessing it requires “that the cyclist has registered as a user of HSL’s Bike Parking Service with a strongly authenticated HSL account”, though other methods are being developed also. But even just accessing it requires authentication.
Currently the amenity=bicycle_parking is tagged with access=permissive, but an authentication:HSL_account=yes (or whatever) would be beneficial additional information!
In general, I agree. But I’m wondering whether the question is asking about identifying when registering. Rigorously, authentication:*= is used each time the feature is used. Needs to be eg membership=required + membership:authentication:*= for most of the cases asked.
Agree, like if I need to give fingerprints for getting the account, but at the object itself just my membership card is required we should just record that tis membership is required. It’s not important to OSM what is needed to obtain that membership.
Thanks for the pointers everyone. I’ll keep an eye on Key:authentication to see if this can be adequately used. @aktiivimallikansalainen has a point at least on reflecting my experience: this is about requirements that are “not posted” or are not part of what one could describe as the “intended workflow”. It’s not necessarily membership, as this affects also public / general-purpose usage.
In any event, my concern in wanting to represent this data on OSM is less about what it is used on (tools, machines, etc) and more about and more about what the nature of the information is, and the risks that can imply. Could be useful to have this mapped for example regarding social or “social” facilities in places that are becoming more recessive or fascist, or regarding risks that one would have to hand out something like body samples that could reveal one’s medical conditions.