- From: Isaac Agudo Ruiz <isaac@lcc.uma.es>
- Date: Sun, 3 May 2020 23:08:26 +0200
- To: public-automotive <public-automotive@w3.org>
- Message-Id: <92B4721A-C961-4D03-AEDB-0DCF1B43B76F@lcc.uma.es>
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://sequencediagram.org/> 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
Attachments
- text/html attachment: stored
- image/png attachment: OAuth-2.png
Received on Sunday, 3 May 2020 21:09:21 UTC