Compliance · Consent

Session-scoped consent: consent built into the access primitive

Most vehicle data systems treat consent as a policy bolted onto a data pipe. Session-scoped consent makes it part of how access is created — and revoked.

Talk to our team

Session-scoped consent means the user's permission is structurally part of creating an access session, not a separate policy applied afterward. Instead of granting a service blanket, perpetual access to a vehicle's data, the owner authorizes a specific session: a defined scope of data and capabilities, for a defined purpose, for a defined time, after which everything revokes at once. Consent is compliant by architecture, not by policy.

The problem with blanket consent

Think about logging into a streaming account at a hotel two years ago. There is a decent chance a stranger is still using it, because the access you granted never cleanly ended. Now imagine that is not a streaming login. It is your car, your digital key, your payment method, and your location. That is what blanket, perpetual data sharing looks like in the vehicle world: access is granted broadly, scoped loosely, and almost never revoked in a way you can verify.

Regulators have decided that model is no longer acceptable. GDPR demands purpose limitation and the right to withdraw; the EU Data Act demands scoped, user-directed access; the FTC's GM/OnStar order demands affirmative opt-in. Every one of them is, in effect, asking for consent that is specific, revocable, and provable.

How session-scoped consent works

A vehicle session is created as a single operation that carries everything the access needs:

  • Identity: who is being granted access, verified.
  • Scope: exactly which data and capabilities, and nothing more.
  • Spend and time limits: a cap and an expiry, so access is bounded by design.
  • Atomic revocation: when the session ends, every permission inside it is withdrawn together, not one system at a time.

When the session closes, it seals a cryptographically signed, independently verifiable record of what was authorized and when it ended. Because consent is part of session creation, you cannot have access without a consent artifact, and you cannot have lingering access after revocation. The compliance properties regulators ask for are not added later. They are the only way the system works.

A concrete example: a three-day rental

Picture a driver renting a connected vehicle for a weekend. With session-scoped consent, the rental creates one session at checkout: it verifies the driver, issues a digital key, scopes data access to location and trip telemetry for the rental period only, sets a spend cap for charging and tolls, and stamps a 72-hour expiry. The driver can see precisely what they granted. When they return the car, the session ends: the key stops working, data access stops, and a signed record of the whole arrangement is sealed.

Nothing lingers. There is no open data feed after the return, no key that still works in a stranger's hands, and no need for anyone to manually go disable five separate systems. The consent and its boundaries were the access, so ending the access ended the consent, cleanly and provably.

Blanket consent vs. session-scoped consent

PropertyBlanket consentSession-scoped consent
When consent is capturedOnce, up front, broadlyPer access event, as part of creating it
Scope of dataLoosely defined, often everythingExactly what the purpose needs
RevocationManual, partial, often neverAtomic; all permissions end together
ProofA policy documentA signed, verifiable per-session record

Why this satisfies multiple regulations at once

The reason a single model answers GDPR, the EU Data Act, and California SB-1394 is that they all reduce to the same primitive: authorize, scope, revoke, and prove. A blanket-consent system has to bolt each of those on separately and reconcile them. A session model produces all four as a side effect of granting access at all. That is what it means for consent to be structurally part of the session creation primitive rather than a policy layer.

For the technical implementation of revocation specifically, which maps directly to SB-1394's “revocable by the owner” requirement, see audit-ready vehicle access. For the broader model these sessions belong to, see vehicle session infrastructure, and developers can start with the consent product.

Related: all compliance topics · EU Data Act

This page is educational, not legal advice.