[Returned for Revisions] SDL 0158 - Cloud App Transport Adapter

[theresalech]

Hello SDL community,

The review of the revised "SDL 0158 - Cloud App Transport Adapter" begins now and runs through May 1, 2018. The original review of "Cloud App Transport Adapter" occurred April 11 - April 17, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/1476b3de4797685d434e8206b6fac4a943baba7c/proposals/0158-cloud-app-transport-adapter.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/452

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

[yang1070]

In general, I like the idea of cloud app and adding a new cloud app adapter. But I’m not quite agree the details of the workflow. Here are some random thoughts.

Let’s review how an iOS/Android customer use a mobile application. The customer shall go to the app store (secure log in), find the app, purchase & download & install the app, register a new (reuse an existing) account if needed, then finally use the app, the app may need authenticate the account. App stores play a very important role. What’s the equivalent part for app store in the sdl cloud apps scenarios? The sdl server or a new standalone server component? What’s the equivalent part of app installation?

Policy Updates regarding cloud app list

• Option 1: The sdl policy server sends the whole (all available) cloud application list to all vehicles in the policy update. (probably not, as the driver will see all the cloud applications in the vehicle and some of them may not be used even once, but the sdl core still has connections to every cloud application in the list and get them registered according the workflow in the proposal)
• Option 2: The sdl policy server send the whole cloud application list to the vehicle, but HMI does not show them initially. We need something like find/install cloud apps api between core and HMI, which allows the driver to choose from the list for the apps that can automatically set up connections by SDL (described in the proposal). Later on sdl open set up connection for those virtually “installed” cloud applications and HMI only shows those selected and connected cloud apps. (user “installs” the app via HMI)
• Option 3: The sdl policy server sends selective cloud applications to a vehicle according to some kind of opt-in (per customer, per vehicle). Does the sdl server need the capability to manage per app developer, per customer and per vehicle, for example what cloud applications are available to what set of customers/vehicles, has the customer virtually “purchase & install” an app in the app list for a vehicle. A user can chose what apps to install on physical mobile device, does he can do it for cloud apps? Is there a whole new component in the sdl framework that does all of this and it just gives the results to a sdl server? (this means OEM controls/pusblish the cloud app list, a user needs to have an account with the new server component, and “install” the apps via web interface in his/her account)

Workflow

• Shall HMI see the cloud applications that has already has app interface registered as proposed? (Workflow: Activate the app via HMI “after” socket open and start RPC.)
• OR HMI can see the cloud applications that are allowed by policy server? (workflow: Activate “before” the socket open and start RPC)
• The workflow does not describe how to “activate your device” (the sdl module in vehicle).
• Does SDL store some user/account/activation status info locally?

Security.

• Communication between a cloud application and the vehicle shall be secure at all time. SDL shall enforce the ssl/tls connection. There should be no unsecured RPC connections in production environment. SDL shall only use unsecured connection for development stage and debugging purpose, not in production.
• How can sdl core authenticate a cloud app? Does the cloud app need a certificate assigned by the policy server like regular sdl navigation apps?
• Clearly, VIN is a PII data. it needs protection. It is OK to use VIN (or hashed VIN) as an ID of a vehicle. But It is not a good ID for a customer.
• How do we allow cloud app authenticate a user account (not a vehicle)?

• "endpoint": https://10.0.0.1:8080

• Probably IP is not a good candidate for the end point. We may need domain names insteady. Like https://some.com:8080 . Because one domain name can have multiple IP address. Certificate usually bind to domain name, not IP address.

255 is not big enough for a certificate.

[joeljfischer]

I have a few concerns about this proposal:

Connection Process

• Nothing in this proposal seems to address how apps will appear on the head unit. It seems to imply that all web apps which are available will appear on the head unit.

• Showing a prompt telling the user to do something while they are driving, like the Activate Your Device prompt, should not occur in a driving situation.

• Do all web apps get started and a persistent websocket connection started upon starting the drive, or only when selected? If a popular app were active in a good number of cars, I could see the number of persistent websocket connections for a web app's server causing issues. Their mobile app probably works on a REST, or REST-like manner, and the socket connection is likely to be much costlier in resource usage and perhaps monetarily (if they pay for something like AWS).

• Perhaps a companion app solution (per OEM) for configuring which apps you want to appear and requiring those apps to be configured before they appear would be best.

Potential Downsides

OEM must maintain extra set of policy related data (Endpoints and certificates). If an endpoint becomes outdated, head units will try to connect to an unknown endpoint.

I think we'd need to enforce a set of rules around this. If the app doesn't appear for the user, this may be confusing, but if the connection or the endpoint go down, we need a user-friendly way to tell the user.

It might be easy to fake the VIN and impersonate another user. A different form of identification could be used if this is a major concern.

Using the companion app solution, perhaps the app would have to be connected, and the username / password would need to be passed along with the VIN? Then we would certainly need an encrypted connection. Additionally, what happens when a user sells their car?

Adding a new Javascript proxy library means another major repository must be developed and maintained. This effort requires new feature development, issue tracking/bug fixes, creating documentation.

Given the amount of development the mobile libraries have taken, the impact of this should not be overlooked.

Additional Notes

• If this were accepted, I think we'd need to maintain an example web app and we'd need to the ability to easily debug and test this as well; only production cases seem to be covered in this proposal.

[Jack-Byrne]

@yang1070 Thank you for the feedback.

Regarding:

Policy Updates regarding cloud app list

Option 1: The sdl policy server sends the whole (all available) cloud application list to all vehicles in the policy update

Regarding option 1: I agree that this option would not be ideal and would just annoy the user.

Option 2: The sdl policy server send the whole cloud application list to the vehicle, but HMI does not show them initially

Regarding option 2: I think this would be the best option. I believe this flow would require 2 additional HMI RPCs not included in the proposal.

• A request from HMI->Core to get the list of cloud app names included in the policy table. This information could be displayed to the user for them to select Enable/Disable for each listed cloud app.

<struct name="CloudApplication">
     <param name="appName" type="String" maxlength="100" mandatory="true">
     <param name="appID" type="Integer" mandatory="true">
     <param name="enabled" type="Boolean" mandatory="true">
</struct>

<function name="GetListOfCloudApps"  messagetype="request">
     <description>Request from HMI to SDL to get list of cloud app names that are listed in the policy table</description>
