Onboarding-Leitfaden für Verifier Registrars

Übersicht

In diesem Abschnitt wird der schrittweise Prozess für Registrare von Prüfern beschrieben, um den Google Wallet Identitätsdienst zu nutzen.

Als Registrar für die Identitätsüberprüfung (z. B. ein Unternehmen für die Identitätsüberprüfung, das im Namen anderer Rechtssubjekte die Identität überprüft) fungieren Sie als eigene Zertifizierungsstelle (CA, Certificate Authority) und signieren Identitätsanfragen für die nachgelagerten End-RPs (Relying Parties), die Sie verwalten.

Onboarding-Prozess

Schritt 1: Aufnahmeformular und Stammzertifikate einreichen und Nutzungsbedingungen akzeptieren

Füllen Sie das Onboarding-Formular für Prüfer-Registrare aus und senden Sie es ab. In diesem Formular geben Sie sowohl Ihre Sandbox- als auch Ihre Produktions-Root-Zertifikate an. Durch das Senden dieses Registrierungsformulars akzeptieren Sie auch die Nutzungsbedingungen für Google Wallet Verifier Registrar.

Schritt 2: Sandbox-Vertrauen und ‑Tests

Nachdem Sie das Aufnahmeformular eingereicht haben, fügt Google Ihr Sandbox-Root-Zertifikat dem Google Wallet-Sandbox-Trust Store hinzu und benachrichtigt Sie. Anschließend können Sie mit dem Testen Ihrer Integration in der Sandbox beginnen. Verwenden Sie dazu Zertifikate, die von Ihrem Sandbox-Stammzertifikat signiert wurden.

Schritt 3: E2E-Videodemonstration aufzeichnen

Wenn die Sandbox-Tests abgeschlossen sind, zeichnen Sie End-to-End-Videodemonstrationen des Bestätigungsvorgangs für Ihre erste (1.) Relying Party auf und senden Sie sie an Google.

  • Videoanforderungen:
    • Nehmen Sie Demonstrationen für sowohl vom Prüfer gehostete (selbst gehostete) als auch vom Händler gehostete (RP-gehostete) Abläufe auf.
    • Verwenden Sie in den Videos tatsächliche Händler-Display-Assets (Name, Logo, URL der Nutzungsbedingungen) und Aggregator-Display-Assets.
    • Zeigen Sie deutlich die Benutzeroberfläche und die Bildschirme, über die der Bestätigungsvorgang gestartet wird.

Schritt 4: Genehmigung und Vertrauenswürdigkeit der Produktions-Root

Nachdem Google Ihre End-to-End-Videodemonstrationen erhalten hat, wird die Videoüberprüfung und der Genehmigungsprozess ausgelöst. Gleichzeitig wird mit dem Prozess für das Vertrauen in das Produktions-Stammzertifikat begonnen. Nachdem beide Prozesse abgeschlossen und genehmigt wurden, können Sie mit der Einführung des Dienstes für Ihre nachgelagerten End-RPs beginnen.

Schritt 5: Laufendes Onboarding von End-RPs

Für jeden End-RP, den Sie unterzeichnen, müssen Sie Folgendes tun:

  • Google informieren:Verwenden Sie das Verifier Registrar Client Onboarding Form, um Google über den neuen RP und den vorgesehenen Anwendungsfall zu informieren.
  • Metadaten konfigurieren:Geben Sie die Anzeigeinformationen des RP an (Name, Logo, URL der Datenschutzerklärung) und legen Sie in seinem Zertifikat einen global eindeutigen Distinguished Name (Subject) fest.

Technische Spezifikationen

A. Zertifikatsprofil

Anfragen müssen mit Standard-X.509-v3-Zertifikaten signiert werden, die mit P-256 / ECDSA generiert wurden und eine benutzerdefinierte Google-Erweiterung enthalten:

  • Benutzerdefinierte Erweiterungs-OID:1.3.6.1.4.1.11129.10.1
  • Wichtigkeit:Nicht kritisch.
  • Inhalt:Ein SHA256-Hash von RelyingPartyMetadataBytes, codiert in einem ASN.1-OCTET STRING.

