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
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
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
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
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”
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
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)
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?
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
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.
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.
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
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
Top Related