FPNV Technical Carrier Onboarding Guide

Letzte Änderung: 10. September 2025

Übersicht

In diesem Dokument werden alle erforderlichen Schritte beschrieben, um einen Mobilfunkanbieter über TS.43-Telefonnummerbestätigungen in die Firebase-Telefonnummerbestätigung (Firebase Phone Number Verification, FPNV) aufzunehmen.

Terminologie

Beteiligte Parteien

• CSP: Communications Service Provider (Anbieter von Kommunikationsdiensten)
  • z.B. Mobilfunkanbieter
• Aggregatoren
  • App-Facing Aggregators: Aggregator, mit dem Apps eine Bestätigung durchführen können, ohne dass die App direkt mit dem Mobilfunkanbieter interagiert.
  • z.B. Firebase-Bestätigung der Telefonnummer
  • Meta-Aggregator: Aggregator, der den Mobilfunkanbieter beim Onboarding für einen app-orientierten Aggregator unterstützt
    • Ein Meta-Aggregator könnte für die Einrichtung der Berechtigungsserver für die Mobilfunkanbieter und/oder die Konfiguration der Details der Berechtigungsserver mit den app-orientierten Aggregatoren verantwortlich sein.
• FPNV: Firebase Phone Number Verification (Firebase-Bestätigung der Telefonnummer)
• Google TAM: Google Technical Account Manager, der das Onboarding des Mobilfunkanbieters für FPNV unterstützt
• Android Telephony: Bietet Telefonnummer-APIs für Android, einschließlich einer Plattform für Mobilfunkanbieter und Aggregatoren zur Bereitstellung von TS.43-Bestätigungen.
• GSMA: Verband von Mobilfunknetzbetreibern, der Spezifikationen wie TS.43 definiert.
• CAMARA: Open-Source-Projekt für Linux, in dem Carrier-APIs in Zusammenarbeit mit der GSMA definiert werden

Bedingungen für die Bestätigung

• PNV: Bestätigung der Telefonnummer
• TS.43: Definiert das Protokoll für die Kommunikation zwischen Mobilgeräten und Servern mit dem Mobilfunkanbieter über HTTP.
• EAP-AKA: Authentifizierungsmethode, die in https://www.rfc-editor.org/rfc/rfc4187 definiert ist und keine Interaktion mit dem Nutzer erfordert
• ECS: Entitlement Configuration Server (Server für die Bezugskonfiguration)
  • Einstiegspunkt für den Aggregator, um mit dem Mobilfunkanbieter zu kommunizieren
• ODSA: On-Device Service Activation (Aktivierung von Diensten auf dem Gerät)
  • Bezieht sich auf verschiedene vom ECS bereitgestellte Vorgänge zum Aktivieren von Diensten auf dem Gerät
  • z.B. AcquireTemporaryToken; GetPhoneNumber

Berechtigungsserver des Mobilfunkanbieters und PNV-Endpunkt

Erforderliche Endpunkte erstellen

ACTION1: Der Mobilfunkanbieter implementiert die folgenden Endpunkte, die alle über das Internet zugänglich sind. Weitere Informationen zur Implementierung finden Sie in Anhang A.

Technische Anforderungen

Allgemeine Leistung: Die Betriebszeit aller Endpunkte muss mindestens 99,99 % betragen.

Sicherheit: Aus Sicherheitsgründen müssen die Endpunkte des Mobilfunkanbieters die folgenden Anforderungen erfüllen:

• EAP-AKA-Auth-Token: Muss innerhalb von einer Stunde ablaufen
• Temporäres Token: Einmalige Verwendung mit einer Ablaufzeit von 5 Minuten
• Option 1: Vanilla TS.43
  • OAuth-Token: Muss innerhalb von einer Stunde ablaufen
• Option 2: CAMARA
  • CAMARA-Zugriffstoken: Einmalige Verwendung mit einer Ablaufzeit von 5 Minuten