B. Metadatenschema (CBOR)

Metadaten müssen im CBOR-Format codiert sein.

; in CDDL for CBOR encoding
; schemaVersion = "v1"

RelyingPartyMetadataBytes = #6.24(bstr .cbor RelyingPartyMetadata)


RelyingPartyMetadata = {
  "schema_version": tstr,
  "display": DisplayInfo,
  "aggregator_info": DisplayInfo  ; Optional: include to show your branding alongside the RP
}

DisplayInfo = {
  "display_name": tstr,
  "logo_uri": tstr,             ; See brand guidelines link in following paragraph
  "privacy_policy_uri": tstr
}

Das logo_uri muss den Branding-Richtlinien für Google Wallet entsprechen.

C. OpenID4VP-Integration

Wenn Sie Ihre signierte OpenID4VP-Anfrage formatieren, fügen Sie die Base64URL-codierten Metadaten im Feld gw_rp_metadata_bytes innerhalb des client_metadata-Objekts ein (siehe Beispielanfragecode im folgenden Abschnitt).

Compliance und Widerruf

  • Missbrauchsüberwachung:Google überwacht schädliche RP-Aktivitäten und benachrichtigt Sie, wenn Missbrauch erkannt wird.
  • Aufforderung zum Widerruf:Sie sind verpflichtet, Zertifikate für missbräuchliche RPs umgehend zu widerrufen und eine aktualisierte Zertifikatssperrliste (Certificate Revocation List, CRL) zu veröffentlichen.
  • Auditierung:Google führt anonymisierte Logs, um sicherzustellen, dass RP-Anfragen mit den registrierten Anwendungsfällen übereinstimmen.

Nächste Schritte

Füllen Sie das Verifier Registrar Onboarding Intake Form aus und senden Sie es ab, um mit dem Onboarding als Verifier Registrar zu beginnen. Verwenden Sie zum Onboarding nachfolgender Downstream-Clients das Verifier Registrar Client Onboarding Form (Onboarding-Formular für Verifier-Registrar-Clients).

Häufig gestellte Fragen zum Onboarding und zur Integration finden Sie unter Häufig gestellte Fragen zu Digital Identity & Credentials.

Details zur Integration des Verifier-Registrars

Im folgenden Abschnitt werden die technischen Integrationsdetails für Verifier Registrars beschrieben, die die Digital Credentials API einbinden. Dazu gehören die Formatierung von Anfragen, die Verschlüsselung von Anfragen, das Auslösen der API, die Validierung von Antworten und die Implementierung von Zero-Knowledge-Beweisen.

Unterstützte Formate und Funktionen

Google Wallet unterstützt digitale Ausweise, die auf ISO mdoc basieren.

Anfrage formatieren

Wenn Sie Anmeldedaten aus einer beliebigen Wallet anfordern möchten, müssen Sie Ihre Anfrage mit OpenID4VP formatieren. Sie können bestimmte Anmeldedaten oder mehrere Anmeldedaten in einem einzelnen dcql_query-Objekt anfordern.

Beispiel für JSON-Anfrage

Hier sehen Sie ein Beispiel für eine requestJson-Anfrage für mobile Dokumente, mit der Identitätsnachweise aus einem beliebigen Wallet auf einem Android-Gerät oder im Web abgerufen werden.

{
      "requests" : [
        {
          "protocol": "openid4vp-v1-signed",
          "data": {<signed_credential_request>} // This is an object, shouldn't be a string.
        }
      ]
}

Verschlüsselung anfordern

Das client_metadata enthält den öffentlichen Verschlüsselungsschlüssel für jede Anfrage. Sie müssen private Schlüssel für jede Anfrage speichern und damit das Token authentifizieren und autorisieren, das Sie von der Wallet App erhalten.

Integrierte OpenID4VP-Metadaten

Beim Formatieren der Anmeldedatenanfrage müssen Sie das Feld gw_rp_metadata_bytes in das Objekt client_metadata einfügen (siehe Beispielcode für die Anfrage unten). Dieses Feld enthält die Base64URL-codierten Metadaten der vertrauenden Partei, die von Google Wallet benötigt werden, um Ihre Identität zu bestätigen und Ihr Branding dem Nutzer anzuzeigen.

