Adding support Digital Key management #702
Conversation
Signed-off-by: Erik Jaegervall <[email protected]>
|
I am in agreement that we may need to define some signals in this area. We may not be able to define what these signals are at this time, but we can start defining where they should reside in the tree. I can certainly see signals indicating whether the user has decided to block or enable sharing digital keys. |
|
@tguild you onto this one also _ I know we were discussing the CCC activities the other day and how we could do something in the CV BoF group for fleet management & digital keys |
spec/Vehicle/DigitalKey.vspec
Outdated
| # There are several reasons why a key state may change. Note that the implementation is outside the scope of this spec. | ||
| # | ||
| # Examples (informative): | ||
| # - If the primary key paring state changes to UNPAIRED all existing secondary keys may be terminated or removed. |
spec/Vehicle/DigitalKey.vspec
Outdated
| # | ||
| # Examples (informative): | ||
| # - If the primary key paring state changes to UNPAIRED all existing secondary keys may be terminated or removed. | ||
| # - If the vehicle identity (DigitalKey.VehicleId) changes all existing keys may be terminated or removed. |
spec/Vehicle/DigitalKey.vspec
Outdated
| # Keys may have different capabilities. Some keys can be used to drive the vehicle while others | ||
| # only can be used for specific purposes or with specific restrictions. | ||
| # The VSS model does not make any assumptions on what capabilities exist, but includes a signal | ||
| # DigitalKey.KeyData.KeyCapability (of string datatype) which can be used to show capabilities |
spec/Vehicle/DigitalKey.vspec
Outdated
| DigitalKey.PairingState: | ||
| datatype: string | ||
| type: sensor | ||
| allowed: ['UNPAIRED', 'PAIRED', 'PAIRING','BLOCKED'] |
There was a problem hiding this comment.
,'BLOCKED' -> , 'BLOCKED"
| BLE indicates Bluetooth Core Specification 5.0 or later. | ||
| UWB indicates IEEE Standard for Low-Rate Wireless Networks (802.15.4z-2020). | ||
|
|
||
| DigitalKey.BluetoothLeAddress: |
There was a problem hiding this comment.
Presumably, this attribute is only present or set for a BLE DigitalKey, correct? What would be returned if this attribute is not set? All zeroes? Should a comment mention this?
Similar comment for other fields in this definition.
There was a problem hiding this comment.
Historically we typically do not include any "undefined" value for VSS signals. So that if you ask for Vehicle.VehicleIdentification.VehicleExteriorColor or Vehicle.Speed and your VSS server currently does not know the vehicle color or the vehicle speed, the API should return "not available", "not found", "None" or whatever mechanism the API has to indicate that no value exist.
(This could off course be discussed for this particular case; if we would benefit from have a specific value for undefined/unknown)
spec/Vehicle/DigitalKey.vspec
Outdated
| type: sensor | ||
| datatype: uint64 | ||
| description: Start time of validity for the key. | ||
| unit: unix-time |
There was a problem hiding this comment.
This should be UTC and not "wall clock" time. Same for other times herein.
There was a problem hiding this comment.
That is implied by our definition of unix-time in https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/units.yaml#L213:
Number of non-leap seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970
Signed-off-by: Erik Jaegervall <[email protected]>
Signed-off-by: Erik Jaegervall <[email protected]>
|
Temporarily removed |
Digital Keys are becoming common for vehicles and there is even standardization ongoing within the Car Connectivity Consortium (e.g. CCC Digital Key Release 3). This is a complex area and it is likely so that VSS is not suitable to handle all aspects of digital keys as the procedures for registering keys may vary considerably and may involve aspects like token/certificate evaluation and physical steps that must be performed within a vehicle. There are however areas where VSS representation could be useful. One potential use-case is to offer the driver/owner an overview of which digital keys that have been defined for the vehicle and the status of them. VSS could potentially be used to trigger certain management steps, like adding or removing a key. Note however that VSS should not in itself be responsible for security critical functionality, like validating that request have been signed by the trusted primary key.
The purpose of this PR is to initiate a discussion on if this makes sense to add to VSS,