Re: Combining Service accounts and OAuth flow

Looks, good!

I have an interesting story relating to these cases that happened to my son and his friends while visiting a park in northern California his weekend. They were renting a car which was relying on internet connection to unlock and lock the vehicle.  The retrieval of the vehicle went well, and they drove off to the park, got out of the car and the car locked itself via the app on my sons phone. However, when they got back to the car connectivity was poor and something went wrong with the verification from the vehicle to the cloud and the car refused to unlock itself. (Usually this can be overridden by the use of zipkey but they had not received that card before the trip) . So, they spent the rest of the day trying to hitch hike back through corona plagued back country (ok , it was not that bad, people were friendly).  I think, though, that it shows though that applications depending on connectivity for authentication in certain cases are vulnerable in areas where we have intermittent connectivity.

Br

Peter W
From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Tuesday, May 5, 2020 at 1:28 AM
To: Isaac Agudo Ruiz <isaac@lcc.uma.es>
Cc: public-automotive <public-automotive@w3.org>
Subject: Re: Combining Service accounts and OAuth flow
Resent-From: <public-automotive@w3.org>
Resent-Date: Tuesday, May 5, 2020 at 1:28 AM

Hi,

I really like Isaac's proposal.
However, I think we should also support an alternative flow which does not require the Client App to manage the public-private key pair.
The attached sequence diagram, which only differs from Isaac's proposal in the first sequence steps, is my proposal on what that might look like.
BR
Ulf

On Sun, May 3, 2020 at 11:09 PM Isaac Agudo Ruiz <isaac@lcc.uma.es<mailto:isaac@lcc.uma.es>> wrote:
Hello everyone,

I have prepared a  diagram to serve as a starting point for discussions in the next meeting. I have combined the standard Oauth Flow with the concept of service accounts. User could the the car owner or the manufacturer.

Having a key pair per app would enable also another interesting use case, at least from my perspective: Encrypted responses. The Vehicle Server can use the public key of the app to encrypt responses, avoiding the need for TLS in the back channel. I order to avoid it in the requests, they should also be encrypted using the vehicle server public key. I think removing the TLS dependency in the last step, could affect performance in a good way.

I have used the following tool to create the diagrams, in case someone wants to amend them: https://sequencediagram.org<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsequencediagram.org%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C6980f3f356834fb55a1608d7f0ce5802%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637242641354370141&sdata=b2M4Tm9xwYwWEhxz0j7JXCo2kQS7piB68mT64Huo9dM%3D&reserved=0>

Best,

Isaac.

******

Here is the source code and the diagram in PNG:

title User delegating access to Client App

actor User
participant Client App
participant AuthzServer
participant AuthnServer
participant Vehicle Server


note over User: Install Client App
User-->*Client App:<<create>>
note over Client App: Generates Key Pair
aboxright over User,AuthzServer: User delegates access to Client App by \nidentifiying the Public Key, e.g. QR codes\n and set app permisions, e.g. using roles
note over Client App: Generates JWT with iat \nset to current UNIX time
Client App->AuthnServer: Request access token using JWT
note over AuthnServer,AuthzServer: Check permisions
AuthnServer-->Client App: Token response
Client App -> Vehicle Server: Request Signal using Access Token
note over Vehicle Server: Check Token
Vehicle Server-->Client App: Signal response

[cid:171e3e75a5a9bb14bb71]


--
Ulf Bjorkengren
Geotab
Senior Connectivity Strategist | Ph. D.
Mobile
+45 53562142
Visit
www.geotab.com<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geotab.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C6980f3f356834fb55a1608d7f0ce5802%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637242641354380126&sdata=A%2F6UyKnSb3BdvTINyY9la%2B3htq1jSexJWSdG%2BkvD8rA%3D&reserved=0>

Received on Tuesday, 5 May 2020 16:43:07 UTC