Der Parameter credential_request in requestJson enthält die folgenden Felder.

Spezifische Anmeldedaten

{
  "response_type": "vp_token",
  "response_mode": "dc_api.jwt", // change this to dc_api if you want to demo with a non encrypted response.
  "nonce": "1234",
  "dcql_query": {
    "credentials": [
      {
        "id": "cred1",
        "format": "mso_mdoc",
        "meta": {
          // Use org.iso.18013.5.1.mDL for mDL,
          // com.google.wallet.idcard.1 for ID pass, or
          // org.iso.23220.photoid.1 for ID pass (using photo ID document type)
          "doctype_value": "org.iso.18013.5.1.mDL"
        },
        "claims": [
          {
            "path": [
              "org.iso.18013.5.1",
              "family_name"
            ],
            "intent_to_retain": false // set this to true if you are saving the value of the field
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "given_name"
            ],
            "intent_to_retain": false
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "age_over_18"
            ],
            "intent_to_retain": false
          }
        ]
      }
    ]
  },
  "client_metadata": {
    "jwks": {
      "keys": [ // sample request encryption key
        {
          "kty": "EC",
          "crv": "P-256",
          "x": "pDe667JupOe9pXc8xQyf_H03jsQu24r5qXI25x_n1Zs",
          "y": "w-g0OrRBN7WFLX3zsngfCWD3zfor5-NLHxJPmzsSvqQ",
          "use": "enc",
          "kid" : "1",  // This is required
          "alg" : "ECDH-ES",  // This is required
        }
      ]
    },
    "vp_formats_supported": {
      "mso_mdoc": {
        "deviceauth_alg_values": [
          -7
        ],
        "issuerauth_alg_values": [
          -7
        ]
      }
    },
    "gw_rp_metadata_bytes": "<base64url encoded metadata string>"
  }
}

Alle berechtigten Qualifikationen

Hier ist die Beispielanfrage für mDL, digitalen Identitätsnachweis und digitalen Identitätsnachweis (mit Lichtbildausweis als Dokumenttyp). Der Nutzer kann mit einer der beiden Optionen fortfahren.

{
  "response_type": "vp_token",
  "response_mode": "dc_api.jwt", // change this to dc_api if you want to demo with a non encrypted response.
  "nonce": "1234",
  "dcql_query": {
    "credentials": [
      {
        "id": "mdl-request",
        "format": "mso_mdoc",
        "meta": {
          "doctype_value": "org.iso.18013.5.1.mDL"
        },
        "claims": [
          {
            "path": [
              "org.iso.18013.5.1",
              "family_name"
            ],
            "intent_to_retain": false // set this to true if you are saving the value of the field
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "given_name"
            ],
            "intent_to_retain": false
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "age_over_18"
            ],
            "intent_to_retain": false
          }
        ]
      },
      {  // Credential type 2: ID pass
        "id": "id_pass-request",
        "format": "mso_mdoc",
        "meta": {
          "doctype_value": "com.google.wallet.idcard.1"
        },
        "claims": [
          {
            "path": [
              "org.iso.18013.5.1",
              "family_name"
            ],
            "intent_to_retain": false // set this to true if you are saving the value of the field
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "given_name"
            ],
            "intent_to_retain": false
          },
          {
            "path": [
              "org.iso.18013.5.1",
              "age_over_18"
            ],
            "intent_to_retain": false
          }
        ]
      },
      {  // Credential type 3: ID pass (using photo ID document type)
        "id": "photo_id-request",
        "format": "mso_mdoc",
        "meta": {
          "doctype_value": "org.iso.23220.photoid.1"
        },
        "claims": [
          {
            "path": [
              "org.iso.23220.1",
              "family_name"
            ],
            "intent_to_retain": false // set this to true if you are saving the value of the field
          },
          {
            "path": [
              "org.iso.23220.1",
              "given_name"
            ],
            "intent_to_retain": false
          },
          {
            "path": [
              "org.iso.23220.1",
              "age_over_18"
            ],
            "intent_to_retain": false
          }
        ]
      }
    ]
    credential_sets : [
      {
        "options": [
          [ "mdl-request" ],
          [ "id_pass-request" ],
          [ "photo_id-request" ]
        ]
      }
    ]
  },
  "client_metadata": {
    "jwks": {
      "keys": [ // sample request encryption key
        {
          "kty": "EC",
          "crv": "P-256",
          "x": "pDe667JupOe9pXc8xQyf_H03jsQu24r5qXI25x_n1Zs",
          "y": "w-g0OrRBN7WFLX3zsngfCWD3zfor5-NLHxJPmzsSvqQ",
          "use": "enc",
          "kid" : "1",  // This is required
          "alg" : "ECDH-ES",  // This is required
        }
      ]
    },
    "vp_formats_supported": {
      "mso_mdoc": {
        "deviceauth_alg_values": [
          -7
        ],
        "issuerauth_alg_values": [
          -7
        ]
      }
    },
    "gw_rp_metadata_bytes": "<base64url encoded metadata string>"
  }
}