</function>

<function name="GetListOfCloudApps" messagetype="response">
     <param name="applications" type="Common.CloudApplication" 
     mandatory="true" array="true" minsize="0" maxsize="100"/>
</function>

• A notification from HMI->Core sent when a user chooses to enable or disable a cloud app from the list returned in the previous RPC. By default all cloud app connections would be disabled, but when an app is enabled by user, Core would initiate a connection to that cloud app and then save the enabled state into the policy table so that the app would also be connected on future ignition cycles.

<function name="OnAllowCloudApplication" messagetype="notification">
        <param name="appID" type="Integer" mandatory="true">
        <param name="enabled" type="Boolean" mandatory="true">
</function>

Option 3: The sdl policy server sends selective cloud applications to a vehicle according to some kind of opt-in (per customer, per vehicle)

I believe this option would require a lot of extra components and complexity for managing users list of apps without adding any benefits that option 2 can't solve by itself.

Managing cloud app connections on directly on the head unit should be pretty "light weight" since the information stored for each app is just connection data. It should not be difficult for the hmi to display a list of possible cloud app connections and for the user to select enable/disable.

Regarding:

Workflow

Shall HMI see the cloud applications that has already has app interface registered as proposed? (Workflow: Activate the app via HMI “after” socket open and start RPC.)

OR HMI can see the cloud applications that are allowed by policy server? (workflow: Activate “before” the socket open and start RPC)

I believe Activate the app via HMI “after” socket open and start RPC would be the preferred method because if the app is displayed then you know there is an active connection with the cloud server. However with the new RPCs I proposed above, an SDL integrator could technically do either of the two workflows you mentioned.

The workflow does not describe how to “activate your device” (the sdl module in vehicle).

If the web app does not recognize the VIN, the web app must send a show with the following message:

`Activate Your Device
Code: 12345
Visit www.appwebsite.com/activate`

The user must go to the applications website and register their connection before the web app can be used.
This method of authentication uses a similar flow for activating streaming services (ie Roku/Apple TV -> Netflix)

Any further details regarding this process I believe would be outside the scope of this proposal since the 3rd parties creating these cloud apps would implement their own device activation procedure.

Does SDL store some user/account/activation status info locally? No, not according to the proposal in its current form.

Security

Communication between a cloud application and the vehicle shall be secure at all time. SDL shall enforce the ssl/tls connection. There should be no unsecured RPC connections in production environment. SDL shall only use unsecured connection for development stage and debugging purpose, not in production.

Agreed

How can sdl core authenticate a cloud app? Does the cloud app need a certificate assigned by the policy server like regular sdl navigation apps?

Core relies on the policy server to supply accurate cloud app connection data. And yes I believe cloud apps should be assigned certificates similar to sdl nav apps.

Clearly, VIN is a PII data. it needs protection. It is OK to use VIN (or hashed VIN) as an ID of a vehicle. But It is not a good ID for a customer.

I would like to change the proposal to use the Hashed VIN as the preferred ID method. Is there a specific reason you believe this to be a bad ID?

How do we allow cloud app authenticate a user account (not a vehicle)?

The proposal originally intended for a vehicle to be directly linked to one user account but this doesn't work well in case a car is shared between multiple drivers. Maybe it makes sense to involve user account authentication via username and password info entered by the user directly on the head unit. If entering login information on the head unit is preferred then the proposal will need revisions.

"endpoint": https://10.0.0.1:8080

This url was a placeholder but I can revise the proposal to be more specific on the format of the url.

[AndrewRMitchell]

I read this last week on Friday, but let it percolate in my mind until today. These comments are in addition to the ones mentioned above (to not duplicate feedback, except where it made sense to do so). And take into account the reply from Jack as well. That being said, don't take the size of this response as being negative on the idea. I'm not, I love the idea. I am just pointing out the things that need to be thought about before the idea can be realized.

1) App discovery - No matter what the implementation details are, long term maintainability suffers if the primary source of discoverability is the HMI. Unless you're planning on implementing an App Store in the HMI, as this list grows and changes managing it through simple lists on the HMI is going to become cumbersome and confusing for the users.

I like the idea of being able to set these through accessory Apps (either manufacturer provided, or developer provided). Allowing the Manufacturer to provide the App interface gives them control over the Apps they want to expose and the type of UI in ordered to find them. Having the developer provide them, lets me add "Web" apps to the HMI from my SDL App. Weather the Web app is a compliment to my SDL App, or simply replaces the functionality for when my phone isn't present in the Car, thats up to me.

And this should be an allowable "mode" for Web apps, only have them run if the previously run SDL App isn't present. This concept is obviously missing from the existing proposal.

2) User authentication - Since we're only talking about transmission over a secure connection to begin with, a hashed VIN is probably manageable from a PII standpoint. That being said, from a Web app side, a hashed VIN does present some problems. First, my infrastructure is probably already all in place and developed around some sort of token mechanism. Having to change this to also support using a hashed VIN may be a significant amount of infrastructure work in ordered to get running. And then there are things like forced refresh. I can't force the VIN on a vehicle to change. The VIN is the VIN no matter what.

Taking this a bit further, if you're going run with a VIN based mechanism, how do I distinguish between users? If you're car is truly multi-user, I can imagine vendors implementing some mechanism of identify the driver to these Web apps, similarly to how they have different seat positions, etc. If you're only using the VIN, there is no built in way to identify different users. With a phone, the phone is providing the users identity. Without the phone, how is the users identity being made available?

3) App Type - Should there be some limit on the type of App allowed in the cloud? I.E. it probably doesn't make sense for projection Apps to be run from the cloud. But how about Apps accessing the car's microphones? Streaming to the Car is an obvious use case for this for things like Internet Radio, but how about streaming from the car to cloud for uses like communications Apps or voice assistants? I fear that not specifying what's specifically allowed in these use cases will have people pushing the edge as to what is actually providing a user benefit.

3A) API Type - are there any API's that simply don't make sense in this environment? How about API's that need to be added to help maintain this environment?

4) JavaScript - just asking the question here, is JavaScript the best language to write the client connector in. To most HU's have a JavaScript interpreter or run time in them? Again, this is as much about my lack of knowledge of what's on the HU as any dislike I have of JavaScript to write a networking layer in.