API-Datenqualität: 100% der Inhalte erfolgreicher Antworten (d. h. die MSISDN sollte korrekt sein).

FPNV unterstützt zwei Varianten von TS.43. Der Hauptunterschied besteht darin, wie der FPNV-Server das temporäre Token mit dem Mobilfunkanbieter austauscht.

• Vanilla TS.43: Bezieht sich auf die Implementierung gemäß der Spezifikation TS.43.
• CAMARA: Bezieht sich auf die Implementierung gemäß dem JWT-Bearer-Flow von CAMARA.

Option 1: TS.43-Implementierung ohne Anpassungen

Anfragen von Android-Geräten

1. EAP-AKA-Endpunkt: Auth-Token zurückgeben
2. AcquireTemporaryToken-Endpunkt: Gibt bei Angabe des Auth-Tokens ein TempToken zurück.

Anfragen vom FPNV-Server

1. OAuth 2.0-Endpunkt – OAuth-Client-ID/Schlüssel-Ablauf: Gib anhand der OAuth-Client-ID/des Schlüssels ein OAuth-Zugriffstoken zurück.
2. GetPhoneNumber-Endpunkt: Gibt die entsprechende Telefonnummer anhand des OAuth-Zugriffstokens und des TempToken zurück.

Option 2: CAMARA-Implementierung

Die CAMARA-Implementierung ähnelt der TS.43-Implementierung, mit Ausnahme der Endpunkte zur Verarbeitung der Anfragen vom FPNV-Server.

Anfragen von Android-Geräten

1. EAP-AKA-Endpunkt: Auth-Token zurückgeben
2. AcquireTemporaryToken-Endpunkt: Gibt bei einem Auth-Token ein TempToken zurück.

Anfragen vom FPNV-Server

1. OAuth 2.0-Endpunkt – JWT-Inhaberfluss: Gibt ein CAMARA-Zugriffstoken zurück, wenn ein JWT mit dem TempToken angegeben wird.
2. CAMARA NumberVerification v2-Endpunkt: Gibt die entsprechende Telefonnummer für das CAMARA-Zugriffstoken zurück.

Onboarding für Android-Telefonie und FPNV

Mobilfunkanbieter-Test-App

AKTION 2: Der Mobilfunkanbieter wendet sich an den technischen Account Manager (TAM) von Google. Der TAM stellt dem Mobilfunkanbieter die FPNV-Test-App für Mobilfunkanbieter zur Verfügung. Diese Test-App für Mobilfunkanbieter simuliert die Anfragen, die von FPNV gesendet werden, ohne dass der FPNV-Server beteiligt ist. Mit dieser Test-App können Mobilfunkanbieter prüfen, ob ihre Endpunkte richtig funktionieren.

ACTION3: Der Mobilfunkanbieter prüft mit der FPNV-Test-App, ob die oben genannten Endpunkte durchgängig funktionieren.

Erforderliche Produktionskonfigurationen einrichten

Android-Konfiguration – EAP-AKA / AcquireTempToken

ACTION4: Der Mobilfunkanbieter definiert seine Produktionskonfiguration für seine EAP-AKA-/AcquireTempToken-Anfragen von Android Telephony.

• Konfiguration:
  • Die Canonical Carrier ID für Android dieses Mobilfunkanbieters
  • TS.43 use_cases-Werte: use_case=GetPhoneNumber
  • URL des Berechtigungsservers für die Produktion für EAP-AKA/AcquireTempToken
  • SAN und Fingerabdruck des x509-Produktionszertifikats von Firebase
  • SAN: fpnv.googleapis.com
  • Fingerabdruck: aad068c93399a22fc2b11ab58468e8cb72b8f9fc53700991799a8b764c589c7e

Firebase-Konfiguration – TempToken gegen Telefonnummer tauschen

ACTION5: Firebase-Anmeldedaten zum Abrufen eines OAuth-Tokens vom Mobilfunkanbieter