Sie können eine beliebige Anzahl von unterstützten Attributen aus einem in Google Wallet gespeicherten Identitätsnachweis anfordern.

Signierte Anfragen

Signierte Anfragen (JWT-gesicherte Autorisierungsanfragen) kapseln Ihre Anfrage für die überprüfbare Darstellung in einem kryptografisch signierten JSON Web Token (JWT) mithilfe Ihrer PKI-Infrastruktur. So wird die Integrität der Anfrage sichergestellt und Ihre Identität gegenüber Google Wallet nachgewiesen.

Vorbereitung

Bevor Sie die Codeänderungen für signierte Anfragen implementieren, müssen Sie Folgendes sicherstellen:

  • Privater Schlüssel:Sie benötigen einen privaten Schlüssel (z. B. Elliptic Curve ES256), um die Anfrage zu signieren. Dieser wird auf Ihrem Server verwaltet.
  • Zertifikat:Sie benötigen ein Standard-X.509-Zertifikat, das von Ihrem Schlüsselpaar abgeleitet ist.
  • Registrierung:Ihr öffentliches Zertifikat muss bei Google Wallet registriert sein.

Logik für die Erstellung von Anfragen

Um eine Anfrage zu erstellen, müssen Sie Ihren privaten Schlüssel verwenden und die Nutzlast in eine JWS einbetten.

def construct_openid4vp_request(
    doctypes: list[str],
    requested_fields: list[dict],
    nonce_base64: str,
    jwe_encryption_public_jwk: jwk.JWK,
    is_zkp_request: bool,
    is_signed_request: bool,
    state: dict,
    origin: str
) -> dict:

    # ... [Existing logic to build 'presentation_definition' and basic 'request_payload'] ...

    # ------------------------------------------------------------------
    # SIGNED REQUEST IMPLEMENTATION (JAR)
    # ------------------------------------------------------------------
    if is_signed_request:
        try:
            # 1. Load the Verifier's Certificate
            # We must load the PEM string into a cryptography x509 object
            verifier_cert_obj = x509.load_pem_x509_certificate(
                CERTIFICATE.encode('utf-8'),
                backend=default_backend()
            )

            # 2. Calculate Client ID (x509_hash)
            # We calculate the SHA-256 hash of the DER-encoded certificate.
            cert_der = verifier_cert_obj.public_bytes(serialization.Encoding.DER)
            verifier_fingerprint_bytes = hashlib.sha256(cert_der).digest()

            # Create a URL-safe Base64 hash (removing padding '=')
            verifier_fingerprint_b64 = base64.urlsafe_b64encode(verifier_fingerprint_bytes).decode('utf-8').rstrip("=")

            # Format the client_id as required by the spec
            client_id = f'x509_hash:{verifier_fingerprint_b64}'

            # 3. Update Request Payload with JAR specific fields
            request_payload["client_id"] = client_id

            # Explicitly set expected origins to prevent relay attacks
            # Format for android origin: origin = android:apk-key-hash:<base64SHA256_ofAppSigningCert>
            # Format for web origin: origin = <origin_url>
            if origin:
                request_payload["expected_origins"] = [origin]

            # 4. Create Signed JWT (JWS)
            # Load the signing private key
            signing_key = jwk.JWK.from_pem(PRIVATE_KEY.encode('utf-8'))

            # Initialize JWS with the JSON payload
            jws_token = jws.JWS(json.dumps(request_payload).encode('utf-8'))

            # Construct the JOSE Header
            # 'x5c' (X.509 Certificate Chain) is critical: it allows the wallet
            # to validate your key against the one registered in the console.
            x5c_value = base64.b64encode(cert_der).decode('utf-8')

            protected_header = {
                "alg": "ES256",                 # Algorithm (e.g., ES256 or RS256)
                "typ": "oauth-authz-req+jwt",   # Standard type for JAR
                "kid": "1",                     # Key ID
                "x5c": [x5c_value]              # Embed the certificate
            }

            # Sign the token
            jws_token.add_signature(
                key=signing_key,
                alg=None,
                protected=json_encode(protected_header)
            )

            # 5. Return the Request Object
            # Instead of returning the raw JSON, we return the signed JWT string
            # under the 'request' key.
            return {"request": jws_token.serialize(compact=True)}

        except Exception as e:
            print(f"Error signing OpenID4VP request: {e}")
            return None

    # ... [Fallback for unsigned requests] ...
    return request_payload

