Re: Consent support in VISSv2

Ok, got it.
Thanks!
/pw

From: Andre.Wendel@bmw.de <Andre.Wendel@bmw.de>
Date: Tuesday, June 27, 2023 at 9:50 AM
To: Winzell, Peter <peter.winzell@volvocars.com>, ubjorken@ford.com <ubjorken@ford.com>, public-automotive@w3.org <public-automotive@w3.org>
Subject: Re: Consent support in VISSv2
The Client would by something like an App-ID, the consent needs to be bind with the ClientID and the user; within the oAuth-Process you have the ClientID as technical identifier for the app within the token request process; Often the ClientID/Secret is used to have a base security, so that not everyone access tokens (in general the secret is mostly build inside the code and can be recompiled);

Within the token request process you have normally both information the ClientID of the App and the user ID; The auth server or anything else can then store the consent based on the ClientID and user information; In this case it would make sense that the auth sever in combination with a consent system is doing this based on the available purposes;

Every ClientID could be linked with purposes, so that it is clear during the login process for the token, which rights the user grants;

Cheers,
André

Von: "Winzell, Peter" <peter.winzell@volvocars.com>
Datum: Dienstag, 27. Juni 2023 um 09:45
An: "Bjorkengren, Ulf (UB)" <ubjorken@ford.com>, "Wendel Andre, EN-51" <Andre.Wendel@bmw.de>, "public-automotive@w3.org" <public-automotive@w3.org>
Betreff: Re: Consent support in VISSv2
Neu gesendet von: <public-automotive@w3.org>
Neu gesendet am: Dienstag, 27. Juni 2023 um 09:44

So, if the client has multiple users or is tied to a family account ? One user’s consent is all users’ consent.  If we can identify us with the system should not our consented info be cached – or does that violate some consent principal?

Br
Peter Winzell

From: Bjorkengren, Ulf (UB) <ubjorken@ford.com>
Date: Monday, June 19, 2023 at 1:31 PM
To: Andre.Wendel@bmw.de <Andre.Wendel@bmw.de>, public-automotive@w3.org <public-automotive@w3.org>
Subject: RE: Consent support in VISSv2
Hi,

After reading the comment from André, it seems what is missing in the spec is a ClientID. My proposal is to add that to the “clx” claim, which exists in both the access grant token and the access token.
This ClientID would be an input to the AGT server in the request for an AGT. It should be a short and descriptive human readable ID/name that would have to be unique within the ecosystem. If not unique, then AGTS rejects request with appropriate error code. It should be in the interest of the client to make it descriptive, as if not the likelihood to get the consent is diminished.

With this in the spec, it should then be possible to also include an ECF support that can handle consent for individual clients.

BR


From: Andre.Wendel@bmw.de <Andre.Wendel@bmw.de>
Sent: Monday, June 19, 2023 10:00 AM
To: Bjorkengren, Ulf (UB) <ubjorken@ford.com>; public-automotive@w3.org
Subject: Re: Consent support in VISSv2

I have the same view, that an external ECF should currently not be included inside the spec; Additionally there could be a best practice added beside, how an external ECF could be integrated, but I would suggest that an external ECF is not directly part of the standard maybe an extension of the token server?

Anyway, just my thoughts about a consent implementation;

The AGT and Access Tokens within the Token Server need to be mapped to a ClientID (which is required within the token request process) and to a VIN and in general are linked to a VISS purpose; Based on the flow the user accepts the purpose by granting a token so the user already know, to which data points he is giving his consent (this can be prompted inside the application screen by the workflow); otherwise if there is no full purpose acceptance the application won’t work, or why should an application have an larger purpose then required;

So each application in general has a clientID, e.g. if maps is an app it has his own ClientID, same as a music app and all tokens are linked to that specific client ID in combination of VIN or accepting user;

Based on the stored information within the token server, the user or car owner needs to be able to revoke the granted AGT and access token, so there must be the possibility to query all granted tokens of the VIN/User from the token server, by the owner of the VIN or the granted user; Based on these information the consent can be removed by disabling/removing all the related tokens to a corresponding ClientID;

All this could be done, if the Token server or the JWT Workflow is aware of the information within the defined purposes and the owner/VIN has access to list all tokens that are related too;

Based on the already existing roles within the JWT, the access or consent could be limited to cloud, vehicle etc. so every VISS server knows, if he is running on- or offboard, so he could easily drop requests just by checking if a client has a related device role;

Cheers,
André


Von: "Bjorkengren, Ulf (UB)" <ubjorken@ford.com<mailto:ubjorken@ford.com>>
Datum: Freitag, 16. Juni 2023 um 16:38
An: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Betreff: Consent support in VISSv2
Neu gesendet von: <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Neu gesendet am: Freitag, 16. Juni 2023 um 16:35

Sent from outside the BMW organization - be CAUTIOUS, particularly with links and attachments.
Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen von Links und Anhängen.
________________________________
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<mailto:peter.winzell@volvocars.com>>; Isaac Agudo Ruiz <isaac@uma.es<mailto:isaac@uma.es>>
Cc: 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

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