Identification extension (LicensePlate and VehicleExteriorColor)

[jakubdrabik]

During our adoption of VSS we noticed missing license plate number and vehicle exterior color.

VehicleExteriorColor could further be accompanied by VehicleExteriorColorSpecification with more details.

[erikbosch]

Do we need to more explicit on what we expect this signal to contain, for example stating that it shall be the OEM name of the color, rather than internal/standardized color code, and that the names used are not standardized? For example, a possible name could be "Carnelian red metallic".

(I by the way do not know if there is any international standard color scheme for vehicle colors. In the Swedish vehicle registry there are only 24 colors to choose from, like light red, red and dark red, but I assume that varies from country to country)

[jakubdrabik]

In my experience, there's usually a need to have a basic colour palette which serves as easy identification, especially towards users and for comparative reasons across different brands/models. Something you could find in the Vehicle Registration Certificate (at least the European one), however, there's no standard set of those colours and it differs per country as far as I know.

This attribute (VehicleExteriorColor) is meant to represent this basic set of colours (blue, black, red, white, ...).

"Carnelian red metallic" are rather marketing names (could be VehicleExteriorColorName) that refer to specific colour codes of an OEM (could be VehicleExteriorColorCode).

Does that make sense?

[erikbosch]

I think it makes sense

[jakubdrabik]

I'll provide a better description of the property

[adobekan]

What if we have both option, one with fancy name from OEM and second as basic pallet which you might find in vehicle license?

[erikbosch]

Meeting notes:

• Shall we possibly also add OEM marketing name and OEM color code?
• Adnan: Would be good to have all
• Jakub: Better to keep it as is, add the other later.
• Is there is a risk to have the license plate signal configurable by the user - could we add a comment stating the risk.
• Jakub - I could mention the risk
• Erik - Maybe something for me and Adnan to discuss in Data expert Group - how is various attributes handled, are they defined by OEM, vehicle or owner, ....

[jakubdrabik]

@erikbosch @adobekan @nickrbb I dealt with the trailing space and mentioned the license plate risk using the comment if it's sufficient this way

[erikbosch]

Concerning colors there were a meeting chat message asking if we possibly should use colors from https://www.farb-tabelle.de/de/farbtabelle.htm.

My personal view is that using those standardized colors does not make sense, as they neither correspond to the colors supported by the vehicle registry, not the OEM marketing name of the color. The Hex/RGB code could possibly be interesting to represent, but I do not know if it would be sufficient for a garage to do a good paint job.

By the way, I found the 10 colors used in the german vehicle registry. So a bit fewer than the 24 we have in Sweden:

Es stehen insgesamt 10 Farbcodes zur Verfügung, die folgenden Farben zugeordnet werden:

0 = Weiß 1 = Gelb 2 = Orange 3 = Rot 4 = Lila bzw. Violett 5 = Blau 6 = Grün 7 = Grau 8 = Braun 9 = Schwarz

[jakubdrabik]

Concerning colors there were a meeting chat message asking if we possibly should use colors from https://www.farb-tabelle.de/de/farbtabelle.htm.

My personal view is that using those standardized colors does not make sense, as they neither correspond to the colors supported by the vehicle registry, not the OEM marketing name of the color. The Hex/RGB code could possibly be interesting to represent, but I do not know if it would be sufficient for a garage to do a good paint job.

By the way, I found the 10 colors used in the german vehicle registry. So a bit fewer than the 24 we have in Sweden:

Es stehen insgesamt 10 Farbcodes zur Verfügung, die folgenden Farben zugeordnet werden:

0 = Weiß 1 = Gelb 2 = Orange 3 = Rot 4 = Lila bzw. Violett 5 = Blau 6 = Grün 7 = Grau 8 = Braun 9 = Schwarz

To give it another perspective, this is the list of options from mobile.de.

I used to work on a dealership management system, including one for used cars, and having a standard set of (not just) colours would make life much easier. On the other hand, the market is very inconsistent which might lead to a huge burden to try to standardize the values.

[nickrbb]

The issue with the license plate number isn't that it's sensitive (it's displayed on the vehicle in a very prominent and easily readable manner, in most cases) it's that it cannot be trusted as correct.

This is because this is something that the OEM cannot set and protect/make read-only (e.g. as they do with the VIN), and the license plate on a vehicle is subject to change (e.g. vehicle owner buys a privatised number plate, US citizen moves to a different state to live), consequently it means someone else other than the OEM has to configure it, and with privately-owned vehicles this is going to have to be the vehicle owner/user. In which case, if some local authorities want to use this signal rather than, say, using automatic number plate recognition (ANPR) technology, then this would be a very bad idea. Note that, in the UK at least, it is a crime to display incorrect number plates (purposefully or accidentally); it is NOT a crime to have an incorrect license plate number configuration within vehicle systems.

Please don't misunderstand my concern to be objecting to this proposal, because I am not. I see valid use cases for having this information in vehicles, including privately-owned vehicles e.g. vehicles paying for their parking automatically (in which case, vehicle users are incentivised to configure the right license plate number so that they don't get a fine for parking without paying). But if this data is used for say, congestion charging (e.g. https://www.visitlondon.com/traveller-information/getting-around-london/congestion-charge), then the vehicle user is incentivised to fake it.

I hope that conveys my point. As I said, just having some words of warning about this would resolve my issue. We can't stop certain entities (e.g. local authorities) from ultimately misusing it and then finding out people can easily circumvent it, but we can at least warn them.

Thus, proposed wording could be something like:
Note: this attribute may be configurable by the vehicle user, and therefore should be considered untrustworthy in the absence of another method of verification.

Here "another method of verification" could be that a vehicle fleet manager configures this setting and locks it down from being altered in the vehicle itself, which I believe was a use case mentioned on the call yesterday.

[jakubdrabik]

@nickrbb The information might as well be simply out of date. I suggest this:

comment: Depending on the context, this attribute might not be up to date or might be misconfigured, and therefore should be considered untrustworthy in the absence of another method of verification. Moreover, it is potentially sensitive information.

What do you think?

[nickrbb]

I don't understand why you think this is sensitive information (see my explanation as to why I don't think it is in my first paragraph of my posting above). Please can you elaborate?

[jakubdrabik]

I don't understand why you think this is sensitive information (see my explanation as to why I don't think it is in my first paragraph of my posting above). Please can you elaborate?

Even though it's prominent, considering the same system (inside/outside the vehicle) would also keep information about the user, it could potentially lead to risks like privacy invasion etc. However, this is very specific to use cases and probably not a concern of VSS itself. I updated the PR with just the first sentence.

[nickrbb]

Looks OK to me now, thanks.

[adobekan]

Looks good.

[erikbosch]

Meeting notes:

• Ok to merge if build succeeds