CPID wird eingerichtet

GTAF verwendet den Nutzerschlüssel, um einen Abonnenten bei der Kommunikation mit der DPA zu identifizieren. Anwendungen, die Zugriff auf die MSISDN des Nutzers haben, können sie als „user_key“ verwenden. Andererseits müssen Anwendungen, die keinen Zugriff auf die MSISDN haben, eine Kennung für den Mobilfunktarif (Carrier Plan Identifier, CPID) erstellen, ohne die MSISDN des Nutzers zu ermitteln. Im Folgenden wird der Mechanismus beschrieben, mit dem eine CPID erstellt wird.

CPID-Anrufablauf

Abbildung 2: Anrufablauf zum Einrichten der CPID.

  1. Eine Google-Anwendung auf dem UE verwendet eine Google-interne API, um die URL des CPID-Endpunkts aus GTAF abzurufen. Der Betreiber wird anhand der öffentlichen IP-Adresse des Clients und des MCC+MNC der aktiven SIM-Karte identifiziert. Bei MVNOs verwendet Google die SPN und GID1, um den MVNO zu ermitteln.
  2. Der Client sendet eine HTTP-GET-Anfrage an den CPID-Endpunkt. Der Betreiber KANN die Anfrage über HTTPS senden.
  3. Der Betreiber KANN seine Deep Packet Inspection-Funktion verwenden, um die Anfrage zu identifizieren und die Telefonnummer des Nutzers als HTTP-Header in die Anfrage einzufügen.
  4. Der CPID-Endpunkt empfängt die Anfrage, erstellt die CPID und gibt die CPID an das UE mit einer Gültigkeitsdauer (TTL) zurück, die angibt, wie lange das UE diese CPID verwenden kann.

Der Betreiber KANN in der CPID-Endpunkt-URL auch IP-Adressen anstelle von Domainnamen verwenden, wenn dies bevorzugt wird. Die IP-Adressen KÖNNEN im privaten Adressbereich liegen, müssen aber für Google-Clients im Netzwerk des Betreibers erreichbar sein.

Der Betreiber MUSS Google im Rahmen des Onboarding-Prozesses die folgenden Informationen zur Verfügung stellen:

  1. Die CPID_URL, über die Anwendungen CPIDs abrufen. Eine CPID_URL ist obligatorisch, der Betreiber kann jedoch mehrere URLs angeben, um die Verfügbarkeit zu erhöhen.
  2. Die Liste der IP-Präfixe, die dem Betreiber gehören, sowie der Mobile Country Code (MCC) und der Mobile Network Code (MNC), die dem Betreiber zugeordnet werden sollen. Wenn der Betreiber SPN oder GID1 verwendet, um MVNOs in seinem Netzwerk zu unterscheiden, MUSS er diese Informationen ebenfalls angeben. Google verwendet diese Informationen, um Clients den entsprechenden CPID-Endpunkten zuzuordnen, wie in Schritt 1 von Abbildung 2 dargestellt.

Das Format der Anfrage ist: GET CPID_URL Aus Legacy-Gründen sollte der CPID-Endpunkt eine Anfrage wie die folgende unterstützen:

GET CPID_URL?app={app_id}

Der CPID-Endpunkt kann den URL-Parameter {app_id} beim Generieren der CPID ignorieren. Die Anwendung MUSS jedoch eine Anfrage mit dem Parameter verarbeiten können.

Die Anfrage an den CPID-Endpunkt KANN den Accept-Language-Header enthalten. Wenn der Header enthalten ist, MÜSSEN in Updates, die der DPA über die Mobile Data Plan Sharing API sendet, die Einstellungen verwendet werden, die in der CPID-Anfrage angegeben sind.

Jedes Mal, wenn der Client eine GET CPID_URL-Anfrage sendet, MUSS er eine neue CPID erhalten. Wenn die CPID erfolgreich erstellt wurde, MUSS der CPID-Endpunkt eine 200 OK-Antwort zurückgeben. Der Antworttext MUSS eine Instanz von CPIDResponse enthalten.

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

Die zurückgegebene CPID MUSS für „ttlSeconds“ Sekunden gültig sein, auch wenn ein Abonnent danach andere CPIDs angefordert hat. Google empfiehlt für eine optimale Nutzerfreundlichkeit einen TTL-Wert von 30 Tagen, aber nicht weniger als 14 Tagen. GTAF codiert die CPID gemäß RFC2396 in nachfolgenden Aufrufen der DPA.

CPID-Generierung

Die EMPFOHLENE Methode zum Erstellen einer CPID über den CPID-Endpunkt ist:

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