• Vanilla TS.43
  • Der Mobilfunkanbieter erstellt die OAuth-Client-ID und das Secret für die Anfragen von FPNV. Der Mobilfunkanbieter konfiguriert dann seinen OAuth-Endpunkt so, dass ein Zugriffstoken für diese Anmeldedaten zurückgegeben wird.
• CAMARA
  • Google TAM stellt den öffentlichen Schlüssel von Google bereit, damit der OAuth-Endpunkt des Mobilfunkanbieters überprüfen kann, ob das JWT von Google signiert wurde.

ACTION6: Der Mobilfunkanbieter definiert eine Produktionskonfiguration für den FPNV-Server, um das TempToken gegen ein Telefon einzutauschen.

• Die Canonical Carrier ID für Android dieses Mobilfunkanbieters
• Vanilla TS.43
  • OAuth – Client-ID/Schlüssel-Ablauf
  • OAuth-Endpunkt-URL
  • OAuth-Client-ID/Schlüssel
  • OAuth-Bereich (falls vorhanden)
  • GetPhoneNumber
  • Endpunkt-URL für GetPhoneNumber
• CAMARA
  • OAuth – JWT-Inhaber-Flow
  • OAuth-Endpunkt-URL
  • NumberVerification API Version 2
  • URL des NumberVerification-Endpunkts

Anmeldedaten/Konfigurationen teilen

Bestätigung der Telefonnummer mit Firebase

ACTION7: Der Mobilfunkanbieter teilt seine Produktionskonfiguration aus ACTION4 und ACTION6 mit dem Google Technical Account Manager.

• [WICHTIG] Das OAuth-Geheimnis muss über einen sicheren Out-of-Band-Mechanismus (keine E-Mails, keine Dokumente usw.) an Google weitergegeben werden. Dieser Out-of-Band-Mechanismus wird vom Mobilfunkanbieter und vom Google TAM vereinbart.

ACTION8: Google TAM prüft, ob die Konfiguration mit der Test-App des Mobilfunkanbieters durchgängig funktioniert. Anschließend speichert Google TAM die OAuth-Anmeldedaten in einem sicheren Google-Speicher und aktualisiert die Konfigurationen von FPNV, um das TempToken gegen ein Telefon einzutauschen (d.h. die Konfigurationen von ACTION6).

Android-Telefonie

ACTION9: Der Mobilfunkanbieter folgt dem Dokument „Google Open Gateway CSP Onboarding“ (das der Google TAM mit dem Mobilfunkanbieter teilt). Der Mobilfunkanbieter oder sein Google TAM erstellt ein Buganizer-Ticket für das Onboarding in die Android Telephony-Konfiguration: https://issuetracker.google.com/issues/new?component=1861595&template=2168610. Bei diesem Fehler wird die Produktionskonfiguration von ACTION4 übernommen.

Wenn ein Meta-Aggregator die FPNV-Integration im Namen des Mobilfunkanbieters einrichtet, muss eine Einwilligungserklärung (E-Mail, PDF, Brief usw.) der Führungsebene des Mobilfunkanbieters (Director oder höher) die Geschäftsbeziehung mit dem betreffenden Betreiber bestätigen. Anschließend kann der Meta-Aggregator die Konfiguration des Mobilfunkanbieters im Namen des Mobilfunkanbieters an Android Telephony senden.

Anhang A. Detaillierte Implementierung

Groß-/Kleinschreibung

• Bei HTTP-Headern wird nicht zwischen Groß- und Kleinschreibung unterschieden.
• Bei XML- und JSON-Formaten muss die Groß- und Kleinschreibung beachtet werden. Achten Sie also darauf, dass die Felder für Anfragen und Antworten genau mit dieser Dokumentation übereinstimmen.

Schritt 1: EAP-AKA / AcquireTempToken

Endpunkte: EAP-AKA und AcquireTempToken müssen denselben ECS-Endpunkt verwenden.

EAP-AKA-Herausforderung