API auslösen

Die gesamte API-Anfrage sollte serverseitig generiert werden. Je nach Plattform übergeben Sie das generierte JSON an die Plattform-APIs.

In-App (Android)

So fordern Sie Identitätsnachweise von Ihren Android-Apps an:

Abhängigkeiten aktualisieren

Aktualisieren Sie in der Datei „build.gradle“ Ihres Projekts die Abhängigkeiten, um Credential Manager (Beta) zu verwenden:

dependencies {
    implementation("androidx.credentials:credentials:1.5.0-beta01")
    implementation("androidx.credentials:credentials-play-services-auth:1.5.0-beta01")
}

Credential Manager konfigurieren

Fügen Sie zum Konfigurieren und Initialisieren eines CredentialManager-Objekts eine ähnliche Logik wie die folgende hinzu:

// Use your app or activity context to instantiate a client instance of CredentialManager.
val credentialManager = CredentialManager.create(context)

Attribute zur Identität anfordern

Anstatt einzelne Parameter für Identitätsanfragen anzugeben, stellt die App sie alle zusammen als JSON-String innerhalb von CredentialOption bereit. Der Credential Manager übergibt diesen JSON-String an die verfügbaren digitalen Wallets, ohne seinen Inhalt zu prüfen. Jede Wallet ist dann für Folgendes verantwortlich: - Parsen des JSON-Strings, um die Identitätsanfrage zu verstehen. – Ermitteln, welche der gespeicherten Anmeldedaten die Anfrage erfüllen.

Wir empfehlen Partnern, ihre Anfragen auch für Android-App-Integrationen auf dem Server zu erstellen.

Sie verwenden die requestJson aus Anfrageformat als request im GetDigitalCredentialOption()-Funktionsaufruf.

// The request in the JSON format to conform with
// the JSON-ified Digital Credentials API request definition.
val requestJson = generateRequestFromServer()
val digitalCredentialOption =
    GetDigitalCredentialOption(requestJson = requestJson)

// Use the option from the previous step to build the `GetCredentialRequest`.
val getCredRequest = GetCredentialRequest(
    listOf(digitalCredentialOption)
)

coroutineScope.launch {
    try {
        val result = credentialManager.getCredential(
            context = activityContext,
            request = getCredRequest
        )
        verifyResult(result)
    } catch (e : GetCredentialException) {
        handleFailure(e)
    }
}

Anmeldedaten-Antwort verarbeiten

Sobald Sie eine Antwort von der Wallet erhalten haben, prüfen Sie, ob die Antwort erfolgreich ist und die credentialJson-Antwort enthält.

