<scribe> scribenick: ted

<scribe> Scribe: Ted

Meeting in May

https://doodle.com/poll/8quph22ztpt87i4z

08am - noon PST / 11am - 3pm EST / 5pm - 9pm CET

proposed

Best Practices task force

Ted @@proposal

Arman: absolutely, have not been in touch with them since end of January but happy to support

Access Control

Isaac's email and diagram

Isaac: role to establish initial access policy could be user, car manufacturer or other
... the request for the access token is done by the application using this process
... access server is outside the vehicle

Ulf: I like it as such. having a public/private key pair is useful
... we can eliminate or even not use TLS in some cases
... however I see an alternative flow that may also be worth allowing
... benefit is app does not need to have and manage a keypair

Ulf's alternate flow

Isaac: it is relevant. my flow was to ensure the application is authenticated
... there may be cases where information is not as restricted and can be more open

MagnusG: how would a third party client that supports multiple brands know the flow or have we not discussed that yet?

Ted points out https://en.wikipedia.org/wiki/WebAuthn

https://www.w3.org/TR/webauthn/

Ulf: we should not necessarily delve into auth methods

Isaac: it could be interesting to leverage and maybe not have in our specification itself

Gunnar: one risk is user may be tricked into allowing permissions to access data
... OEM may want to give permission to certain, identified and known applications
... it is not something user can grant but OEM
... there are some more scenarios that need to be considered

Isaac: scenario you mentioned is taken into account in my flow, application uses a recognizable keypair that can be checked by OEM

Gunnar: if I approve on trusted device, I don't necessarily trust all applications on that device

Isaac: you need to do a more complex oauth of the application

Gunnar: what is included in the token?

Isaac: potentially several things
... the authorization server can recognize the app and user separately
... there are two stages

Gunnar: need clarification on those details

Ulf: not in sequence diagram but augmented with text describing those details

Gunnar: that sounds good
... clarification on requesting access token

Ulf: Isaac's alternative is slightly more secure but requires application ability to handle a keypair
... my flow requires less of application and less secure

Gunnar: you have to think of the ways it can be attached and how feasible those are

Ulf: these are based on existing paradigms

Isaac: I can go into more detail on consequences for both paradigms
... to attain long term authorization and not necessarily be online
... you can issue token with long expiration date. for every request to auth server will be the same
... the key pair is long time and private key backup for getting a new token
... you can only use the flow if you have means to protect public key in Ulf's approach
... if the tokens are short term they're more similar in both approaches

Gunnar: we changed server naming in this flow compared to what we were discussing before
... second auth server is on the vehicle

Ulf: yes

Isaac: in Ulf's approach, the token issued by the server can include relevant information

Gunnar: check permissions should only be on that line, the one straddling both diagrams

Ulf: the two actors involved
... signature needs to be confirmed

Isaac: I think we need to support both flows

Ulf: I agree

Isaac: there a base document we can start putting this?

Ulf: chapter 5 I think of the Core doc in W3C github

Isaac: what would be the best way to capture those two flows

Ulf: best is to start with an issue in github and then start drafting it

Gunnar: the user cannot take the decision on their own
... it could be the OEM is providing the key pair to the client app

Isaac: there should be a mechanism in place with the client application and user are identified and authenticated
... that could be out of scope of the specification but it is something that has to be solved

Gunnar: yes but it needs to be understandable

Ted: both app and user will need to identify themselves, OEM will need to authorize/bless app before user can opt to use it

Gunnar: I have concerns about doing away with TLS even if not needed for some communications

Isaac: there are alternatives being used recently in various VPN
... it is becoming more popular and in some cases more appropriate
... TLS not always the best choice

Gunnar: industry may be hesitant to consider alternatives

Ulf: I'll create the issue

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Arman Isaac Glenn Ted MagnusG Ulf Gunnar Guru Daniel Peter
Found ScribeNick: ted
Found Scribe: Ted
Inferring ScribeNick: ted
Agenda: https://www.w3.org/mid/A3CADF2F-83D1-4D11-8F2F-77A8D5B41833@volvocars.com

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)