How to know URLs of the different servers?

[UlfBj]

From Issue 425:

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.

[tguild]

Discussed on call how we covered in VISSv1, a well known URI
https://www.w3.org/2021/11/09-auto-minutes.html
Problem is not unique to Auto, looking for conclusion of cross group discussion found this draft from WoT group
https://www.w3.org/TR/wot-discovery/

[peterMelco]

Ok, this is really important I would think that we need to invoke the VISS server somehow...either by providing a proxy api or by handing back a configuration. Putting on the hat of a client implementor they really only want to worry about this once across OEMS.

[UlfBj]

I think the port numbers used by the different servers should be standardised.
The example below uses the default ports for HTTPS and MQTTS. As the default port for WSS also is 443, 6443 is proposed, for same reason 7443 and 8443 are proposed.
VISSv2 server:

• HTTPS: 443
• WSS: 6443
• MQTTS: 8883
  AGT server:
• HTTPS: 7443
  AT server:
• HTTPS: 8443
  How a client obtains the IP address I think it should be out of scope for the specification, in the case of vehicle deployed servers.
  As the VSS path is used as a URI path component in HTTPS calls to the VISSv2 server, path components could be specified for the AGT and AT servers, e.g.:
  AGTS-path: /viss/agts
  ATS-path: /viss/ats
  For cloud deployment, the URI path is prepended with "x.y", where x.y is a reference to the Ecosystem owner.
  AGTS: https://x.y:7443/viss/agts
  ATS: https://x.y:8443/viss/ats
  VISSv2 server:
• HTTPS: https://x.y:443/
• WSS: wss://x.y:6443
  How a client obtains x.y is out of scope for the specification.

[peterMelco]

So, I don't understand why we open up for fragmentations over retrieving the whereabouts of the AGTS and ATS servers if we don't have to. Could we simply not add a standard way of asking the server ?

[erikbosch]

Concering ports - I have no problem in that the specficiation states a recommended/default port, but I assume that stating that port XXXX is mandatory to use could cause problems, that deployments by different reasons may want to select a different port. I.e. implementations are encouraged to use the default path/port, but should preferably have mechanisms to use a different path/port.

In #385 we discussed the possibility to ask the server for capabilities. Would it be possible to use the same or similar mechanism for asking for AGTS/ATS. Possibly even as a generic key-value method where you can ask (without authorization on VISS level) the VISS server and get back a list of key-value-pairs, possibly including both agts/ats info as well as information on proprietary extensions to VISS.

Possibly something like below

[
{"viss:agts":"https://agts.mycompany.com/somepath/:1234"},
{"viss:ats":"https://ats.mycompany.com/something:2345"},
{"viss:history_read":"true"},
{"viss:implementation":"MyCompany VISS Server Pro v 2.3"}
{"mycompany:feature_x_enabled":"true"}
]

This is based on the assumption that none of the information provided is confidential. But it would be possible to think of a solution where only a subset is returned if not token is provided. I.e. first you need to do a call to get agts/ats, then when you have the token you can call again and get the complete list.

[UlfBj]

@peterMelco,
To be able to issue a URL-inquiry to the server, the client need to know either its IP address , or its domain name (typically in- resp off-vehicle deployment).
When the client has this information, there is really no reason to go to the VISS server to get any further information. With the client having this information, my proposal defines the further parts of the complete addresses of the different servers. Without this information, I cannot see how a client can issue the request you are referring to.
I guess the fragmentation that you mention refers to the "x.y" domain name that the client needs to obtain?
This is a necessary "fragmentation", if different OEMs/fleet owners want to have their own access control ecosystems.

[UlfBj]

@erikbosch,
Regarding the VISSv2 server port numbers for the supported transport protocols, I guess we need to have at least one mandatory, to enable a client to issue an inquiry to it.
If one needs to be mandatory, I think it should be so for all the supported transport protocols.
That leaves the port numbers for the AGTS/ATS, which could be optional, and possible to obtain as you propose.

[erikbosch]

@erikbosch, Regarding the VISSv2 server port numbers for the supported transport protocols, I guess we need to have at least one mandatory, to enable a client to issue an inquiry to it.

Well if a client can handle VISS-server address as configuration, I believe they can handle port as configuration as well. And do we want to limit ourselves to that e.g. AGTS/ATS must be on the same address (e.g. https://x.y.com) as the VISS-server. Can it not be totally different, like https://some.other.company.com:7654/some/other/path

[UlfBj]

And do we want to limit ourselves to that e.g. AGTS/ATS must be on the same address (e.g. https://x.y.com) as the VISS-server.

The VISS server is typically deployed in-vehicle, addressed by an IP address, and the AGTS off-vehicle, addressed by a domain name.

The solution might be to have an optional "recommendation" of ports and IP/domain address patterns, and then say that it can be overridden by "configuration" data, where the provisioning details are out of scope.

[UlfBj]

Fixed in PR433