5) Connectivity A) Temporary Connectivity Loss - what is the prescribed behavior if connectivity loss occurs while driving? How is momentary loss (downtime from switching, driving in a city, etc), vs temporary loss (driving through a tunnel without repeaters), vs more permanent loss (driving out of a coverage area) handled. These are things that from a high level I don't think should be left up to the implementation.

B) Multiplexing (or more specifically channels) - what mechanisms will be used to deal with up and down control channels vs up and down data channels? Are we assuming HTTP/2? Multiple connections? Custom multiplexing? Managing the complexity of this should not be left to an implementation detail.

C) Connections - are all connections always initiated from the car side of the world? What happens if the Web is bounced while the connection is active, does the Web app need to wait for the car to reconnect? Does the car automatically try to reconnect? If so, after what delay, and how often before it gives up. In a way this is related to connectivity loss (see above).

D) Connectivity - how are these long lived connections maintained (assuming that indeed we have long lived connections and that server can not initiate new connections to the client?

6) Audio Streaming - Are all the control events that would be sent locally also sent remotely? (I assume so, just asking) More importantly how is channel priority handled when one of the channels is remote, and hence my have a high latency for responding to such commands.

In summary, again I like the idea of this proposal. I just don't think the above questions should be left to implementation details (except for maybe number 6).

[Jack-Byrne]

@joeljfischer

Nothing in this proposal seems to address how apps will appear on the head unit. It seems to imply that all web apps which are available will appear on the head unit.

Please see my comment above that expands on @yang1070 's "Option 2"

Showing a prompt telling the user to do something while they are driving, like the Activate Your Device prompt, should not occur in a driving situation.

If the cloud app gets an OnDriverDistraction notification while the sdl module has not been activated, the cloud app could send an UnregisterAppInterface

Do all web apps get started and a persistent websocket connection started upon starting the drive, or only when selected? If a popular app were active in a good number of cars, I could see the number of persistent websocket connections for a web app's server causing issues.

After doing some quick searching it seems like you can maintain hundreds of thousands websocket connections using AWS. Disclaimer: I am not a network engineer and can't verify the validity of these articles/blog posts. M3.xlarge 620k idle connections. 100K concurrent connections in a t2.medium instance

Their mobile app probably works on a REST, or REST-like manner, and the socket connection is likely to be much costlier in resource usage and perhaps monetarily (if they pay for something like AWS).

I can't speak to the cost efficiency of managing web socket connections vs using a REST api.

Any network engineers able to comment on Joel's network questions?

Perhaps a companion app solution (per OEM) for configuring which apps you want to appear and requiring those apps to be configured before they appear would be best.

This is a possible solution. The same thing could be accomplished on the head unit removing the need for an app. However the companion app might be a better user experience for entering account information

I think we'd need to enforce a set of rules around this. If the app doesn't appear for the user, this may be confusing, but if the connection or the endpoint go down, we need a user-friendly way to tell the user.

The HMI could use GetListOfCloudApps (described in comment above) to see list of enabled apps that SDL should be connected to. If those apps are not included in the UpdateAppList from Core, then the HMI should be able to deduce that there is a connection problem and notify the user as such.

Using the companion app solution, perhaps the app would have to be connected, and the username / password would need to be passed along with the VIN?

I do not think that a companion app connected to the head unit should be required to use cloud apps. I believe the main benefit of having cloud apps to be that the user does not need to connect their phone to the head unit to use SDL applications. The user could enter their information directly into the head unit.

If this were accepted, I think we'd need to maintain an example web app and we'd need to the ability to easily debug and test this as well; only production cases seem to be covered in this proposal.

Agreed. Sample web app should be created, but the javascript proxy library needs to be created first.

[joeljfischer]

Audio Streaming - Are all the control events that would be sent locally also sent remotely? (I assume so, just asking) More importantly how is channel priority handled when one of the channels is remote, and hence my have a high latency for responding to such commands.

I just realized that @AndrewRMitchell's comment here is important. How would media apps work without a generic media connection? Would we have to build a "downloading audio file and playing" mechanism? Are we assuming they'll stream audio data over a socket, or do we just not allow media apps?

[Jack-Byrne]

@AndrewRMitchell Thank you for the feedback. I did not see you posted your comment until after I posted my previous comment.

Regarding:

App discovery User authentication

These seem to be problems highlighted in all the comments. Using the phone with a companion app to set the list of users cloud apps and authentication credentials seems to be the easiest solution. I still do not think this companion app should be required to use the cloud apps every time the car is started. If the companion app is only needed to do the initial setup for the user then I would agree with this approach. Edit: The information supplied by the initial companion app configuration would be stored on the head unit for future use. The OEM app could always be reconnected to the head unit to reconfigure for different users.

App Type - Should there be some limit on the type of App allowed in the cloud?

This is be configurable through the OEM's policy table. The existing mechanism for enforcing app types would apply to cloud apps the same way they do for mobile SDL apps. If an OEM has a system in place where they can reliably perform an audio pass thru to a cloud app then they could allow this RPC via policies. If another OEM's system does not have a good user experience for this RPC, they can disallow that RPC for that specific cloud app.

API Type

Similar response for APP type. This mechanism already exists in policies. In the OEM's policy table they can create a functional group that contains the RPCs they want to allow for web apps. Then in the policy server they only assign that functional group to connected web apps.

JavaScript

Sorry if there is some confusion here but Javascript is not running on the head unit. The proposal mentioning javascript was a suggestion for the language the cloud app proxy would use.

Connectivity

In the case of a connection loss, the head unit would attempt to reconnect to the cloud app. I agree this step is important and will need further details especially on how connection errors are displayed to the user. As for longer and more permanent connection loss, the web apps will simply be unusable.

Multiplexing

This sounds like it would be specific to the OEM head units hardware and outside of the scope of SDL Core.

What happens if the Web is bounced while the connection is active, does the Web app need to wait for the car to reconnect? Does the car automatically try to reconnect? If so, after what delay, and how often before it gives up. In a way this is related to connectivity loss (see above).

My suggestion is: If the connection is broken the vehicle will immediately attempt to reconnect. If that connection is failed, the vehicle will attempt to reconnect at OEM defined timeouts. This timeout sequence could be defined in the policy table module_config as such. The head unit would stop connection retries after reaching the end of the retry timeout array.