Referenzen: TS.43 v12.0 – Abschnitt 2.8.1 – „Embedded EAP-AKA Authentication by Entitlement Configuration Server“.

EAP-AKA, Schritt 1 – Authentifizierungsaufforderung

EAP-AKA #1 – GET-Anfrage an ECS

Das Android Telephony-Modul sendet eine TS.43 EAP-AKA-Anfrage an den Berechtigungsserver des Mobilfunkanbieters.

Anfrageheader von Android

• Accept: application/vnd.gsma.eap-relay.v1.0+json
  • Es handelt sich um ein JSON-Format, das speziell für die GSMA entwickelt wurde und nicht nur für application/json.

Anfragefelder von Android

• eap_id: Siehe RCC.14, Anhang C
  • z.B. 0<IMSI>@<realm>.mnc<MNC>.mcc<MCC>.3gppnetwork.org
• GID1: Nur angegeben, wenn die Berechtigungsversion 12.0 ist
• app_name: Der codierte AppName hat einen MD5-Hashwert des Anwendungsfalls, der die Telefonnummerüberprüfung durchführt:
  • Alle an Apps gerichteten Aggregatoranfragen haben den App-Namen Google-OGI.
• app: Die App-ID ap2014 steht für Telefonnummerinformationen.
• terminal_vendor/model/sw_version: Auf einen beliebigen Wert festlegen. Android garantiert nicht, dass diese Felder die tatsächlichen Geräteinformationen enthalten.
• vers: Konfigurationsversion, z.B. 0 oder 1
• entitlement_version: Google konfiguriert die Berechtigungsversion, die an die Mobilfunkanbieter gesendet wird, basierend auf den Anforderungen des Mobilfunkanbieters.
  • Normalerweise ist entitlement_version 10.0 oder 12.0.

EAP-AKA #1 – Antwort von ECS

ECS-Antwortheader

• Content-Type: Unter Android wird erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. application/vnd.gsma.eap-relay.v1.0+json

ECS-Antwortfelder

• eap-relay-packet: Enthält das EAP-Paket gemäß RCC.14 – Abschnitt C.2

EAP-AKA-Schritt 2 – Auth-Token abrufen

EAP-AKA #2 – POST-Anfrage an ECS

Das Android-Telefonie-Modul sendet dann die empfangene eap-relay-packet an denselben Endpunkt zurück.

Anfrageheader von Android

• Accept: Unter Android werden zwei Accept-Header festgelegt:
  • application/vnd.gsma.eap-relay.v1.0+json: Bezieht sich auf den Mobilfunkanbieter, der wieder JSON zurückgibt, wenn das Gerät eine weitere EAP-AKA-Anfrage senden muss.
  • text/vnd.wap.connectivity-xml: Bezieht sich auf das tatsächliche Format, in dem Android erwartet, dass der Mobilfunkanbieter das EAP-AKA-Authentifizierungstoken zurückgibt.
• Content-Type: application/vnd.gsma.eap-relay.v1.0+json

Anfragefelder von Android

• eap-relay-packet: Enthält das eap-relay-Paket der vorherigen EAP-AKA-Antwort, aber im EAP-Response/AKA-Challenge-Format gemäß RFC 4817, Abschnitt 9.2.

EAP-AKA 2 – Antwort von ECS

Nach einer erfolgreichen EAP-AKA-Authentifizierung gibt der Mobilfunkanbieter ein Authentifizierungstoken zurück.

ECS-Antwortheader

• Content-Type: Android erwartet, dass die Antwort, die mit dem Accept-Header der Anfrage übereinstimmt,
  • Android erwartet also, dass die Antwort mit dem Auth-Token den Typ text/vnd.wap.connectivity-xml hat.
  • Der andere Accept-Header, application/vnd.gsma.eap-relay.v1.0+json, wird verwendet, wenn der Mobilfunkanbieter möchte, dass Android eine weitere EAP-AKA-Anfrage ausführt.

ECS-Antwortfelder

