The document discusses data privacy and control considerations for vehicle data APIs. It covers the types of vehicle sensor and location data collected, and balancing commercial interests in data with consumer expectations of ownership and privacy. The document proposes implementing OAuth2 for authorization, with a RESTful API design focused on resource-driven access control. Technical challenges around access tokens and caching are also addressed. The conclusion advocates for prioritizing consumer trust by voluntarily implementing strong data privacy and control practices.

2. What Kind of Data?
● Vehicle sensors
– Speed, Tire Pressure, Engine Temperature, Oil Pressure,
Door Sensors, ABS State, Trouble Codes, etc.
● Location data (GPS)
● Accelerometer data
– Acceleration and Deceleration
● … And the list is only going to grow

3. Security vs. Control
● The first is the protection of that data
– Treat the data as “PII”. Robust mechanisms for protecting
data exist and can work – assuming you try!
● The second is how that data can be used
– From an API perspective, there are few tools out there to
help and in many ways this is unexplored territory

4. Is There a Problem?
● Consumers have (or should have!) an expectation of
ownership and control
● Commercial interests want to monetize (directly or
indirectly) the consumers data
● Mass collection of personal data by Government
entities

5. Do Consumers Care?
● Usually only after there's a problem
● Over the past few years, data privacy has started to be
discussed in the “mainstream”
● Advocating for consumer control can be a
differentiator for companies

6. State of the Industry
●
OEMs
– They're coming around
● Aftermarket
– There's a lot of value in that data. We need to resist the urge to
misuse it
● Regulation
– Consumer Car Information and Choice Act (CA SB 994)
– EU has fairly strict data privacy laws but it's unclear whether this
applies to vehicular data
– FTC recently asked Congress to pass laws governing “data
brokers”

7. What is Control?
● Owners must be able to access (and download) their
data
● Owners must have a way to authorize your API
consumers to their data
● Owners must be able to revoke that access at any
time, and for any reason.
● Owners must be able to delete their data
● Owners must be able to review who has accessed
what data, and when

8. How do we do this?
● Important to note that we are focusing on
authorization, not authentication
● Resource driven API
– How you structure your API matters!
● OAuth 2.0 is one way
– Let's get it out of the way – OAuth2 is not perfect.
– It's a framework, not a protocol. Not all aspects will fit
your API and you may need additional controls (for
instance, signatures and/or encryption may be needed
beyond SSL/TLS)

9. Using REST
● … or at least some of it.
– The choice to fully adhere to REST has other factors and
you may decide it's not all for you
● Uniform Interface
– Identification of resources
– Manipulation of resources through these representations
● Beware of Caching!
– Most scalable systems require some level of caching to
improve scalability and performance
– But what if the user revokes access to a cached entity?

10. Using OAuth2
● Access to a resource is granted based on a validated
access token
– An access token defines authorization between a client (your
API consumer) and a resource controlled by the vehicle owner
● Four mechanisms (grant types) exist for an API
consumer to receive an access token
– Authorization Code
– Implicit
– Resource Owner
– Client Credentials

11. Authorization Code and Implicit
● These are the primary types used to delegate access to
an API consumer
● When an API consumer needs access to a vehicle
owners data, they request authorization using one of
these two flows. The data owner must log in to your
system and grant access.
● Primary difference between the two is that the
authorization code type is slightly more secure and
therefore supports refresh tokens.

12. The Other Two
● Resource Owner
– This allows the API consumer to immediately gain access
to a vehicle owners data but it does so by collecting the
owners credentials to your system. Your API consumer
should not have your users core credentials!
● Client Credentials
– This grant type is appropriate for you API consumer to
interact with their data within your system. It is not used
for delegated access.

13. Technical Challenges
● Access tokens map a client to a single individuals
resources
– This can make API calls that span multiple individuals
problematic
– You'll need to secure your endpoints using a Client
Credential call and then perform the authorization check
internally
● When access tokens are revoked or expired, this can
cause confusion in the user interfaces for your API
consumers

14. Conclusion
● We need to consider ourselves the gatekeepers of
data, not the owners
● By walking the high ground, you will miss out on
business opportunities! The trust of your users will
make up for it in the long run
● Regulation is important, but there's no reason to wait
for it