"cloud_app_connection_retry" : [1, 5, 25, 125, 625]

Audio Streaming - Are all the control events that would be sent locally also sent remotely? (I assume so, just asking) More importantly how is channel priority handled when one of the channels is remote, and hence my have a high latency for responding to such commands.

I think this comment is implying that an app on a phone could be used in conjunction with a cloud app, which was not the intent of the original proposal.

[Jack-Byrne]

@joeljfischer

Audio Streaming

Downloading and playing media would probably not be the best performance wise. Streaming the audio similar to how NAV apps stream audio might be necessary for cloud media apps if we decide to enable audio streaming functionality at all.

[yang1070]

I also have concerns about the long lived connections, not only the number of connection that an application server can support but also on the vehicle side. For every cloud app listed in the policy (or enabled apps), no matter it is used or not, there is a socket connection between the vehicles and a cloud server in order to get the app registered and remains in the HMI. Even the app has never be activated in the HMI, sdl still need to keep the connection alive.

I would like to see a REST API module(s) act as a proxy between the app and SDL.

[nickschwab]

@yang1070 Thanks for sharing your concerns.

Due to the frequency of payloads both from the vehicle to the application server and from the application server to the vehicle, I believe websockets would be the ideal connection method. Websocket connections are lightweight, designed for real-time bidirectional throughput, and avoid the repetitive network latency which is accrued through REST-based implementations.

The concept of apps maintaining a connection with the vehicle even if the app is not in use is already a fundamental behavior of SDL integrations between smartphone apps and Core. Since SDL is a real-time event-emitting platform, maintaining a constant connection between applications and Core is vital to the intended product offering, regardless of whether the application resides on a smartphone or on a web server.

Application developers may opt to build their websocket host in a variety of ways to handle expected load based on their business case, e.g. load balancing, microservices, etc.

[theresalech]

The Steering Committee voted to return this proposal for revisions, to reflect the comments left on the review issue. One of the biggest revisions includes using websocket connections to connect the head unit to the cloud servers, as this was deemed to be the most cost effective and lightweight solution. To reduce the amount of data sent back and forth, the connections will only be open when app is active (when onAppActivate is sent, when app is not in HMI_NONE). The revision will also consider additional data sent over cloud apps, as compared to what's currently sent for maintenance. Another large revision to this proposal will be including details on a how a companion app can be used to authenticate user accounts and determine which apps should be displayed on the head unit, using updateAppList. Within a policy table entry or companion app provided table there could be base registerAppInterface request information, so that chosen apps can appear on the head unit even though they might not have a websocket connection open yet.

This review issue will remain unlocked per the author's request, to allow any additional feedback from members that should be incorporated into the revisions.

[theresalech]

This proposal has been updated to reflect the requested revisions, and the revised proposal is now in review until May 1, 2018.

[joeljfischer]

5. Cloud app verifies login credentials and stores hashed VIN for future use.

Is the hashed VIN still necessary if the user enters login credentials? Can everything be done with the secret token? How do we deal with shared / sold cars? We need to mandate a good way of clearing this information.

6. Cloud app responds to OEM app store with a secret token that will be used to authenticate SDL Core's future websocket connection

How should Core store these secret keys? In the proposal it's in the JSON policy, however, that doesn't seem secure enough. What could happen if someone got access to that key?

[Jack-Byrne]

@joeljfischer

Is the hashed VIN still necessary

If a cloud app requires user login, both the hashed VIN and the secret token are used by the cloud app servers to authenticate incoming connections.

If a cloud app does not require user login, there will be no secret token to send. In this case the hashed Vin should still be sent when the connection is created so the cloud server can still identify the head unit.

How should Core store these secret keys?

A production head unit should be using an encrypted policy table, therefore all secret tokens should be stored within the encrypted policy table.

[Jack-Byrne]

As for how to deal with shared or sold cars, that will be up to the implementation of the OEM app.

As an example,the user goes into their "OEM App Store" on their mobile device and selects to "log out of all SDL cloud app accounts". The OEM app could make post requests to all enabled cloud app servers to invalidate that users secret tokens for a specific vehicle (hashed vin).

[kshala-ford]

I read the the proposal and tried to follow the conversation before and after the revision. I might not understand the full proposal but I got stuck at the user/vehicle authentification where I mostly struggle with followed by vehicle identification.

3. If the cloud application requires user authentication, the user will enter login information or complete OAuth Device Flow

• What user authentification are we requesting? The auth needed for the app store? or the auth needed for the app service itself?

I understood the user credentials for the app itself...

• Who decides that the app requires user authentification? Is there a flag in the OEM's App Store?
  • If yes: Does the OEM need to add HMI logic for user and password credentials?
  • If no: Does the app perform a keyboard interaction to request input?

I believe the answer is "yes" but that's not clear to me. If that's true I need to quote @AndrewRMitchell 's comment above

User authentication - Since we're only talking about transmission over a secure connection to begin with, a hashed VIN is probably manageable from a PII standpoint. That being said, from a Web app side, a hashed VIN does present some problems. First, my infrastructure is probably already all in place and developed around some sort of token mechanism. Having to change this to also support using a hashed VIN may be a significant amount of infrastructure work in ordered to get running. And then there are things like forced refresh. I can't force the VIN on a vehicle to change. The VIN is the VIN no matter what.

Usually every partner has their own way of storing the hashed password. I'm not a pro in web based user authentification but I don't believe the head unit should do user authentification as we don't know what algorithm sits behind the app's user authentification.

Instead I would see the app presenting the keyboard if the cloud app wasn't able to identify/authenticate the user. Which means the app store doesn't do user authentification

4. Auth information is sent in a post request from OEM app store to cloud app server with hashed VIN

I wouldn't specify the need of the hashed VIN. According to GPDR a VIN (even if it's hashed) could be used to identify the user which can be a legal issue. Not specifically for the OEM but for the app partner who's in charge of taking care about the regulation. I've asked the Ford EU commisioner for input on this. The issue might be solved by a simple addition to the partners T&C.

Instead I would specify "a randomly generated hash" e.g. a hash based on VIN and a pseudo-random number per master reset. If the vehicle allows user profiles a user profile identifier should be included.

This way the apps can be user (not vehicle) dependent. Furthermore the hash stored by the cloud app service is useless after a master reset which increases data privacy.

7. User connects phone to headunit, OEM app registers and sends updated list of enabled cloud apps and corresponding secret tokens.

I'm not sure about the need of the phone. I thought the proposal is about cloud apps without using phones. May be I'm missing something...

May be it makes sense to create a flow for "High level overview of connection process and authentification" like you did for "Transport Adapter Connection Flow".

[joeljfischer]

What user authentification are we requesting? The auth needed for the app store? or the auth needed for the app service itself?

The app itself

I believe the answer is "yes" but that's not clear to me.

Yes, unless the OEM's app store is an within the OEM's mobile app.

Usually every partner has their own way of storing the hashed password. I'm not a pro in web based user authentification but I don't believe the head unit should do user authentification as we don't know what algorithm sits behind the app's user authentification.

The recommended way is an OEM app containing the app store. I understand the concern here, but it would primarily be a username / email & password combination. This could get trickier with 2 factor auth and we would need to account of it in the head unit "app store" or mobile app store.

I wouldn't specify the need of the hashed VIN. According to GPDR a VIN (even if it's hashed) could be used to identify the user which can be a legal issue.

I'm not convinced we need the VIN. Why wouldn't the secret token be enough? If it's not enough, your suggestion of a reset of the hash by master reset would be a good one.

I'm not sure about the need of the phone. I thought the proposal is about cloud apps without using phones. May be I'm missing something...

I think the part missing here is that the OEM app could have the "app store". This would allow the user to authenticate their apps ahead of time, when they "activate" it for use in the car. e.g. iHeartRadio has a cloud app, the user goes into "FordPass" and activates it for SDL. It then prompts the user to login via a native or web-based OAuth flow. The user does, the app stores the secret key and passes it to the head unit's policy table. This is a much nicer UX for the user than to input on the head unit itself.

[BrettyWhite]

I'm not convinced we need the VIN. Why wouldn't the secret token be enough? If it's not enough, your suggestion of a reset of the hash by master reset would be a good one.

I believe he is talking about the API token for the service that was auth'ed for use with the compatible cloud app. For example, say i OAuth with a popular music service. When the cloud app is launched, It will send the requests to the service's back end with my API token to let me access my subscription. That would need to be attached to a user (car), hence the need for the VIN.

[Jack-Byrne]

@kshala-ford

What user authentification are we requesting? The auth needed for the app store? or the auth needed for the app service itself?

Auth for the app service itself. For example, singing into your pandora account.

Who decides that the app requires user authentification?

Most likely the cloud app server.

Is there a flag in the OEM's App Store?

This would depend on an OEM's App store implementation, which i think is outside the scope of this proposal.

I wouldn't specify the need of the hashed VIN.

According to the proposal the "Hashed VIN" value is read from a file path set in the smartDeviceLink.ini. If there are legal issues around using a VIN or a hashed VIN, then the OEM can put any other uniquely generated string in that file. How the head unit resets / regenerates the contents of that file on a master reset is up to the OEM's implementation.

I'm not sure about the need of the phone. I thought the proposal is about cloud apps without using phones. May be I'm missing something...

It was requested in the previous comments for the ability to use the mobile device to enable an "App Store" to enable cloud apps. The commenters expressed concerned that limiting an app store to the head unit would be a bad experience. The step you are referencing would only be required as a configuration step to get newly enabled/authenticated apps to show up on the head unit. On future ignition cycles the user won't have to connect the OEM app store to the head unit to use the cloud apps.

[joeljfischer]

@brettywhite

I believe he is talking about the API token for the service that was auth'ed for use with the compatible cloud app. For example, say i OAuth with a popular music service. When the cloud app is launched, It will send the requests to the service's back end with my API token to let me access my subscription. That would need to be attached to a user (car), hence the need for the VIN.

Maybe I'm just totally not understanding. I don't see how the VIN is needed in this at all. In a traditional OAuth flow, you need username / password and you get an access token. How are our needs different from the traditional flow in that we need an additional user identifier?

[BrettyWhite]

Ahh @joeljfischer

When I originally was looking over this, there was an idea to use the sdl server / policy server to store and sync this information to allow a phone-less sync between a mobile OEM app store and an Internet connected HU. In that case, the remote policy server would need to keep that reference.

I re-read the proposal and specifically these lines:

7. User connects phone to headunit, OEM app registers and sends updated list of enabled cloud apps and corresponding secret tokens.
8. Core stores secret tokens in the policy table and updates the enabled field of the cloud apps listed in the policy table.

It seems as if that idea was dropped and the syncing is to take place with a phone and HU directly. In that case, you are correct I don't see the need for it. If it is changed or expanded in the future to sync remotely, then it would be needed.

[joeygrover]

It seems as if that idea was dropped and the syncing is to take place with a phone and HU directly. In that case, you are correct I don't see the need for it. If it is changed or expanded in the future to sync remotely, then it would be needed.

This is not necessarily true. The proposal should have had a qualifier that stated: "If the app store is to reside or be synchronized through a mobile phone...." for those steps. Therefore an OEM can still implement an app store in the cloud that syncs with a headunit using this hash as a tie between oauth tokens and vehicles. The module could then request that list from the cloud backend using the hash and obtain the tokens. That is the idea behind this solution, that it supports all possible scenarios of app store locations and ability for synchronization.

[Jack-Byrne]

@joeljfischer In the case a cloud app does have a user account authorization, then there will be no secret token created. The hashed VIN would serve as a unique identifier in case there is no secret token created through the user authentication process. To make this more agreeable we could say that the hashed Vin is not mandatory and the file path set in the ini file can be left blank or point to an empty file. It would be up to the integration of the OEM's ecosystem if it makes sense for them to use the hashed VIN or not.

@brettywhite The phone less-sync between the app store and head unit is still possible given the proposal. If the OEM wanted to, secret tokens and enabled apps could be delivered through policy table updates. However the main use case example given in the proposal uses the phone app store method.

[kshala-ford]

@joeljfischer @JackLivio I believe I caused some confusion for the hashed VIN. Let me try to explain:

First of all I guess we are mixing up identification, authentification and authorization. To my understading "hashed VIN" should be there for identification and the user credentials for authentification (and authorization). For some apps the identification could be enough without the need for auth.