• TOKEN.token: Enthält das Auth-Token
• TOKEN.validity: Anzahl der Sekunden, die die Antwort gültig ist, nachdem das Gerät die Antwort empfangen hat.
  • Google prüft, ob das Autorisierungstoken den technischen Anforderungen entspricht.

AcquireTemporary Token

AcquireTempToken – GET-Anfrage an ECS

Mit dem vom EAP-AKA erhaltenen Authentifizierungstoken ruft der Android-Client das temporäre Token ab, indem er den AcquireTemporaryToken-Endpunkt des Mobilfunkanbieters aufruft. Die Anfrage

• Beispiel: TS.43 v12.0 – Abschnitt 6.4.6 – „AcquireTemporaryToken Request Example“
• AcquireTempToken hat ähnliche Parameter wie EAP-AKA #1, mit folgenden Ausnahmen:
  • AcquireTempToken gibt auch IMSI, operation und operation_targets an.
  • In AcquireTempToken ist EAP_ID nicht angegeben.

Anfrageheader von Android

• Accept: Android legt text/vnd.wap.connectivity-xml fest.

Anfragefelder von Android

• terminal_vendor/model/sw_version: Android garantiert nicht, dass diese Felder die tatsächlichen Informationen des Geräts enthalten.
• operation_targets
  • FPNV: Das Betriebsziel ist GetPhoneNumber

AcquireTempToken – Antwort von ECS

Beispiel: TS.43 v12.0 – Abschnitt 6.6.6 – „AcquireTemporaryToken Response Example“

ECS-Antwortheader

• Content-Type: Unter Android wird erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. text/vnd.wap.connectivity-xml

ECS-Antwortfelder

• APPLICATION.TemporaryToken: TemporaryToken, den der FPNV-Server dann gegen eine Telefonnummer eintauschen kann
• APPLICATION.TemporaryTokenExpiry: Ablaufzeit im Format JJJJ-MM-TTThh:mm:ssTZD
  • Google prüft, ob das Ablaufdatum von TempToken den technischen Anforderungen entspricht.
• APPLICATION.OperationResult: Siehe TS.43 v12.0 – Abschnitt 6.5.1
  • Wenn die Vorgänge als SUCCESS angegeben sind, geben Sie 1 zurück.

Schritt 2: TempToken gegen Telefonnummer eintauschen

Option 1: Vanilla TS.43

abstrahiert.

Endpunkte: OAuth- und GetPhoneNumber-Endpunkte können sich auf unterschiedlichen Servern befinden. Diese Endpunkte können sich auch vom EAP-AKA-/AcquireTempToken-Endpunkt unterscheiden.

OAuth

Der Mobilfunkanbieter sollte dieser OAuth-Anleitung folgen und Google die erforderlichen OAuth-Informationen (Client-ID, Clientschlüssel, OAuth-Server-URL) zur Verfügung stellen.

OAuth – POST-Anfrage an den Authentifizierungsserver des Mobilfunkanbieters

FPNV-Anfrageheader

• Authorization: Mit FPNV wird Basic $BASE64_ENCODED_CREDENTIALS festgelegt.
  • Die base64-codierten Anmeldedaten sind die Base64-Codierung von OAuth $CLIENT_ID:$CLIENT_SECRET.
• Content-Type: FPNV legt application/x-www-form-urlencoded fest.
• Accept: FPNV legt application/json fest.

Felder für FPNV-Anfragen

• grant_type: client_credentials

POST HTTP/1.1
Host: $OAUTH_ENDPOINT
Authorization: Basic $BASE64_ENCODED_CREDENTIALS
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=client_credentials

OAuth – Antwort vom Auth-Server des Mobilfunkanbieters

Antwortheader des Mobilfunkanbieters

• Content-Type: FPNV erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. application/json

Antwortfelder des Mobilfunkanbieters

• access_token: OAuth-Zugriffstoken
• token_type: bearer
• expires_in: Ablauf des OAuth-Zugriffstokens in Sekunden
  • Google prüft, ob die Ablaufzeit des OAuth-Tokens den technischen Anforderungen entspricht.

200 OK
Content-Type: application/json

{
  "access_token": $ACCESS_TOKEN,
  "token_type": "bearer",
  "expires_in": $EXPIRATION_IN_SECS,
}

GetPhoneNumber

GetPhoneNumber – POST-Anfrage an ECS

Der Google-Bestätigungsserver ruft die Telefonnummer über den Vorgang GetPhoneNumber ab.

• Beispiel: TS.43 v12.0 – Abschnitt 6.4.7 – „GetPhoneNumber Request Example“

Anfrageheader von FPNV

• Accept: application/json
• Content-Type: application/json

Anfragefelder von FPNV

• requestor_id: Gibt den Dienst an, der den TS.43-Vorgang „GetPhoneNumber“ aufruft.
  • UUID für die Firebase-Telefonnummernüberprüfung: 191fd7cc-f7cd-4bb4-a5d2-455ae1fb9a19
• temporary_token: TemporaryToken aus AcquireTempToken
• access_token: OAuth-Token für Google zur Authentifizierung beim Mobilfunkanbieter
• terminal_vendor/model/sw_version: FPNV füllt diese Felder mit beliebigen Werten.
• entitlement_version: Google konfiguriert die Berechtigungsversion, die an die Mobilfunkanbieter gesendet wird, basierend auf den Anforderungen des Mobilfunkanbieters.
  • Normalerweise ist entitlement_version 10.0 oder 12.0.
• app: FPNV legt ap2014 fest.
• app_name: FPNV legt firebase für alle FPNV-Anfragen fest.
  • Hinweis: „AcquireTempToken“ hat unabhängig vom verwendeten Aggregator einen app_name von Google-OGI.
• operation: FPNV legt GetPhoneNumber fest.

GetPhoneNumber – Antwort von ECS

Beispiel: TS.43 v12.0 – Abschnitt 6.6.7 – „GetPhoneNumberResponse Example“

Antwortheader des Mobilfunkanbieters

• Content-Type: FPNV erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. application/json

Antwortfelder des Mobilfunkanbieters

• ap2014.MSISDN: FPNV erwartet, dass die Telefonnummer im E164-Format zurückgegeben wird.
  • Bei JSON wird die Groß-/Kleinschreibung beachtet. Die MSISDN muss also in Großbuchstaben angegeben werden.

Fehlercodes für temporäre Tokens

Verweise aus TS.43 v12.0, Abschnitt 2.8.6.

In der folgenden Tabelle sind die Fehlerantworten aufgeführt, die der ECS für GetPhoneNumber-Anfragen an den Google-Bestätigungsserver zurückgeben muss:

Option 2 – CAMARA

Endpunkte: Das Abrufen des CAMARA-Zugriffstokens und das Abrufen der Telefonnummer können über unterschiedliche Server/Endpunkte erfolgen. Diese Endpunkte können sich auch vom EAP-AKA-Endpunkt bzw. vom AcquireTempToken-Endpunkt unterscheiden.

OAuth – CAMARA-Zugriffstoken abrufen

Google unterstützt nur den JWT-Bearer-Ablauf von CAMARA und nicht den CIBA-Ablauf.

CAMARA-Zugriffstoken – POST-Anfrage an Mobilfunkanbieter

Google erstellt ein JWT mit den folgenden Feldern.

• iss: Aussteller des JWT (auch Client-ID)
  • z.B. firebase (tatsächliche FPNV-Integration) oder fpnv-carrier-tester-app (Test-App des Mobilfunkanbieters)
• sub: Betreff des JWT
  • z.B. operatortoken:$TEMP_TOKEN
• aud: Zielgruppe; Empfänger, für die das JWT bestimmt ist
  • URL des Token-Endpunkts (d.h. URL des Autorisierungsservers)
• exp: Ablaufzeit in Sekunden
  • Google sendet eine Ablaufdauer, die der Gültigkeitsdauer des CAMARA-Zugriffstokens entspricht (siehe Technische Anforderungen).
• iat: Ausgestellt zum Zeitpunkt in Sekunden
• jti: Eindeutige Kennung zur Vermeidung von Replay-Angriffen
  • z.B. zufällig generierte UUID
• scope: Zweck der Anfrage
  • z.B. dpv:FraudPreventionAndDetection number-verification:device-phone-number:read

{
  "iss": "firebase",
  "sub": "operatortoken:ey...",
  "aud": $OAUTH_ENDPOINT,
  "exp": $EXPIRATION_TIME_IN_SECS,
  "iat": $ISSUED_AT_TIME_IN_SECS,
  "jti": $RANDOMLY_GENERATED_UUID,
  "scope": "dpv:FraudPreventionAndDetection number-verification:device-phone-number:read"
}

FPNV signiert das JWT mit seinem eigenen privaten Schlüssel und der Mobilfunkanbieter kann das JWT mit dem entsprechenden öffentlichen Schlüssel validieren. FPNV stellt den öffentlichen Schlüssel über einen JWKS-Endpunkt bereit. Mobilfunkanbieter sollten diesen JWKS-Endpunkt regelmäßig nach dem öffentlichen Schlüssel abfragen (z.B. einmal täglich), da FPNV die öffentlichen Schlüssel in regelmäßigen Abständen rotiert (z.B. einmal alle 30 Tage).

Anfrageheader von FPNV

• Content-Type: application/x-www-form-urlencoded
• Accept: application/json

Anfragefelder von FPNV

• grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
• assertion: Das oben erstellte JWT, das mit dem privaten Schlüssel von FPNV signiert wurde
  • Dieses JWT enthält das TempToken.

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=$JWT

CAMARA-Zugriffstoken – Antwort vom Mobilfunkanbieter

Antwortheader des Mobilfunkanbieters

• Content-Type: FPNV erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. application/json

Antwortfelder des Mobilfunkanbieters

• access_token: CAMARA-Zugriffstoken, das später gegen eine Telefonnummer eingetauscht werden kann
• token_type: bearer
• expires_in: Ablauf des OAuth-Zugriffstokens in Sekunden
  • Google prüft, ob die Ablaufzeit des OAuth-Tokens den technischen Anforderungen entspricht.
• scope: Zweck der Anfrage
  • z.B. dpv:FraudPreventionAndDetection number-verification:device-phone-number:read

200 OK
Content-Type: application/json

{
  "access_token": $CAMARA_ACCESS_TOKEN,
  "token_type": "bearer",
  "expires_in": $EXPIRATION_IN_SECS,
  "scope": "dpv:FraudPreventionAndDetection number-verification:device-phone-number:read"
}

CAMARA NumberVerification API Version 2

Google tauscht dieses CAMARA-Zugriffstoken dann aus, indem es eine GET-Anfrage an den Endpunkt /device-phone-number des Mobilfunkanbieters sendet.

CAMARA NumberVerification – GET-Anfrage an Mobilfunkanbieter

Anfrageheader von FPNV

• Authorization: Bearer $CAMARA_ACCESS_TOKEN
• Accept: application/json

GET /device-phone-number
Authorization: Bearer $CAMARA_ACCESS_TOKEN
Accept: application/json
Content-Type: application/json

CAMARA NumberVerification – Antwort vom Mobilfunkanbieter

Antwortheader des Mobilfunkanbieters

• Content-Type: FPNV erwartet, dass der Antworttyp mit dem Accept-Header der Anfrage übereinstimmt.
  • z.B. application/json

Antwortfelder des Mobilfunkanbieters

• devicePhoneNumber: Gibt die Telefonnummer im E164-Format zurück.

200 OK
Content-Type: application/json

{
 "devicePhoneNumber": $PHONE_NUMBER
}