<scribe> scribenick: ted
<scribe> Scribe: Ted
Ulf: Isaac and I have been
working quite a bit the last couple weeks on this and had
progress but maybe not reached the point we hoped for
... we initially suggested today as delivery for this chapter
draft
... we have a few slides
[Ulf's slides]
Ulf: we have realized that the
scope is quite big if we want to be reasonably detailed and
complete
... we want to ask this group for an extension until end of
July. I will be on vacation next week
... we may have something earlier in July
... it is a deep, complex topic and planning to work on a
research paper in parallel to share outside this group
... some aspects are non-normative and feel only normative
belong in the spec
... such as access control server within gen2
... we do like the role based model and think it can provide
value here
... want to include the three sub-actors that comprise the role
presented previously
... I feel it gives an intuitive level of understanding to the
access being given
... eg an OEM will have access to most
... also allows to provide maximum access possibility
... client gets back what it has access to
... in authentication process, the request for certain role
could help server profile client
... we feel there should be a list of available purposes
... client must provide purpose in its request to access token
server
... we have a draft for what access token may look
... one could have JSON definition of all the signals available
for this purpose, although potentially very verbal
... just a few signal description strings add up quickly to 150
or more characters
Ted: of course we will agree to an extension. While roles do have their conveniences, I still feel OEM will want to be very granular (shows demo of W3C ,access tool that is a hybrid). agree it is worth publishing a paper for non-normative pieces, they may belong in best practices as well. US DHS wants to get me a slot presenting to https://www.acic-auto.org/ and we may want to try to enlist that audience
<Zakim> ted, you wanted to mention bp and acic
Gunnar: can you summarize your statement on scope, including purpose
Ulf: purpose is a name, a placeholder with definited set of signals for that purpose
Gunnar: only one purpose at a time?
Ulf: yes, client would only be able to request one access token for one purpose
Gunnar: token is then sent with a request for specific signals?
Ulf: yes, when client requests data for one or more signals the token must be sent
Gunnar: server would then check the signals requested are within the designated purpose?
Ulf: yes
... list of purpose would line up with service categories
Ted will send out survey https://doodle.com/poll/w62mb6e367tuwgx5
MagnusF: tried to summarize conversations. the purpose is from an older slidedeck (see email)
https://lists.w3.org/Archives/Public/public-automotive/2020Jun/0015.html
Christian/Gunnar: add security before safety
[requirements from pdf slides]
MagnusF: this lines up with JWT
of previous topic
... we need to be abstracted from SomeIP etc
... we need to differential service access based on roles, I
will leverage what Ulf/Isaac are coming up with for Gen2
[RPCs can use VISS/Gen2 for signal pub/sub, but Gen2 has no dependencies on RPC]
MagnusF: based on what we
discussed previously
... Daniel suggested simpler use cases we stick with writing
signals instead of use RPC. we will experiment there
... we will need arbitration for competing RPC on same
signals
Ted: perhaps role based there
MagnusF: yes and legal
restrictions
... there is a tentative agreement on GENIVI working on RPC
service catalog and W3C the protocol piece
Gunnar and Ted: agree
MagnusF: I will focus more on W3C
side but GENIVI as well
... I want to have 1:1 with Gunnar to agree on basics, similar
with Ted on W3C process
... we are exploring different protocols. there is JSON-RPC
which can co-exist on VISS/Gen2 socket
... that is a possiblity and may be proposed
... will compare to JSON-WSP. maybe not the most efficient and
open to suggestions
... we will use YAML as format to define services as a semantic
subset of Franca and strive to keep it simple
... we will have formal translation rules for translation
to/from Franca
Gunnar: we need to work through that, aim to keep translation rules simple
MagnusF: RPC to actuate, sends
request with completion code: error, complete or in-progress
and return immediately (within 50ms)
... as mentioned we'll look at using pure signals for simpler
cases and contrast
... large information retrieval of eg all SiriusXM stations,
that is not the kind of thing you want to transmit
... but instead use data plane. we need some best practices for
how to retrieve a large set of targeted data
... there are a few alternatives, we are looking into this
Ted: Peter sent regrets and that
he has yet to find someone within Volvo on RPC
... reiterate call for editor and willingness to help
MagnusF: also willing to make the case
on GENIVI call we were discussing how instantiation of doors and their signals may look in tree, benefits of one approach for graph queries. I'll see if Daniel wants to run it by this audience as well
[adjourned]