Figure 7.1: The Abstract protocol flow. (Source: [3]; Colored boxes are added)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Sequenzdiagramm (abstrakter Protokoll- und Nachrichtenfluss in textueller ASCII-Notation mit farblichen Scoping-Containern).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikationsdokument AUTOSAR_AP_EXP_AutomotiveAPI. Das Diagramm referenziert die W3C VISSv2-Spezifikation (Vehicle Information Service Specification Version 2) und ordnet das zugehörige Autorisierungs- und Zugriffskontroll-Framework in die serviceorientierte Architektur von AUTOSAR AP ein.
• Technischer Zweck: Trennung von Identitäts-/Rechtevergabe (OAuth 2.0 / Token-Handling) und dem eigentlichen Zugriff auf geschützte Fahrzeugdaten (Vehicle Signal Specification, VSS) über den VISSv2-Server.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten:
  • Client: Anfragende Entität (z. B. fahrzeuginterne Adaptive Application, In-Vehicle-Infotainment-System, externes Cloud-Gateway oder Diagnose-/Flotten-Client).
  • Access Grant server (AGS): Autorisierungsinstanz zur Identitätsprüfung und Ausgabe eines Authorization Grants (Berechtigungsnachweis).
  • Access Token server (ATS): Token-Endpunkt, der gegen Vorlage des Grants kryptografisch signierte Zugriffstoken (z. B. JWT) ausstellt.
  • VISSv2 server: Ressourcen-Server (Resource Server) innerhalb der AUTOSAR-Plattform, der die Automotive API (Signale, Baumstrukturen, Lese-/Schreibzugriffe) exponiert.
• Normative Scopes (Farbboxen):
  • Non-mandatory (Gelbe Umrandung): Interaktion mit AGS und ATS. Nicht zwingend im VISSv2-Server selbst implementiert; kann über externe Authentifizierungs-Infrastrukturen (Off-Board, OEM-Backend, lokale Security-Dienste) abgewickelt oder bei vorprovisionierten statischen Tokens übersprungen werden.
  • Mandatory (Grüne Umrandung): Protokollschnittstelle zwischen Client und VISSv2-Server. Zwingend vorgeschriebener Kommunikationspfad für geschützte Ressourcenabfragen (über WebSocket oder HTTP/REST).

3. Dynamisches Verhalten & Sequenzablauf

1. Phase 1: Autorisierung & Token-Akquisition (Optional / Non-mandatory):
   • Client -> Access Grant server: Access Grant request (Übermittlung von Client-Identität, Benutzer-Credentials und gewünschten Signal-Scopes).
   • Access Grant server -> Client: Access Grant response (Ausstellung des Authorization Grants).
   • Client -> Access Token server: Access Token request (Austausch des Grants gegen ein Zugriffstoken).
   • Access Token server -> Client: Access Token response (Rückgabe des signierten Access Tokens, ggf. inkl. Refresh Token und Gültigkeitsdauer).
2. Phase 2: Ressourcenzugriff (Obligatorisch / Mandatory):
   • Client -> VISSv2 server: Protected Resource request (Anfrage auf VSS-Knoten unter Injektion des Tokens im Request-Header/-Payload).
   • VISSv2 server: Autonome Validierung des Tokens (Prüfung von Signatur, Expiration und Rollen/Scopes für den angeforderten VSS-Pfad via ara::crypto).
   • VISSv2 server -> Client: Protected Resource response (Auslieferung der Telemetrie-/Fahrzeugdaten oder Fehlerantwort bei ungültigem Token wie 401 Unauthorized / 403 Forbidden).

4. Normative Relevanz & Entwickler-Hinweise

• VISSv2-Stack-Implementierung (AP-Plattform):
  • Der Server fungiert als reiner Resource Server. Eine Implementierung von AGS/ATS auf demselben Knoten ist nach AUTOSAR AP nicht gefordert; der VISSv2-Server muss primär die lokale Token-Verifikation (z. B. via asymmetrische Public-Key-Validierung) unterstützen.
  • Validierungszertifikate und Vertrauensanker sind über das Key-Storage-Management (ara::crypto) sicher im Manifest und Dateisystem zu hinterlegen.
• Applikations- & Client-Entwicklung:
  • Clients dürfen den Token-Abruf nicht fest mit jedem Datenzugriff koppeln; Token sind gemäß ihrer expires_in-Dauer zu cachen, um Buslast und Latenzen zu minimieren.
  • Für ungeschützte Ressourcen (Public Signals) kann der Zugriff direkt ohne Phase 1 erfolgen, sofern die Access-Control-Policy des VISSv2-Servers dies zulässt.