// Handle the successfully returned credential.
fun verifyResult(result: GetCredentialResponse) {
    val credential = result.credential
    when (credential) {
        is DigitalCredential -> {
            val responseJson = credential.credentialJson
            validateResponseOnServer(responseJson) // make a server call to validate the response
        }
        else -> {
            // Catch any unrecognized credential type here.
            Log.e(TAG, "Unexpected type of credential ${credential.type}")
        }
    }
}

// Handle failure.
fun handleFailure(e: GetCredentialException) {
  when (e) {
        is GetCredentialCancellationException -> {
            // The user intentionally canceled the operation and chose not
            // to share the credential.
        }
        is GetCredentialInterruptedException -> {
            // Retry-able error. Consider retrying the call.
        }
        is NoCredentialException -> {
            // No credential was available.
        }
        else -> Log.w(TAG, "Unexpected exception type ${e::class.java}")
    }
}

Die credentialJson-Antwort enthält ein verschlüsseltes identityToken (JWT), das vom W3C definiert wird. Die Wallet App ist für die Erstellung dieser Antwort verantwortlich.

Beispiel:

{
  "protocol" : "openid4vp-v1-signed",
  "data" : {
    <encrpted_response>
  }
}

Sie geben diese Antwort an den Server zurück, um ihre Authentizität zu bestätigen. Schritte zum Validieren der Anmeldedatenantwort

Web

Wenn Sie Identitätsanmeldedaten mit der Digital Credentials API in Chrome oder anderen unterstützten Browsern anfordern möchten, stellen Sie die folgende Anfrage.

const credentialResponse = await navigator.credentials.get({
          digital : {
          requests : [
            {
              protocol: "openid4vp-v1-signed",
              data: {<credential_request>} // This is an object, shouldn't be a string.
            }
          ]
        }
      })

Senden Sie die Antwort von dieser API zurück an Ihren Server, um die Anmeldedatenantwort zu validieren.

Antwort validieren

Sobald das Wallet das verschlüsselte identityToken (JWT) zurückgibt, müssen Sie eine strenge serverseitige Validierung durchführen, bevor Sie den Daten vertrauen.

Antwort entschlüsseln

Verwenden Sie den privaten Schlüssel, der dem öffentlichen Schlüssel entspricht, der in der client_metadata der Anfrage gesendet wurde, um das JWE zu entschlüsseln. Das Ergebnis ist ein vp_token.

Python-Beispiel:

  from jwcrypto import jwe, jwk

  # Retrieve the Private Key from Datastore
  reader_private_jwk = jwk.JWK.from_json(jwe_private_key_json_str)
  # Save public key thumbprint for session transcript
  encryption_public_jwk_thumbprint = reader_private_jwk.thumbprint()


  # Decrypt the JWE encrypted response from Google Wallet
  jwe_object = jwe.JWE()
  jwe_object.deserialize(encrypted_jwe_response_from_wallet)
  jwe_object.decrypt(reader_private_jwk)
  decrypted_payload_bytes = jwe_object.payload
  decrypted_data = json.loads(decrypted_payload_bytes)

