User consent and the authorisation process

What does it look like to the connected car user?

HIGH MOBILITY
Jul 16, 2019 · 7 min read

Now that the HIGH MOBILITY platform offers access to personalised data from connected cars, we thought it would be useful for third party services and application developers to understand how the authorisation flow looks from the car-owning end user’s perspective. The authorisation process is exciting for both the application developer and the car owner — it is simultaneously the final step before the developer has access to personalised car data, and what may be the end user’s first step into the world of connected car applications.

In this post we will demonstrate the car owner’s perspective of the authorisation flow so you know exactly what your users will see.

If you have any questions, comments or feedback, please let us know in the comments at the end of the post!

User Consent

Whether your application is offering pay-as-you-drive insurance, charging or services, each car owner must consent to the application’s access to — and use of — the relevant data. During the authorisation process, the vehicle owner is able to confirm or deny the third party application’s request to access this data.

Though consumers are accustomed to sharing all kinds of data from their phones, authorising access to vehicle data is a new and sensitive topic — which is why we have designed our authorisation flow and data-handling to be secure, transparent and GDPR-compliant. (Should a car owner no longer wish to share their data, they can revoke permission at any time, either in the application or in their car maker’s owner portal).

Throughout the authorisation process, we have taken extra care to make it very clear what data has been requested, by whom and for what purpose. The process should look familiar to anyone who has used OAuth 2.0 to log in to an online service.

In order to consent to sharing personalised car data with a third party, an end user must visit several pages. The user’s experience — detailed under each subheading — includes a few extra steps during the authorisation request compared to the standard OAuth flow.

However, the application developer simply implements the OAuth flow with HIGH MOBILITY, and HIGH MOBILITY manages every step of the authentication process with the relevant automaker.

User Starts Journey from App

When a potential end user indicates that he or she would like to sign up for a connected car service, they will see a page similar to the one below. In this case, a “LINK A NEW VEHICLE” button takes them to a link generated by the service, which will initiate the OAuth flow. (This login link is composed of the redirect_uri, client_id, and other parameters which are associated with the service’s account on HIGH MOBILITY).

Here, the user selects his or her car maker from a list of car makers supported by HIGH MOBILITY.

From this point on, the consent flow differs slightly according to car maker. First, we will show the BMW flow.

The Consent Flow for BMW

Before being redirected to the BMW ConnectedDrive portal, the user is shown which permissions the application has requested and is shown the app’s Terms of Use and Privacy Policy.

In this step and in the following steps, if the user selects “Decline”, a confirmation modal will ask the user to confirm their decision. If they confirm that they would like to stop the signup process, they will be redirected back to the app.

The user is presented with and agrees to HIGH MOBILTY’s Terms and Conditions and Privacy Policy.

This is the step in the flow where the vehicle is first known. The user is prompted to enter the VIN, which enables BMW to identify the owner and contact him or her by email in the next steps to request access to his or her vehicle’s data.

Once BMW knows the VIN of the customer’s vehicle, they send an email to the customer informing him or her that an application has requested access to certain data points, and inviting him or her to log into the ConnectedDrive portal and consent to the sharing of data with the third party app.

At the same time, the user is directed back to the application, which will show a status of “Pending” until the user has approved the request inside the ConnectedDrive portal.

In the portal, the car owner can approve the request, as well as see all approved requests. In the portal, the car owner can also see — and has the option to revoke — any permissions which he or she had previously granted to other applications.

Image taken from: https://www.bmw-connecteddrive.com

Once approved, the application can use HIGH MOBILITY’s API to get live vehicle data.

The Consent Flow for Mercedes-Benz

Although the basic idea is the same, the consent flow for a Mercedes-Benz owner to share his or her vehicle data differs slightly from that of BMW.

In the first steps, the user is redirected from the application to HIGH MOBILITY, and he or she selects his car maker.

Before being redirected to the Mercedes-Benz portal, the user is shown which permissions the application has requested, and is shown the app’s Terms of Use and Privacy Policy.

In this step and in the following steps, if the user selects “Decline”, a confirmation modal will ask the user to confirm their decision. If they confirm that they would like to stop the signup process, they will be redirected back to the app.

In the next step, the user sees and agrees to HIGH MOBILTY’s Terms and Conditions and Privacy Policy.

Before being redirected to the Mercedes-Benz portal, the user is prompted to enter his vehicle’s VIN, which will be used in the API requests between HIGH MOBILITY and Mercedes-Benz. HIGH MOBILITY will store the VINs to simplify linking of additional third party apps. If the user clicks “Cancel”, he or she will be redirected to the app.

In the Mercedes ME portal, the user is again shown which use case and data bucket the application is requesting, and approves the request.

This is the final step in the authorisation process for Mercedes-Benz vehicles. The application gets an authorisation code which can be exchanged for an access token, which is used to access vehicle data via the API.

We hope you’ve found this rundown of the user’s view of the authorisation process useful as you begin working with personalised car data. Although the exact flows differ slightly between manufacturers, the differences are always transparent to developers. Irrespective of which car maker you choose to work with, the application sends the user to HIGH MOBILITY to start the authorisation process. When he or she completes the authorisation process, the application will receive an authorisation code.

If you have any questions about what we’ve outlined above, or any suggestions for improving the customer consent experience, please share them in the comments below.

In an upcoming article,“How to Connect to a Real Vehicle”, we’ll be looking at what’s possible on the HIGH MOBILITY platform now and in the future, and read personalised data from a connected car that’s on the road today. Until then, happy testing and developing over on HIGH MOBILITY.

HIGH MOBILITY Magazine

The car is the next developer platform.

HIGH MOBILITY

Written by

HIGH MOBILITY is the car data company providing you with a single, powerful API to access all connected cars.

HIGH MOBILITY Magazine

The car is the next developer platform. HIGH MOBILITY is building the community for people who push the boundaries when building, testing and running data-driven mobility services.

More From Medium

More on API from HIGH MOBILITY Magazine

Related reads

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade