https://developers.google.com/identity/protocols/oauth2#serviceaccount link Isaac provided at end of last meeting
Ted summarizes where we left off last week and Isaac's suggested reading
Isaac: we should try to follow existing model where possible, this is a perfect fit for our usage
... this covers our actors in scenario
... Ulf also had an email about proxy concept
Ulf: I was wondering if it is possible to not define specific use cases for every type of app+device imagineable
... behind all there is still a role, person/user and need to explicitly proove their consent
User centric access control model
Gunnar: only sending my response now
https://lists.w3.org/Archives/Public/public-automotive/2020Apr/0008.html
Gunnar: when speaking about being a proxy for user, it is still identity app has
... proof in challenge-response would be signed statement on who's behalf you're acting
... signatures can be checked via public key
... method of proof is separate from concept of identity. what is the app saying about itself?
Ulf: if the app doesn't have to go through its own authentication process but has a valid token from a verified
Gunnar: that is a single thing of several we mentioned that could affect access
Ted: @@token server issue based on role request for given, verifiable app
Isaac: the discussion was more on permissiveness of policies, what kind of scenarios we should handle
... we are now focused more on the actors
... I think we can reach an agreement on what application is accessing the data
... trust may vary on the receiving end based on device, role
... mechanisms for authenticating users and their devices is something we want to discuss farther
Ted: first time app runs against a given vehicle and sends its own private key signed authentication, it might need to go through additional verification
... could be separate from user's short or long lived token, multifactor auth for increasing security
Isaac: we can have two kinds of controls, on owner and process of application
... we may have additional parties besides the owner, such as the auto manufacturer who will be granting access to vehicle data by applications
Gunnar: you already provided a good example
... how to enforce that the application is not accessing others' data
... you cannot trust application to manage different users
... in case app is compromised or malicious
Isaac: there may be different data owners, including oem and app service
... oauth handles distinctions in trust levels
Ulf: what would be a sensible next step, back to the use case descriptions?
https://www.w3.org/auto/wg/wiki/Access_use_cases
MagnusG: last week it seemed we were discussing different layers on where to do authentication and was concerned we were going to get stuck
... we cannot foresee every conceivable use case
... we need to confirm we have a correct/verified client
MagnusF: if a third party wants to access data they will get what is required under right to repair, owner more
... oem and approved mechanics access to all data. it will be role based
MagnusG: workshop scenario could be handled through the cloud instead of accessing the vehicle directly
... and you can impose whatever authentication restrictions you want
MagnusF: you may want ODB to get some earlier, even pre-boot data and device connected to cloud
... telematics unit may not even be up yet
Ulf: possible to match with architecture we have so far
[discussion of root keys that can check some keys without vehicle having network connection]
[discussion of Right to Repair data access provisions/debate in various states in US]
MagnusF: there will deligated authority to users who can then in turn authorize other third parties - be it a workshop or app
... user should be able to provide subaccess
... there is still active debate on nuances, especially around safety aspects
... UIB, authorized shops, shared fleets... various general use cases under discussion
Isaac: they documented anywhere?
MagnusF: nope
... workshop scenario potentially more sensitive
Glenn: we developed a number of these use cases for a discussion over at SAE
... some of them more truck centric, happy to share here too
[Sebastian in Webex chat: Related: https://github.com/eclipse/kuksa.val/blob/master/doc/jwt.md (but less scope than discussed here, our impl. doesn't care "where" the token comes from or whether it is an user or system, it just needs a valid token)]
[Glenn provides:
1.1 Scope
1.2 Use Cases
1.2.1 ECU OTA Updates
1.2.2 Remapping engine for large changes in elevation and terrain
1.2.3 Dynamic space change for platooning
1.2.4 Reset of vehicle infotainment, windows, radio to neutral
1.2.5 Car-sharing: remote ‘key transfer’ to permit unlocking of doors/ engine start
1.2.6a Hybrids: disabling ICE function in certain emission controlled zones
1.2.6b Resetting engine/vehicle modes of operation for specific purpose including, noise and emission controlled areas.
1.2.7 Geofencing: truck travel between the US and Canada, change parameters to meet regulatory compliance.
1.2.8 Truck trailer remote OTA
1.2.9 OEM/Rental House: Remote diagnosis and self check
1.2.10 Sensor setting changes
1.3 Future Requirement Cases
1.3.1 Triggering controller functions or circuits from cloud based exception logic?
1.3.2 Driver feedback and routing assistance?
]
Peter: I'm looking for how we go forward
Ted encourages Glenn to share fuller report by email
[Gunnar in Webex chat: But my wish is we write out at least one complete access control method. It need not be required in spec. I wrote it better in my email.
Complete, but not necessarily perfect (not including all possible identities/credentials/conditions). From today, it should be more than User identity only, at least.]
Gunnar: we need to confirm method works, our spec doesn't need to stipulate all the pieces if there is flexibility
... Magnus made a point about growing this to services as well, such as remote unlock which has stronger security requirements
... very different than reading data
[adjourned]