Common vehicle interfaces provide standardized interfaces that enable interoperability with vehicle systems and between vehicle systems and external devices. Here are some of the use cases that are enabled by having common vehicle interfaces:

• Use case 1. Telematics Integration: common vehicles interfaces enable vehicle data collection.
  • Note: This is partially enabled by VSS which provide the data model. VISS complements that by providing APIs but its scope seems skewed towards web access (MQTT, HTTP, web sockets)
• Use case 2. On Android, Common Vehicle Interfaces can be used as a default implementation for Android VHAL and Car Properties
• Use case 3. On Android and non-Android systems, Vehicle Interfaces can be provided as an SDK for integration by Application developers. This can provide a richer access and control over vehicle capabilities compared to the standard VHAL properties, and can be used on non-Android systems (QNX, Linux, .. etc).
• Use case 4. AUTOSAR can provide ARXML description that conforms to the common vehicle interfaces, and Tier1 suppliers can provide a solution that is ready out of box for integration with multiple OEMs as long as everyone conforms to these standardized vehicle interfaces.

Profile/Identity

Use cases from a services/interfaces perspective for individual profiles, identity management. Intent is to provide initial and continued input on identity needs to influence a data model. The Data Expert Group will determine where the work takes place. It will likely be a separate model than VSS but with relationships between them needing to be defined and may be worth including in that call.

• Use case 1. Identity should be supported in multiple on-board platforms including but not limited to AOSP, Linux containers and browser runtime. Some services that would be extended to individuals might not necessarily have all interactions go through AOSP on head unit but some may. A profile will need to be linked to an AOSP user account. 
• Use case 2. The individual or entity may have different roles with respect to one or more vehicles at a given time and subject to change. Roles include: owner (individual or company for eg shared mobility), manager (if a third party helps manage vehicle), operator (driver), passenger, recipient of CCC Digital Key issued (may be passenger or actual operator), being among primary roles to support.
• Use case 3. Profile needs an associated identity comprised of legal name, nickname or shareable identifier (Verifiable Claims - DID?) that depending on usage masks name for privacy considerations, various other characteristics of the entity, preferences for HVAC, seat position, digital service subscriptions, identity provider for authentication, digital wallet for various automotive payment use cases (request input from that group in COVESA).
• Use case 4. A profile is an essential component for consent management, who is providing permission to use what data for which purpose (service) inside or out of the vehicle. It would be extremely beneficial for identity to be something that can be referenceable across industry/various stakeholders instead of rigidly siloed. A Web ID does not exclude brand/service accounts - OEM, insurance, rental/shared mobility company.
• Use case 5. A Web ID can include details (insurance, driver's license etc), privacy and service preferences that can be communicated to the vehicle by vehicle manager (dealership when vehicle is purchased, rental agency, etc) or by the individual via Bluetooth, Apple CarPlay or Android Auto. Unlike vehicles which more commonly have many to many relationships (vehicles/operators+passengers), smartphones tend to be exclusively tied to an individual and can provide identity and authentication.