Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access token requires VIN even on onboard only use-case #425

Closed
aw-muc opened this issue Oct 19, 2021 · 5 comments
Closed

Access token requires VIN even on onboard only use-case #425

aw-muc opened this issue Oct 19, 2021 · 5 comments
Labels
VISS v2 Generation Two of the spec

Comments

@aw-muc
Copy link

aw-muc commented Oct 19, 2021

A few quotes:

(0)

The VISSv2 access control model is inspired by the concepts of OAuth2.0

(1)

The service may reside in the vehicle for applications needing to analyse a high volume of realtime data or on servers in the internet with information already brought off the vehicle.

(2)

Access control MUST be supported

(3)

The client MAY have to obtain an authorization token before being able to access the values. Arguments, of which path is mandatory …

(4)

Access Grant Request: The request shall contain the first three parameters below, the last is optional: VIN: The vehicle identification number. […]

If the server resides in the vehicle (quote 1) and an application, also in the vehicle, wants to access this server:

How is access control handled in this case?

Is the usages of the auth token optional (quote 3) or not (quote 2)?
If the application has to get an auth token, how would it know the VIN for the Access Grant Request (quote 4)?

How would a web application, running in a browser, know where the different servers (access grant, access token, VISSv2) are running (i.e. which hostname/IP and which port)?

@UlfBj
Copy link
Contributor

UlfBj commented Nov 1, 2021

If the server resides in the vehicle (quote 1) and an application, also in the vehicle, wants to access this server:
How is access control handled in this case?

The Abstract protocol flow shown in Fig 2 of the CORE spec should be applicable for all meaningful deployments of the Access Grant Token Server, Access Token Server, and VISSv2 server (Gen2 server).
The proposed change to make the VIN an optional parameter in the call to the AGTS (4), should simplify the scenario with all three servers deployed in the vehicle.

Is the usages of the auth token optional (quote 3) or not (quote 2)?

The access control is specified as optional, it is up to the implementer to decide whether it shall be used or not. There is also the access control selection feature that can be used to set access control to different signals.

If the application has to get an auth token, how would it know the VIN for the Access Grant Request (quote 4)?

How an application obtains the VIN is out of scope for the specification. For off-vehicle application deployments it seems rather natural that it shall have knowledge of which vehicle it wants to communicate with. For on-vehicle deployments it is as pointed out in this issue not so relevant that the application has explicit knowledge. Updating the spec as stated in (4) should therefore be implemented as I see it.

How would a web application, running in a browser, know where the different servers (access grant, access token, VISSv2) are running (i.e. which hostname/IP and which port)?

This is a relevant question which I think needs to be discussed in the WG before being answered.
I think it has to be analysed separately for the scenarios:

  1. Web application and AGTS deployed off-vehicle, ATS and VISSv2 server deployed on-vehicle.
  2. All four deployed on-vehicle.

@peterMelco peterMelco added the VISS v2 Generation Two of the spec label Nov 2, 2021
@aw-muc
Copy link
Author

aw-muc commented Nov 12, 2021

How would a web application, running in a browser, know where the different servers (access grant, access token, VISSv2) are running (i.e. which hostname/IP and which port)?

This is a relevant question which I think needs to be discussed in the WG before being answered.
I think it has to be analysed separately for the scenarios:

Web application and AGTS deployed off-vehicle, ATS and VISSv2 server deployed on-vehicle.
All four deployed on-vehicle.

Related to the scenario above I have an application running inside my on board browser e.g. a PWA, which is more or less an "off-board application", how could this application determine the VIN? You mentioned above that an off board application should be aware of the VIN it tries to access, but for the customer/developer the app is more or less running onboard and within that use case it is hard to determine the VIN.

@UlfBj
Copy link
Contributor

UlfBj commented Nov 19, 2021

@aw-muc PR431 makes the VIN optional in the AGTS request, and in the AGT/AT.
Does that solve your problem

@aw-muc
Copy link
Author

aw-muc commented Nov 22, 2021

Yes, I think that will work, but only if the AGTS is also deployed on localhost, otherwise a local application could requests tokens for other purposes or vehicles; Nevertheless, in future it would be nice if there would be standard for a browser API or anything else that supports the recognition of the VIN inside the vehicle.

is there anything planed outside VISS? Or could this be an update to later VISS versions?

@UlfBj
Copy link
Contributor

UlfBj commented Nov 23, 2021

but only if the AGTS is also deployed on localhost, otherwise a local application could requests tokens for other purposes or vehicles

That depends on the AGTS implementation. Just because the VIN is optional in the request, it does not mean that the AGTS must accept all such requests.

What comes in the next version we will see then.
You are very welcome to join and push for this at that time:).

@UlfBj UlfBj closed this as completed Dec 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
VISS v2 Generation Two of the spec
Projects
None yet
Development

No branches or pull requests

3 participants