decrypted_data führt zu einem vp_token-JSON mit den Anmeldedaten.

  {
    "vp_token":
    {
      "cred1": ["<base64UrlNoPadding_encoded_credential>"] // This applies to OpenID4VP 1.0 spec.
    }
  }

  1. Sitzungstranskript erstellen

    Als Nächstes erstellen Sie das SessionTranscript aus ISO/IEC 18013-5:2021 mit einer Android- oder webspezifischen Übergabestruktur:

    SessionTranscript = [
  null,                // DeviceEngagementBytes not available
  null,                // EReaderKeyBytes not available
  [
    "OpenID4VPDCAPIHandover",
    AndroidHandoverDataBytes   // BrowserHandoverDataBytes for Web
  ]
]

    Sowohl für Android- als auch für Web-Übergaben müssen Sie dieselbe Nonce verwenden, mit der Sie credential_request generiert haben.

    Android-Übergabe

        AndroidHandoverData = [
      origin,             // "android:apk-key-hash:<base64SHA256_ofAppSigningCert>",
      nonce,           // nonce that was used to generate credential request,
      encryption_public_jwk_thumbprint,  // Encryption public key (JWK) Thumbprint
    ]

    AndroidHandoverDataBytes = hashlib.sha256(cbor2.dumps(AndroidHandoverData)).digest()

    Browserübergabe

        BrowserHandoverData =[
      origin,               // Origin URL
      nonce,               //  nonce that was used to generate credential request
      encryption_public_jwk_thumbprint,  // Encryption public key (JWK) Thumbprint
    ]

    BrowserHandoverDataBytes = hashlib.sha256(cbor2.dumps(BrowserHandoverData)).digest()

    Mit dem SessionTranscript muss die Gerätereaktion gemäß ISO/IEC 18013-5:2021, Abschnitt 9 validiert werden.

    Diese Validierung umfasst mehrere Schritte:

  2. Ausstellerzertifikat prüfen:Extrahieren Sie die Signaturzertifikatskette des Ausstellers aus issuerAuth und validieren Sie sie anhand der vertrauenswürdigen IACA-Root-Zertifikate. Weitere Informationen zu den unterstützten IACA-Zertifikaten des Ausstellers

  3. MSO-Signatur prüfen (18013-5, Abschnitt 9.1.2)

  4. ValueDigests für Datenelemente berechnen und prüfen (18013-5, Abschnitt 9.1.2)

  5. Signatur von deviceSignature überprüfen (18013-5, Abschnitt 9.1.3)

{
  "version": "1.0",
  "documents": [
    {
      "docType": "org.iso.18013.5.1.mDL",
      "issuerSigned": {
        "nameSpaces": {...}, // contains data elements
        "issuerAuth": [...]  // COSE_Sign1 w/ issuer PK, mso + sig
      },
      "deviceSigned": {
        "nameSpaces": 24(<< {} >>), // empty
        "deviceAuth": {
          "deviceSignature": [...] // COSE_Sign1 w/ device signature
        }
      }
    }
  ],
  "status": 0
}

Datenschutzfreundliche Altersüberprüfung (Zero-Knowledge Proof)

Wenn Sie Zero-Knowledge-Beweise unterstützen möchten (z.B. um zu überprüfen, ob ein Nutzer über 18 Jahre alt ist, ohne sein genaues Geburtsdatum zu sehen), ändern Sie das Anfrageformat in mso_mdoc_zk und geben Sie die erforderliche zk_system_type-Konfiguration an.

Eine allgemeine Übersicht über ZKP und die zugehörigen Funktionen finden Sie in den FAQs.

  ...
  "dcql_query": {
    "credentials": [{
      "id": "cred1",
      "format": "mso_mdoc_zk",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
        "zk_system_type": [
        {
          "system": "longfellow-libzk-v1",
          "circuit_hash": "f88a39e561ec0be02bb3dfe38fb609ad154e98decbbe632887d850fc612fea6f", // This will differ if you need more than 1 attribute.
          "num_attributes": 1, // number of attributes (in claims) this has can support
          "version": 5,
          "block_enc_hash": 4096,
          "block_enc_sig": 2945,
        }
        {
          "system": "longfellow-libzk-v1",
          "circuit_hash": "137e5a75ce72735a37c8a72da1a8a0a5df8d13365c2ae3d2c2bd6a0e7197c7c6", // This will differ if you need more than 1 attribute.
          "num_attributes": 1, // number of attributes (in claims) this has can support
          "version": 6,
          "block_enc_hash": 4096,
          "block_enc_sig": 2945,
        }
       ],
       "verifier_message": "challenge"
      },
     "claims": [{
         ...
      "client_metadata": {
        "jwks": {
          "keys": [ // sample request encryption key
            {
              ...

Sie erhalten einen verschlüsselten Zero-Knowledge-Beweis von der Wallet. Sie können diesen Nachweis anhand der IACA-Zertifikate von Ausstellern mit der longfellow-zk-Bibliothek von Google validieren.

Der verifier-service enthält einen einsatzbereiten, Docker-basierten Server, mit dem Sie die Antwort anhand bestimmter IACA-Zertifikate des Ausstellers validieren können.

Sie können die Datei certs.pem ändern, um IACA-Ausstellerzertifikate zu verwalten, denen Sie vertrauen möchten.

Ressourcen und Support