Consent support in VISSv2

The VISSv2 spec is basically feature complete, the probably final outstanding feature to be discussed is issue#474 (https://github.com/w3c/automotive/issues/474<https://clicktime.symantec.com/15tpDKvkVHYdp7GxzXVQk?h=_75J4ZnhQ2ZYZcC0cbfFlFjAFDRx143glkbHkKX_rg8=&u=https://github.com/w3c/automotive/issues/474>), whether the spec should include a possibility for an “external consent framework” to control the behavior of a VISSv2 server in terms of granting requests, or not, from a consent perspective.
The mail thread below contains a discussion between the participants on the last couple of WG meetings where this has also been addressed.
The attached document is an incomplete proposal on text for the spec.
My view is that we should probably not include it in this spec version, but continue to discuss it and consider it for the next version.
BR
Ulf


From: Bjorkengren, Ulf (UB)
Sent: Friday, June 2, 2023 4:21 PM
To: Winzell, Peter <peter.winzell@volvocars.com>; Isaac Agudo Ruiz <isaac@uma.es>
Cc: Carine Bournez <carine@w3.org>; Ted Guild <edwardguild@geotab.com>; isaac@lcc.uma.es
Subject: RE: Consent support in VISSv2

The requirement to support consent per client is not so easy to solve. The access token does not contain any direct client identity, and neither does the access grant token. The client identity is explicit in the access grant token request, so I assume that the access grant token server keeps a log that links the client identity to the access grant token identity (jti claim). However, the access token, which is what the server has in its hands when issuing the request to the ECF, has an independent identity (jti) from the access grant token, otherwise that could be provided to the ECF, which then could use that as a reference to get client identity information from the access grant token server. IF the access token jti is deterministically derived from the access grant token jti, then the loop would be closed, and the ECF would be able to know the client identity.
Is this an acceptable design, that the ECF will have to contact the (cloud based) access grant token server to get information about the identity of the requesting client?
If not, does anyone have an idea of how to solve it?

BR
Ulf

From: Winzell, Peter <peter.winzell@volvocars.com<mailto:peter.winzell@volvocars.com>>
Sent: Thursday, June 1, 2023 2:38 PM
To: Isaac Agudo Ruiz <isaac@uma.es<mailto:isaac@uma.es>>
Cc: Bjorkengren, Ulf (UB) <ubjorken@ford.com<mailto:ubjorken@ford.com>>; Carine Bournez <carine@w3.org<mailto:carine@w3.org>>; Ted Guild <edwardguild@geotab.com<mailto:edwardguild@geotab.com>>; isaac@lcc.uma.es<mailto:isaac@lcc.uma.es>
Subject: Re: Consent support in VISSv2

WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding.

Hi,
So, if I get it right the tag in the data model(tree) is a tag per client then ?

So, each client has a version of the tree :
Client  1 => “consent”: {“value”: “X1”, “expiry”: “Y”}
…
Client n => “consent”: {“value”: “Xn”, “expiry”: “Y”}
…

So,

Out of scope for Spec:

We have a dialog with the user that we can call from each app:
Consent  = App_x -> AskForConsent(lat,long)
If Consent
                ECF -> (x,“Set”,“consent”:“[vehicle.*.lat, ”:“[vehicle.*.long]”})
Else
                ECF -> (x,“Set”,”deny_consent”,”[ vehicle.*.lat, vehicle.*.long]”

Scope:

When App_x asks for lat,long the VISS looks up the value for app_x for lat, long ?
Se we then need to add how a client/user is associated with a requested signal…?

Luckily resolving the case when we have two users for one app would be out of scope…😊

/pw




From: Isaac Agudo Ruiz <isaac@uma.es<mailto:isaac@uma.es>>
Date: Thursday, June 1, 2023 at 12:55 PM
To: Winzell, Peter <peter.winzell@volvocars.com<mailto:peter.winzell@volvocars.com>>
Cc: Bjorkengren, Ulf (UB) <ubjorken@ford.com<mailto:ubjorken@ford.com>>, Carine Bournez <carine@w3.org<mailto:carine@w3.org>>, Ted Guild <edwardguild@geotab.com<mailto:edwardguild@geotab.com>>, isaac@lcc.uma.es<mailto:isaac@lcc.uma.es> <isaac@lcc.uma.es<mailto:isaac@lcc.uma.es>>
Subject: Re: Consent support in VISSv2
You don't often get email from isaac@uma.es<mailto:isaac@uma.es>. Learn why this is important<https://clicktime.symantec.com/15uBY3eVfd1Ake8vaegBG?h=GoZbBUHlvNHkIHUv7qFLtqqnzeShs1b4TtCGhNa4QhA=&u=https://aka.ms/LearnAboutSenderIdentification>
Hi Petter,

I think in this case each application can be considered as a separated client, and the server could easily apply different policies to different clients. Maybe we should also include this example in the document.

One more thing, I think it would be good to talk also about how specific signals could be tagged to require consent.
For example, you could require consent to use a signal in the cloud, but maybe not to use it in the vehicle. Maybe this can be connected to the purpose ...
I know this complicates the document, maybe this is not needed at this point.

Isaac.


El jue, 1 jun 2023 a las 12:47, Winzell, Peter (<peter.winzell@volvocars.com<mailto:peter.winzell@volvocars.com>>) escribió:
Hi, thanks for this.

I was just thinking if I have multiple applications that runs in-vehicle, the user wants to give one consent to push a data point to the cloud, but for the same data point on another app the user does not want to give consent.   These applications then cannot depend on the VISS server to handle this, is this not a reason for not doing this at the server level but pushing this to the actual applications, or is it a system thing , either you give or you don’t then I think this proposal would work…


  *   Say, one user really trusts Apple maps but not Google maps, but really like the search options in Google maps… Maybe a stupid example…

Br
Peter Winzell



From: Bjorkengren, Ulf (UB) <ubjorken@ford.com<mailto:ubjorken@ford.com>>
Date: Thursday, June 1, 2023 at 12:19 PM
To: Carine Bournez <carine@w3.org<mailto:carine@w3.org>>, Ted Guild <edwardguild@geotab.com<mailto:edwardguild@geotab.com>>, Winzell, Peter <peter.winzell@volvocars.com<mailto:peter.winzell@volvocars.com>>, isaac@lcc.uma.es<mailto:isaac@lcc.uma.es> <isaac@lcc.uma.es<mailto:isaac@lcc.uma.es>>
Subject: Consent support in VISSv2
Hi,

Attached is a description of how consent could be supported in VISSv2.
Review comments are welcome. Let us discuss it at the next WG meeting.

BR
Ulf