See also: IRC log
-> https://github.com/aShinjiroUrata/web-platform-tests/tree/dev-urata-vsss-test/vehicle-signal-server-spec Test Cases
Urata: we have 32 tests identified in our document
-> http://www.w3.org/mid/CANXs=p6Po+EQPnQF8aWbimn+F0uFaSDd6T4HtGKFTKV2S1aaYw@mail.gmail.com Urata's email
Urata: I have 21 written and
another dozen or so to go
... authentication is a bit trickier to test. I can have two
tokens with different permissions
... we do not have enough of a description about authentication
level to be able to write a test against
... if it is implementation dependent and will not be defined
in the spec then it will be difficult for others to reuse this
test suite
... another point is my prototype doesn't support the filter
function
... both will take some tweaking to handle
Ted: I believe you are right, we
left auth level to implementation and that makes it difficult
to test
... one idea is to have a known restricted signal to try to
access and expect it to be refused
Urata: there isn't a good way to test auth level
Adam: thank you for your work. I
think the solution might be to put read/write flags in VSS data
model
... we have vehicle and user level tokens. we could have a
vehicle level token, user level and hybrid and different tests
using the different tokens that might help
... I will elaborate further in github issues thread
Urata: do you think more needs to be added to the authentication portion of the spec?
Adam: there is a pull request for
a more detailed example
... have you seen that and should we elaborate further?
-> https://github.com/w3c/automotive/pull/138 example pull request
Adam: it helps conceptualize it more
Urata: I will look further and comment if I think I need more
Peter: we are starting to look at
authorization manager for our implementation here
... if you have different subscriptions and different tokens
expiring for portions of the tree, how do you handle?
Adam: in the spec it says you can reset your existing authentication and build on top of it
John: I work for IFSF and had a
similar problem years ago
... when you do a mobile payment for fuel there is a token
generated and sent to a site
... we found it inadequate since it changes every time and you
need to know who the person is
... you could use the vehicle token as a constant and use it as
a means to identify the randomly generated one
Adam: in section 8 of the current specification we discuss tokens for device and application
http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html
John: can you elaborate on the device, the vehicle or a phone or?
Adam: the vehicle itself
... the infotainment unit
John gives some background on himself including building Shell app
Adam: I'm from JLR and we started using that recently
Ted introduces John to the WG
Urata: regarding the test suite topic I think I have nothing more to say at this point
Adam: the action will be to further discuss VSS permissions model and make sure it aligns well with section 8 of the VISS
-> https://github.com/w3c/automotive/issues/132 What fomat of json should be returned by getVSS()? #132
Ted: I closed that on a previous
call when going over open issues as Urata felt his question was
sufficiently answered
... I'll reopen
Adam: we did digress from the original topic
Rudi: it does not make sense to
expose signals that are not available
... not security through obscurity but trying to pair down
traffic and avoid developer/app confusion
-> https://www.eiseverywhere.com/ehome/225965 May 9-11, 2017 Birmingham, UK
Ted: Thursday and Friday looks
like the best but need to get confirmation still on room
availability from Karin Hanson
... Wednesday is possible too given others' meeting schedules
at AMM but would conflict with Genivi's Open day
... showcase is on Wednesday evening and we may get a table
again but that would be disruptive to the meeting with people
needing to do setup
Rudi: Beginning of the week I have other commitments at Genivi
Mike: I think Volker will represent IBM in the UK. I might be able to attend a March meeting in North America
Adam: I don't think that has been settled yet, leaning in the thread was 1/2 day teleconference[s]
Urata: Hira proposed a March F2F and people responded with teleconference idea
Peter: yes, limited travel budgets for two meetings so close together
Rudi: I started a poll to see
what would work best
... we have had 9 responses and all have indicated that they
are favorable to meet. we would need to figure out the
timezones
Hira: what timezones are we looking at?
<rstreif> http://doodle.com/poll/yitqh6i8dq7wbrar
Rudi: I will quote GMT times and try to find something
Hira: maybe we need three times
for discussion
... for VISS, VIAS and Test Suites, one for each topic
Rudi: I put three sessions and
wanted to see based on the participants if we had any
geographic/regional intersts on those topics that would help
settle on times
... no such pattern emerged so will have to settle on arbitrary
times
Hira: 6am in Japan is acceptable
Urata: that is very difficult for
me
... 2am is in fact better
Peter: is a March F2F out of the question?
Rudi: two days plus travel time
<mike> teleconference +1
hira: f2f
peter: f2f
adam: teleconference
rudi: teleconference
urata: either ok
john: abstains
[VISS editors in Europe so should favor that timezone for that call, Powell is our VIAS editor so check with his availability, Urata has done all the Test Suite work so Asian friendly for that call]
Rudi: Propose week of 5 March
<mike> i'm open, flexible
Peter: regrets that week
Rudi: week of 12 March
Adam: ok for me except
Friday
... our BG meeting is on that Tuesday
Ted: I was hoping to delve into payments on that BG call. if we can avoid that hour that would be my preference but otherwise alright
Urata: this is prepration for
moving the spec to CR
... after these meetings can we expect to be ready for
that?
Rudi: that is my expectation as well
Urata: we should work on agenda
for each meeting
... is that clear yet?
Ted: I will start an agenda on a wiki. Chairs control the agenda so may revise as could people based on their specific areas who know about different issues
Urata: we need some prototype
implementation for VIAS and test suite for it
... I am concerned if that spec will make that schedule
Hira: we have yet to publish FPWD
for VIAS
... after we need wide review
https://www.w3.org/2015/Process-20150901/
Ted: I share the conern about
VIAS schedule. when Powell is ready and this group has reviewed
it I can publish
... my quick read of the process document suggests we need 4
weeks at FPWD before we can go to CR
... I encourage people to start looking at Powell's work. there
has been relatively little feedback so far
Peter: I have done some
Urata: I will as well
Peter: I am working on our
service implementation this week and will look for a colleague
to review it
... phone conference will be on week 11, specific times
pending
[adjourned]