I was saying that using VIN as an identification token could be a legal issue. That's why I wanted to propose to not call it "hashed VIN" but "identifier token". The token could be anything and wouldn't necessarily be related to VIN. The token could be generated by the OEM/HMI out of many different input values like VIN, user id, app id, random id generated by last master reset... What i want to avoid are things like:

• identification issues for people sharing a car (user identification). Think of two people sharing a car but don't want to share their preferences.
• identification of users after the car was sold (reset id after a master reset). I'm afraid if the buyer (re-)installs a cloud app this app could wrongly identify the new user as the old user
• identify what other apps are installed in a car. Each app should have the own identifier to protect the privacy of a user

That's about identification. Regarding Authorization I still think the app store should not ask for user auth.

Usually every partner has their own way of storing the hashed password. I'm not a pro in web based user authentification but I don't believe the head unit should do user authentification as we don't know what algorithm sits behind the app's user authentification.

Instead I would see the app presenting the keyboard if the cloud app wasn't able to identify/authenticate the user. Which means the app store doesn't do user authentification

[yang1070]

Since Core itself does not store the VIN, the hashed VIN must be supplied by the HMI. The path to where this value can be found on disk should be set in the smartDeviceLink.ini config file.
[Cloud App Connections]
...
;File path that contains the Hashed VIN to be used in cloud app authentication
HashedVINPath=cloud_id.data

I agree the hashed VIN must be supplied by the HMI, however, VIN number is unique per vehicle.

I would rather like a RPC between SDL core and HMI to retrieve hashed VIN ( or an equivalent random number per vehicle) than the method of generating a data file with different content for each vehicle. Suggest to (1) either reuse the RPC GetVehicleData with the existing parameter vin, which already allows an app or SDL core read VIN number from the HMI, and SDL core can calculate the hash. (2) or add a new parameter hashedVin or cloudAppRandVehicleId to the GetVehicleData RPC.

[Jack-Byrne]

@yang1070 Thats fine I can agree with option 2, but note that this would create a disconnect between enums represented for GetVehicleData in the Mobile API and HMI Api if the new parameter is not used by the Mobile RPC spec. Also this parameter should be included in the HMI_API RPC OnVehicleData.

Lets call the new parameter "CloudAppVehicleID".

The RPC GetVehicleData(CloudAppVehicleID) will take place after Core starts and the VehicleInfo HMI component registers. Core will store the result in memory for future cloud app connections.

The RPC OnVehicleData(CloudAppVehicleID) will be sent by the HMI in the event that this ID value changes while SDL Core is in use. This would offer the flexibility of clearing the cloud app vehicle ID in case of changing vehicle ownership, or even switching between multiple driver profiles.

[yang1070]

In the proposal, the cloudAppAuthToken is the same for all vehicles of an OEM. It is not unique per vehicle. My understanding is that it is just an application key for a cloud service (in our case SDL service) assigned to an app. It shall not be the same token to authenticate SDL Core's future websocket connection.

To me, AppStore or companion app is for allowing an user to enable/disable web applications, or for control what web apps can be shown on HMI. Of course, AppStore or companion app itself have user authentication to an OEM's service. However, AppStore shall not handle user authentication to a web application in general.

Web applications shall handle user authentication by itself if it need one. A simple example might be the following. Assuming a web app need user name and password and some vechile identifier to log in, it may utilize PerformInteraction RPC to let a driver input user name and password (We may define better RPCs for user input) and getVechicleData RPC to get vechile identifier.

Since there is no web application code running in a vehicle, I assume a web application can save some session info via putFile RPC to a vehicle just like a website can store cookies in web browser. We may still need some new RPCs to allow the web app read cookies, such as a GetFile.

To avoid all those inconvenience, a web applications may adopt openID authentication. But in this case, we may need OEM's web service act as the identity provider and authorization service API provider.

[yang1070]

@JackLivio I would like CloudAppVehicleID is also in mobile API spec so that a web app can query it.

[Jack-Byrne]

@yang1070

cloudAppAuthToken

No this value is generated as a result of the user having a successful authentication through the cloud app store. This value is unique to the users account for that particular cloud app.

However, AppStore shall not handle user authentication to a web application in general.

Why not? Previous comments on the proposal stated that entering user login credentials on the head unit would be a "bad user experience", hence this revision.

I assume a web application can save some session info via putFile RPC to a vehicle just like a website can store cookies in web browser. We may still need some new RPCs to allow the web app read cookies, such as a GetFile.

Out of the scope of this proposal.

[Jack-Byrne]

please note edits made to my previous comment

[theresalech]

The Steering Committee voted to defer this proposal, keeping it in review until 2018-05-08 to allow additional time for SDLC Members to review and discuss. Any specific questions about the proposal should be left as comments on the review issue for the author to address.

In an effort to keep the discussion on this issue as clear and concise as possible, a summary of the items clarified in comments to-date as well as on the 2018-05-01 call can be found below.

• Planned revision: remove HashedVIN from ini file, and get it from the HMI via the current GetVehicleData request. HashedVIN parameter will be renamed to CloudAppVehicleID. Note that the OEM can decide how to set this value during their implementation.
• The token in the policy table is unique per user and per each cloud app. The value can come from the authentication steps outlined by the cloud app store or the OEM can set up a system for tokens to be delivered by their policy server (would require changes to the SDL Policy Server). This component is not required, and meant to be left open ended in the proposal, so that it can be adjusted as needed within OEM implementations.
• The proposal intends to abstract responsibility for authentication for cloud apps away from SDL, and allow this to be an OEM decision upon implementation. There is a field in the policy table to store the auth token that's obtained from the cloud app services themselves. That token is then used to authenticate the user on a vehicle for that service. The following authentication scenarios are available, as this proposal only specifies that we have a token to properly make requests: setCloudAppProperties RPC from the cloud app (1:1), a mobile app store via companion app, embedded app store in head unit, or synchronize tokens to the cloud in an enhanced policy server. Again, this is intended to be decided by an OEM, based on what works best for their implementation, and authentication process is entirely optional.
• There are two types of identification fields, both of which are optional, as this proposal leaves it open for web apps to be connected without either field:
  • CloudAppVehicleID: used for cloud app to identify connecting vehicle.
    • This is not mandatory, and if not implemented, Core will attempt to open a connection and not send the value when opening. If the resulting endpoint requires the field, the connection will fail.
  • CloudAppAuthToken: authorization token tied to the user (not vehicle) and obtained via authentication process, possibly used in the cloud app store. This provides authentication and identification.
    • This is not mandatory, and if not implemented, an app will proceed connecting without it, trying to open a secure websocket connection. If the resulting end point requires the field, the connection will fail.