Der CPID-Endpunkt verkettet die MSISDN, die vom Client im Accept-Language-Header gesendete Sprache und einen hochauflösenden Zeitstempel und verschlüsselt sie mit AES unter Verwendung des secret-Schlüssels. Der Zeitstempel SOLLTE der Zeit entsprechen, zu der die CPID abläuft. Die verschlüsselte Ausgabe ist Base64-codiert. Wenn die CPID in einer URL verwendet wird, MUSS sie URL-codiert werden, um Sonderzeichen (/+=) zu verarbeiten, die in Base64 verwendet werden. Insbesondere wenn GTAF die DPA aufruft oder die DPA die Mobile Data Plan Sharing API aufruft, MUSS die CPID URL-codiert sein.

Je nach Situation eines bestimmten Betreibers kann die Implementierung des CPID-Endpunkts schwierig sein. Ein besonderes Problem, das häufig auftritt, ist der Zugriff auf die MSISDN am CPID-Endpunkt. Wir möchten Ihnen gern unsere Erfahrungen bei der Einrichtung von Betreibern mitteilen. Wenden Sie sich an uns, wenn Sie Probleme haben.

CPID-Speicher

Eine CPID, die mit dem oben beschriebenen Mechanismus generiert wird, muss nicht in einer Datenbank gespeichert werden. Relevante Informationen für die Bearbeitung von Anrufen an die Datenschutzbehörde können aus der CPID abgeleitet werden.

  1. Wenn die DPA einen Anruf von GTAF bezüglich eines Abostatus oder Angebots erhält, kann die MSISDN durch Entschlüsseln der CPID und Extrahieren der MSISDN abgeleitet werden.
  2. Die Ablaufzeit der CPID kann abgeleitet werden, indem die CPID entschlüsselt und dann der Ablauf-Zeitstempel extrahiert wird.

Verfügbarkeit und Kapazitätsanforderungen

Wenn Clients keine CPID abrufen können, können sie nicht auf Informationen aus der Mobile Data Plan API zugreifen. Aus diesem Grund MUSS der Betreiber die erforderlichen Maßnahmen ergreifen, um die Verfügbarkeit des CPID-Endpunkts sicherzustellen. Zu diesen Maßnahmen gehören mehrere Instanzen des CPID-Endpunkts und der DPI-Funktionen sowie physische, Standort- und Netzwerkredundanz für beide Funktionen. Außerdem muss sichergestellt werden, dass Systemressourcen und ‑kapazität angemessen sind. Außerdem müssen der CPID-Endpunkt und die DPI-Funktion, die den Header einfügt, ausreichend Kapazität haben, um die Last aller Google-Clients zu bewältigen, die CPIDs anfordern. Für den CPID-Endpunkt können größere Werte im Feld ttlSeconds verwendet werden, um die Häufigkeit zu verringern, mit der CPIDs generiert werden.

Fehlerfälle

Wenn ein Fehler auftritt, MUSS der CPID-Endpunkt einen HTTP-Fehler mit einem Antworttext zurückgeben, der eine Instanz von ErrorResponse enthalten MUSS. Eine gute Fehlermeldung enthält Informationen, die bei der Fehlersuche helfen können. Wenn beispielsweise eine CPID abgelaufen ist, können wir anhand der CPID-Generierungs- und Ablaufzeit bestätigen, dass der CPID-Endpunkt wie vorgesehen funktioniert.

{
    "errorMessage": "<error message>",
    "cause": "USER_ROAMING"
}

Der CPID-Endpunkt MUSS je nach Szenario Folgendes zurückgeben:

  1. Wenn eine CPID-Anfrage für einen Nutzer eingeht, der nicht zum Betreibernetzwerk gehört (z.B. ein Nutzer, der zu einem anderen Betreiber gehört, aber im Netzwerk dieses CPID-Endpunkts roamt) oder der nicht zugestimmt hat, Informationen zum Datentarif mit Google zu teilen, MUSS der CPID-Endpunkt den HTTP-Statuscode 403 mit USER_ROAMING, USER_OPT_OUT oder INELIGIBLE_FOR_SERVICE als Ursache zurückgeben.
  2. Wenn eine CPID-Anfrage mit einer ungültigen Telefonnummer eingeht, MUSS der CPID-Endpunkt HTTP 400 mit dem Fehlergrund INVALID_NUMBER zurückgeben.
  3. Wenn die Anfrage an den CPID-Endpunkt auf andere Weise fehlerhaft ist, MUSS der CPID-Endpunkt HTTP 400 mit ERROR_CAUSE_UNSPECIFIED als Ursache zurückgeben.
  4. Für andere Fehlerursachen ist jeder kompatible HTTP-Fehlercode zulässig. Insbesondere HTTP 500 ist ein geeigneter Fehlergrund für jeden internen Fehler am CPID-Endpunkt.