Page History

...

Tuesday

...

10 November  - 500pm CET

Participants

• Alexander Domin, Johan Strand, Stefan Wysocki, Guru, Stephen Lawrence, Gunnar, Philippe
• apologies: Stefan Wysocki,

Minutes

AMM debrief

• Johan: workshops were very good

Tuesday 3 November  - 500pm CET

Participants

• Alexander Domin, Johan Strand, Stefan : Chris Simmonds who attended made a good contribution to the discussion
• Philippe: asks whether new work items were identified
• Stefan: the new items are listed at the end of the working session slide deck, there is an interest in digging into the Internal Data Server (IDS) architecture rather than the External Data Server (EDS) we have experimented up to now, with IDS the GraphQL would be exposed through the Android framework
• Stefan: have a couple of questions to ask to the working session participants, e.g. Ford and VW
• Philippe: will send a follow up email to Ford and VW to ask for their feedback on the working session

Backlog review - Work to do

• Wysocki, Guru, Stephen Lawrence, Gunnar, Philippe

Minutes

Permission control

• Alex: some ideas on my desktop, although not formalized as a set of specifications
• the recording of Alex's pitch is here
• some hints on the discussion are given below
• in the web when using graphql,  there is a user login name and password to connect to the data
• you need to authorize yourseld on the phone, the session is valid for a certain period of time, if you do things, the session will remain
• the server knows you
• before you can use a graphql application,  you need to register, there is a link between the graphql server and your role
• let us switch in the car environment and let us deploy some kind of a server in the car
• what we learned from the web, graphql needs a name and a password
• the app which is installed in the vehicle environment shouf be identified and signed / qualified as coming from the BMW store or the OEM specific store
• the app should be made trusted in the environment
• Johan: I agree with the approach
• Alex:  in the web we have roles & permissions stored in the server but not applicable to the vehicle environment
• more on the token: in the web, we have a token enhancement, after we logged on to the server and run through the authentication process, we got a token enhancement
• we can have the same in the vehicle environement
• (not captured...)
• access rights: each and every app should bring permission groups in the manifest file
• let us assume the app is allowed to access 20 atrributes
• let us assume the user driver needs to have more permissions that the user "baby"
• how do we handle this ?
• Johan: I understand the difference between the web and the car
• (not captured...)
• Alex: in the car we have an app where the user authorizes him once and then this app gives rights to all other apps that need it
• discussion continues on the sw architecture
• Gunnar: the key thing for me is that you can include the information that is to be exchanged in the token
• discussion on the token structure
• Gunnar: we need to finalize the building of the platform and the manifest
• Alex: what about the validation of the security token approach ?
• Gunnar: the GENIVI cybersecurity team can help reviewing the desing but will not implement anything
• TODO Alex prepare the use cases for the security token validation for next week (10 November), jira:

  Jira
  server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-117

  is in-progress

Friday 26 October - 3pm-7pm CET - GENIVI AMM AASIG VHAL working session

...