[Jack-Byrne]

Example Use Case 1

This diagram describes the flow in which the user could enable the cloud apps they want to use in their vehicle by using an OEM Companion App.

Note: CloudAppAuthToken and CloudAppVehicleId are optional.

Pros:

• App store selection easier for the user compared to using the head unit.
• App store selection could take place while outside of the car.

Cons:

• Requires user to connect phone to configure cloud apps.

P.S. More example use case diagrams coming. I will post as I go.

[Jack-Byrne]

Example Use Case 2

This diagram shows how an enhanced policy server could be used to deliver enabled cloud app information to SDL Core by using the policy table update mechanism. This flow does not require the user to connect their mobile device to the head unit, therefore the OEM app store does not have to be implemented on a mobile companion app. The OEM app store could be implemented on a website instead.

Pros: Does not require the user to connect their device to the vehicle to configure cloud apps.

Cons: Adds complexity to the SDL Server.

Note: This flow uses two components that I am considering outside of the scope of this proposal and should be entered as follow up proposals.

• Proposal 1: Enhanced policy server that stores users' cloud app settings.
• Proposal 2: Allow Core to make policy table requests through an embedded http module.

[Jack-Byrne]

Example Use Case 3

This diagram shows how the OEM App Store could be implemented as a cloud app itself. Under the current proposal, the OEM could configure the preloaded policy table to contain the OEM app store server endpoint and have it be "enabled" by default. This way the OEM App store as a cloud app would appear on the HMI by default. The user could navigate this app store on the HMI to enable and authenticate other available cloud apps.

Pros: Device-less method to enable and configure mobile apps.

Cons: Requires OEM's to host a cloud app server which would be costlier than the other use case approaches.

[Jack-Byrne]

The purpose of these example use cases is to show how leveraging the existing policy table update mechanism and the new proposed SetCloudAppProperties RPC can create the possibility of having many different types of OEM Cloud App Store implementations.

[Jack-Byrne]

Example Use Case 4

This diagram shows how authentication for a specific cloud app can be contained within the cloud app itself. Login information is passed to the cloud app via a perform interaction.

This diagram assumes that the cloud app has previously been enabled through some other OEM App Store SetCloudAppProperties mechanism.

Pros: Does not require OEM App Store to handle authentication.

Cons: Requires the user to enter login information on HMI.

[AndrewRMitchell]

@JackLivio Thanks for providing these uses cases. These are some of the many things that I don't think should be left for implementation details. I really appreciate you specifying these. One use case that I think is missing would be Use Case number 5 (although it's really an extension of use case 1), SDL Apps register a Web service to be used in case the Device (Phone)/App is missing. I see this as a highly beneficial use case for many Apps.

=====

Other issues I see with this proposal, as I've previously called out and have not been addressed:

1) JavaScript as the primary language of the cloud adapter. I guarantee there companies here that will not allow JavaScript running on internal sites, and probably some that wouldn't allow it on an external site. Even though it's improving JavaScript is still one of the major target vectors of external attacks. And yet, here we are saying you'll have to run JavaScript as a connector.

2) Audio Streaming without some sort of management spec limits you to live streaming only, and will be problematic in spotty coverage areas. There should be a separate specification written around this area to at a minimum allow the HU to download the current song as quickly as network conditions would allow. Ideally, it would allow to begin downloading the next song while the current one is playing, and specify some basic playback configuration (like prohibiting returning to the beginning of the song or skipping to the previous song).

3) Taking Audio Streaming a bit further, I believe not restricting projection apps (or at least placing bandwidth requirements on them) is wrong. You will have people trying to push the envelope here, and in the end the user is the one that gets saddled with a sub-par experience.

4) Connection Issues from initiation to retry to multiplexing, I'm not really sure these should be left as implementation details. I get we want to use websockets, but just specifying this doesn't solve the technical details behind it.

Now these issues bring me to a bigger issue I have in general with how SDL and the SDLC looks at the whole protocol. And don't get me wrong with what I'm about to say, I understand why decisions like this are made in the first place when SDL was a closed system, and you're providing client plug-ins that do all the heavy lifting. But we're no longer in a closed system, we're trying to make a public protocol and have an open source implementation. We want as many manufacturers and developers to use SDL as possible. And let me also say I'm going off script here. The opinions below are my own and may or may not represent any opinions of my employer.

So with that being said, I think we are continuing to overload the client frameworks to make up for a more complicated on the wire API then we need, and instead of focusing on the client libraries, we should be focusing on the Over the Wire API and making that as robust and easy to use as possible. If we want to then provide a reference client API we can, but until we get a clean, consistent, and robust Over the Wire API, then App developers like Amazon (Waze, ParkU, Honeywell, etc.) will have to write custom code for each manufacturers HMI, and there is going to no way to do a write once run everywhere App without littering the App with special case code.

Also, for the Over the Wire API, if the specification says that information is available to the App developer, then the App developer should be able to use that information (GPS anyone). If there are fields that are not generally available for developers to use because of legal restriction, then we shouldn't be including them in the SDL specification, or at a minimum we need to add to the specification information about this to make it easier for developers to figure out what they can and can’t use. This is even MORE important with cloud app as all information sent to the cloud is now and forever more in the cloud. And technically if its on the phone, you should consider it in the cloud.

Now I'm not trying to do away with things like the Policy Server nor requirements that Apps be registered with manufacturers, but I am pointing out that if we are trying to move the needle and bring SDL to an open standard that has a robust App eco system behind it, and give users a reason NOT to use Android Auto or CarPlay, we're not heading in the right direction.

If Apple ever opens up CarPlay to arbitrary developers then its going to be even harder to get users off of the eco system they know and love, and into the SDL world. I'll also point out that in my view of the world WebLink is a way more interesting experience for developing Apps then SDL is. Note that I know NOTHING about WebLink other then what is publicly available on their site, nor have I had any communication with Abalta.

Again, sorry if this sounds like a rant, but if we want SDL to not only survive, but to thrive in a world where Android Auto and CarPlay are already well entrenched, then we need to focus on making SDL great. Yes features are required, but I think the first thing to get right is the Over the Wire API, and then build on top of that.

