What sort of Vehicle IDs should be sent?

[schnuerle]

What types of vehicle IDs are possible and sent in CDS?

1. License plate number?
2. Unique UUID provided by operators, like MDS?
3. VINs (not likely)?
4. City parking registration number? Could be an ID that is agreed upon by city and operator during permitting.

[jacobmalleau]

A comment on privacy - this ID should be an optional attribute in case a city or provider wants to anonymize their event data.

[schnuerle]

Per the discussions, it seems the working group is leaning toward:

1. a required UUID, if the data comes directly from a commercial curb user
2. an optional vehicle identifier painted on side of vehicle from company or sensor (but maybe this should be turned into a UUID through some hash?)

No VIN or license plate number.

[jfh01]

From what I understand about automated billing, it may be necessary to support license plates if CDS data is ever going to be used for transactional purposes. But maybe transactions all happen out-of-band of CDS...

[schnuerle]

Agree for many use cases recently brought in working group calls that a license plate would be required. Suggest adding an optional license_plate field in the curb_event object.

This field would be potentially sensitive data, and its addition will be reviewed by the OMF Privacy Committee, with guidance and use cases well defined for its use. Would review toll-by-plate rules or enforcement by ALPR in the US and regulations in the EU. This would be a framework for collecting data, but requires a higher policy around data management, retention, and security.

[schnuerle]

Added license_plate with temporary privacy comment.

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/events/README.md#curb-event

[schnuerle]

Per the discussion at the last WG meeting, there was some support for adding optional license plate number. Some permitting use plate registration. Some use plates for legally authorized ticketing. So maybe we make it an optional vehicle_license_plate field. Thoughts?

[jlarsonOmahaNE]

In order for us to enforce, we do need to use a LPN and if one is not available we then use the VIN. I was also thinking maybe using the registered USDOT number printed on the side of vehicles instead of VIN? Or could there be documentation on how cities can create their own IDs? We have thought about having delivery companies sign up for a digital permit and we provide an ID.

[schnuerle]

That sounds like you have use for all of the following (most of these are listed in the original post) in some circumstances:

1. License plate number (LPN) - captured with license_plate now
2. USDOT external number - captured with vehicle_id now
3. Unique vehicle ID - captured with source_id UUID now. This is only available if sent in company data feed
4. VIN
5. Digital permit number

4 and 5 would also only be available if sent in company data feed, like 3. Maybe we hold off on these for CDS v1.0? If you want to do 5, then you'd know the provider/operator and can lookup a permit later outside of CDS by the provider_id they send.

[schnuerle]

Maybe need to think about device_id and vehicle_id here too, since we don't have a real device_id concept here, nor any way for an operator to send an identifier to an agency in CDS, except maybe source_id. Propose looking at MDS for inspiration, like in trips and status changes. E.g. for reference:

Field	Type	Required/Optional	Comments
provider_id	UUID	Required	A UUID for the Provider, unique within MDS. See MDS provider list.
provider_name	String	Required	The public-facing name of the Provider
device_id	UUID	Required	A unique device ID in UUID format
vehicle_id	String	Required	The Vehicle Identification Number visible on the vehicle itself

[jiffyclub]

The possibilities here seem pretty context dependent. For data from a provider feed you could get presumably whatever you want, from an arbitrary unique ID to a permit number to a taxi medallion. A person standing at the curb could collect LPN, VIN, permit numbers, etc. But some sensors can't collect any vehicle IDs. So we might want to make this fairly flexible, like allow a vehicle_ids object that can have a variety of different fields?

[schnuerle]

We can make this ability and distinction between the uses of each field clearer in the spec.

[schnuerle]

After discussion, added vehicle_permit_number to the Events object here:

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/events/README.md#curb-event

There is a demand for this in some scenarios, it's easy to optionally add, and there is no individual privacy risk.