Proposal to add a “consent hook”

[UlfBj]

A W3C security review of the VISSv2 specification pointed out that it does not provide any support for a consent mechanism, to enable a “data owner” to control whether data sharing to requesting clients shall be allowed or prevented.

This led to the following possible addition to the spec that would provide not a complete consent framework solution, but a “hook” that could be used for blocking, or unblocking, data to be returned to a requesting client, depending on a Yes/No consent parameter.

The idea is a variant of the access control selection mechanism that uses the Vss node metadata “validate”:” to declare the access restriction of a node. The same principle could be used for consent status of a node, using a node metadata “consent-status”:<yes/no>, which is then inspected by the VISSv2 server at the reception of a request, leading to either an error response (“consent-status”:”no”) or a successful response(“consent-status”:”yes”). Different from the access control case is that this metadata does not have a static value, but must be dynamically modifiable. The interface to do this must not be exposed to the clients, but only in a secure manner to the “in-vehicle consent framework”. The details of this interface and the consent framework, how it obtains the consent from the data owner, etc. would be out-of-scope in the VISSv2 specification.

I believe this could be covered in its whole in a chapter similar to the “Access Control Selection” chapter. The new VSS metadata would not necessarily have to become adopted officially in the VSS documentation, even if would be desirable. It could be populated into the VSS tree using e. g. the layering mechanism.

There are details yet to be worked out, the (“consent-status” should probably have a“not-set” alternative value, it should maybe be possible to apply it not only to tree leaves (single signals), but also to branches (covering multiple signals), etc.

[erikbosch]

An alternative approach to just having yes/no could be to rather allow use of identifiers, possibly one for read and one for write. If a VSS node (or any parent branch) has the following metadata:

consent_read: 'audio_information_read'
consent_write: 'audio_information_write'

Then the server could give a more user friendly consent message (based on lookup of the provided identifier) compared to just stating exact name, like "The garage wants to read service related information for your vehicle, do you accept?"

[UlfBj]

I think the spec/server shall be minimally involved in the "consent framework", and only deal with rejecting, or accepting request according to the status of the consent for the signal(s) as set by the consent property value.
If the signal is not tagged for access control the server only knows the client IP address. If tagged it then also knows its role(s) and the purpose. The server could provide this information to the in-vehicle consent framework, and then let it handle the consent messaging, dialogue, etc.

[UlfBj]

Consent chapter added by PR#483