Maybe we start with Cloud Services since there are no Cloud Enabled Apps today and none that are at the moment (that I’m aware of anyway) holding up production of a new vehicle. Start with defining these use cases, and agreeing to them (which Jack did a great job of). Then work forward from there. I don't want to stop any work on the traditional in-car SDL as I understand there are product pipelines and user expectations that need to be met, I just think that SDL as a whole needs to become easier to use.

Just my 2¢ for the beginning of the week. And sorry for taking so long on this, I've been working on a feature for our SDL apps that I think will delight users, and that, in the end, should be all of our goals.

Andrew

[joeygrover]

@AndrewRMitchell I appreciate your comment and candor, though I want to remind you to try to stay on topic when reviewing a proposal. These more complex features already have a long read so we should stick to commenting on the proposal directly. Therefore I do not recommend any further discussion that is not directly related to this proposal in this thread. I'm all for having discussions based on those topics during the next workshop or steering committee call when we have time. If you have any specific feature/fix/change you want to see until then, I encourage you to enter a proposal.

• As we've talked with OEM after OEM, forcing them into a single method is always met with extreme resistance and usually doesn't work. Using a method that enables a variety of different cloud app authorization methods allows us to adapt to any situation that's possible, and best of all each of the solutions can work side by side. I believe if we have to limit it, I would recommend at least 2 of solutions. The first being the cloud app itself authenticating through PerformInteraction requests. The second would be the enhanced policy server where it's possible to get a custom policy table based on the specific vehicle/user. This would cover our most bare bones as well as best user experience. (Edit: I think I misread your initial comment so this bullet can likely be ignored)
• Nothing in this proposal stops the use of web services when an app isn't connected via a mobile device. However, it's possible to put clarifying language in the proposal like "Apps that have both a cloud and mobile implementation that connect to the module will always have the mobile implementation take priority."
• The client library is not part of this proposal as the author has stated. It will have a separate proposal where the language can be debated for its merits or lack thereof. This proposal is only the adapter for Core and how Core knows where to connect.
• Media streaming does need to be flushed out more to be used in this setting, but in my opinion most cloud apps will be more on the utilitarian side (ride share, weather, etc) for the reasons you shared plus the cost of the actual data the user will have to pay for on their car's data plan. I think looking at it from that use case (non-intensive data usage apps) the benefits of this adapter really start to shine.

Something that isn't clearly spelled out is the ability to use this cloud adapter for locally ran apps. Using web sockets, it becomes easy to enable the ability to connect apps that run on the same hardware as the Core module itself. In my opinion, this is where media"cloud" apps could reside; essentially becoming a translation app between partner APIs into SDL APIs to take advantage of being able to cache media while connected to WiFi, play it locally, leverage the already existing SDL HMI, etc. This also becomes useful for OEM apps (user manual, app store for cloud apps, etc). OEMs have the ability to create an app that runs locally on an IVI system but uses the SDL HMI for it's UX therefore able to be taken from generation to generation of IVI system without complete rewrites.

[AndrewRMitchell]

@joeygrover In an effort to just review this proposal below are my comments just with this proposal as it exists that still haven't been addressed (ignoring the VIN issue for now). And I like your idea about connecting to local Apps, but again, that is a whole other can of worms and definitely beyond the scope fo this proposal. Also I apologize for not realizing the proposal had fundamentally changed from the one we originally reviewed (given the scope change, it may have deserved a new proposal number).

Comments:

Line 12 - Remove the word JavaScript - the technology will be defined later Line 19 - Again, we're forcing the implementation into JavaScript Line 34 - We're specifying Websockets, but unless we're already committing the client library to be in JavaScript, this decision is premature. Line 43 - Again we're calling out Websockets. Line 81 - Again, Websockets, and in this case it's not even needed for the rest of the line to be completely relevant. Line 105 - Websockets. I'll stop harping on this and stop mentioning all the remaining occurrence. Lines 114-128 - I'dd add things like UNSUPPORTED_HMI_TYPE and UNSUPPORTED_HMI_LEVEL, as I said before, you really need to provide vendors with the ability to limit the types of Cloud Apps that they will allow to run on their HMI. Line 145 - if you want to keep this a bool, I'd insert a line at 146 - isHybridCloudApplication to allow for specifying a cloud App that runs only when the device App isn't there. I don't think that overloading the App ID is the way to support the hybrid model. Line 155 - You probably want a retry timed out or retry failed on count (or both) code as well to indicate the App was connected, but is no longer connected and we're no longer actively retrying.

In addition to the other item's I've mention, it's also missing a flag to auto reconnect on launch. I think this should be separate from any equivalent device functionality as bringing up the cloud connection can incur real costs for the user.

The other thing I'll point out is I think that Jack's use cases should be integrated into the proposal (as I previously stated), assuming we are going to assume that all 4 of the use cases are integrated into the proposal.

Now the question is, can we realistically come to an agreement on this proposal with out a Workshop. That is a question I'll leave this question up to the group.

Andrew

PS, while you may view some of my previous comments not relevant to this proposal, I did make a lot of effort to limit them in scope this proposal. The issues that I see are specifically being brought up by this proposal, as this proposal is fundamentally inheriting all of SDL and brining it into a new domain, and this is the reason I feel its valid to discuss these items in this proposal.

[theresalech]

The Steering Committee voted to return this proposal for the following revisions:

• Remove HashedVIN from ini file, and get it from the HMI via the current GetVehicleData request. HashedVIN parameter will be renamed to CloudAppVehicleID. Note that the OEM can decide how to set this value during their implementation.
• Remove references to "JavaScript," as the language the cloud app proxy would use will be defined during individual implementations.
• Add an additional parameter to Policy Table entry called cloudTransportType or something similar.
• Add example use cases and diagrams.
• Add parameter of when to display cloud app (always, when local or mobile is not present, never). The user can pick this setting when choosing to enable their app.

It was also agreed that a new review issue will be created for this revised proposal, to best keep the discussion contained to the revised version.

[theresalech]

Due to the number of comments on the original proposal and the amount of changes within the revised proposal, a new review issue has been created for the revised proposal: https://github.com/smartdevicelink/sdl_evolution/issues/493. Please provide any comments on the revised proposal there.