<scribe> scribenick: ted
<scribe> Scribe: Ted
https://doodle.com/poll/8quph22ztpt87i4z
08am - noon PST / 11am - 3pm EST / 5pm - 9pm CET
proposed
Ted @@proposal
Arman: absolutely, have not been in touch with them since end of January but happy to support
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
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.)[End of scribe.perl diagnostic output]