Przewodnik wprowadzający dla rejestratorów weryfikatorów

Przegląd

W tej sekcji opisujemy krok po kroku proces wdrażania usługi tożsamości Portfela Google dla rejestratorów weryfikujących.

Jako rejestrator weryfikujący (np. firma IDV, która weryfikuje tożsamość w imieniu innych podmiotów) pełnisz rolę własnego urzędu certyfikacji (CA), który podpisuje żądania tożsamości dla zarządzanych przez Ciebie podmiotów zależnych (End RPs).

Proces wdrażania

Krok 1. Prześlij formularz zgłoszeniowy i certyfikaty główne oraz zaakceptuj Warunki korzystania z usługi

Wypełnij i prześlij formularz zgłoszeniowy rejestratora weryfikującego. W tym formularzu podasz certyfikaty główne piaskownicy i środowiska produkcyjnego. Przesłanie tego formularza zgłoszeniowego oznacza również formalną akceptację Warunków korzystania z usługi Portfela Google dla rejestratorów weryfikujących.

Krok 2. Zaufanie i testowanie w piaskownicy

Gdy prześlesz formularz zgłoszeniowy, Google doda Twój certyfikat główny piaskownicy do magazynu zaufania piaskownicy Portfela Google i powiadomi Cię o tym. Następnie możesz rozpocząć testowanie integracji w piaskownicy za pomocą certyfikatów podpisanych przez Twój certyfikat główny piaskownicy.

Krok 3. Nagraj demonstrację wideo procesu kompleksowego

Gdy testowanie w piaskownicy zostanie zakończone, nagraj kompleksowe demonstracje wideo procesu weryfikacji dla pierwszego podmiotu zależnego i prześlij je do Google.

  • Wymagania dotyczące filmów:
    • Nagraj demonstracje zarówno dla procesów hostowanych przez weryfikującego (self-hosted), jak i hostowanych przez sprzedawcę (RP-hosted).
    • W filmach używaj rzeczywistych komponentów wyświetlanych sprzedawcy (nazwa, logo, adres URL Warunków korzystania z usługi) i komponentów wyświetlanych agregatora.
    • Wyraźnie pokaż interfejs użytkownika i ekrany, które uruchamiają proces weryfikacji.

Krok 4. Zatwierdzenie i zaufanie do certyfikatu głównego środowiska produkcyjnego

Gdy otrzymamy Twoje kompleksowe demonstracje wideo, Google rozpocznie proces sprawdzania i zatwierdzania filmu, a równocześnie proces zaufania do certyfikatu głównego środowiska produkcyjnego. Gdy oba procesy zostaną zakończone i zatwierdzone, możesz zacząć udostępniać usługę podmiotom zależnym.

Krok 5. Ciągłe wdrażanie podmiotów zależnych

W przypadku każdego podmiotu zależnego, w imieniu którego podpisujesz umowę, musisz:

  • Poinformować Google: użyj formularza zgłoszeniowego klienta rejestratora weryfikującego, aby powiadomić Google o nowym podmiocie zależnym i jego planowanym przypadku użycia.
  • Skonfigurować metadane: uzupełnij informacje wyświetlane podmiotu zależnego (nazwa, logo, adres URL Polityki prywatności) i ustaw unikalną globalnie nazwę wyróżniającą (podmiot) w jego certyfikacie.

Specyfikacja techniczna

A. Profil certyfikatu

Żądania muszą być podpisane standardowymi certyfikatami X.509 w wersji 3 wygenerowanymi za pomocą P-256 / ECDSA i zawierającymi niestandardowe rozszerzenie Google:

  • OID rozszerzenia niestandardowego: 1.3.6.1.4.1.11129.10.1
  • Krytyczność: niekrytyczne.
  • Treść: identyfikator SHA256 RelyingPartyMetadataBytes zakodowany w formacie ASN.1 OCTET STRING.

B. Schemat metadanych (CBOR)

Metadane muszą być zakodowane w formacie CBOR.

; 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
}

logo_uri musi być zgodny ze wskazówkami dotyczącymi marki Portfela Google.

C. Integracja OpenID4VP

Podczas formatowania podpisanego żądania danych logowania OpenID4VP umieść metadane zakodowane w formacie base64url w polu gw_rp_metadata_bytes w obiekcie client_metadata (jak pokazano w przykładowym kodzie żądania w następnej sekcji).

Zgodność ze standardami i odwoływanie

  • Monitorowanie nadużyć: Google monitoruje złośliwą aktywność podmiotów zależnych i powiadomi Cię o wykrytych nadużyciach.
  • Szybkie odwoływanie: musisz szybko odwołać certyfikaty podmiotów zależnych, które dopuszczają się nadużyć, i opublikować zaktualizowaną listę odwołanych certyfikatów (CRL).
  • Audyt: Google przechowuje anonimowe logi, aby mieć pewność, że żądania podmiotów zależnych są zgodne z zarejestrowanymi przypadkami użycia.

Dalsze kroki

Aby rozpocząć wdrażanie jako rejestrator weryfikujący, wypełnij i prześlij formularz zgłoszeniowy rejestratora weryfikującego. Aby wdrożyć kolejnych klientów zależnych, użyj formularza zgłoszeniowego klienta rejestratora weryfikującego.

Odpowiedzi na najczęstsze pytania dotyczące wdrażania i integracji znajdziesz w sekcji Najczęstsze pytania dotyczące tożsamości cyfrowej i danych logowania.

Szczegóły integracji rejestratora weryfikującego

W tej sekcji omówimy szczegóły integracji technicznej rejestratorów weryfikujących z interfejsem Digital Credentials API (w tym formatowanie żądań, szyfrowanie żądań, wywoływanie interfejsu API, sprawdzanie poprawności odpowiedzi i wdrażanie dowodów z wiedzą zerową).

Obsługiwane formaty i funkcje

Portfel Google obsługuje cyfrowe dokumenty tożsamości oparte na ISO mdoc.

Formatowanie żądania

Aby poprosić o dane logowania z dowolnego portfela, musisz sformatować żądanie za pomocą OpenID4VP. Możesz poprosić o konkretne dane logowania lub wiele danych logowania w jednym obiekcie dcql_query.

Przykład żądania JSON

Oto przykład żądania requestJson mdoc, które umożliwia uzyskanie danych logowania z dowolnego portfela na urządzeniu z Androidem lub w internecie.

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

Szyfrowanie żądania

client_metadata zawiera klucz publiczny szyfrowania dla każdego żądania. Musisz przechowywać klucze prywatne dla każdego żądania i używać ich do uwierzytelniania i autoryzowania tokena otrzymanego z aplikacji portfela.

Zintegrowane metadane OpenID4VP

Podczas formatowania żądania danych logowania musisz umieścić pole gw_rp_metadata_bytes w obiekcie client_metadata (jak pokazano w przykładowym kodzie żądania poniżej). To pole zawiera metadane podmiotu zależnego zakodowane w formacie Base64URL, które są wymagane przez Portfel Google do zweryfikowania Twojej tożsamości i wyświetlenia Twojej marki użytkownikowi.

Parametr credential_request w requestJson zawiera te pola.

Konkretny certyfikat

{
  "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": {
          "doctype_value": "org.iso.18013.5.1.mDL"  // this is for mDL. Use com.google.wallet.idcard.1 for ID pass
        },
        "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>"
  }
}

Dowolny kwalifikujący się certyfikat

Oto przykładowe żądanie zarówno mDL, jak i cyfrowego dokumentu tożsamości. Użytkownik może wybrać dowolne z nich.

{
  "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": "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_sets : [
      {
        "options": [
          [ "mdl-request" ],
          [ "id_pass-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>"
  }
}

Możesz poprosić o dowolną liczbę obsługiwanych atrybutów z dowolnych danych logowania przechowywanych w Portfelu Google.

Podpisane żądania

Podpisane żądania (żądania autoryzacji zabezpieczone za pomocą JWT) obejmują żądanie prezentacji weryfikowalnej wewnątrz tokena sieciowego JSON (JWT) podpisanego kryptograficznie przy użyciu infrastruktury PKI, co zapewnia integralność żądania i potwierdza Twoją tożsamość w Portfelu Google.

Wymagania wstępne

Zanim wprowadzisz zmiany w kodzie dotyczące podpisanego żądania, upewnij się, że masz:

  • Klucz prywatny: potrzebujesz klucza prywatnego (np. krzywej eliptycznej ES256) do podpisywania żądania, którym zarządzasz na serwerze.
  • Certyfikat: potrzebujesz standardowego certyfikatu X.509 pochodzącego z pary kluczy.
  • Rejestracja: upewnij się, że Twój certyfikat publiczny jest zarejestrowany w Portfelu Google.

Logika tworzenia żądania

Aby utworzyć żądanie, musisz użyć klucza prywatnego i opakować ładunek w JWS.

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

Wywoływanie interfejsu API

Całe żądanie do interfejsu API powinno być generowane po stronie serwera. W zależności od platformy wygenerowany kod JSON zostanie przekazany do interfejsów API platformy.

W aplikacji (Android)

Aby poprosić o dane logowania z aplikacji na Androida, wykonaj te czynności:

Aktualizowanie zależności

W pliku build.gradle projektu zaktualizuj zależności, aby używać Menedżera danych logowania (wersja beta):

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

Konfigurowanie Menedżera danych logowania

Aby skonfigurować i zainicjować obiekt CredentialManager, dodaj logikę podobną do tej:

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

Żądanie atrybutów tożsamości

Zamiast określać poszczególne parametry żądań tożsamości, aplikacja udostępnia je wszystkie razem jako ciąg JSON w CredentialOption. Menedżer danych logowania przekazuje ten ciąg JSON do dostępnych portfeli cyfrowych bez sprawdzania jego zawartości. Każdy portfel jest odpowiedzialny za: - analizowanie ciągu JSON w celu zrozumienia żądania tożsamości. - określanie, które z przechowywanych danych logowania (jeśli takie istnieją) spełniają żądanie.

Zalecamy partnerom tworzenie żądań na serwerze nawet w przypadku integracji z aplikacjami na Androida.

Użyjesz requestJson z formatu żądania jako request w wywołaniu funkcji GetDigitalCredentialOption().

// 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)
    }
}

Obsługa odpowiedzi dotyczącej danych logowania

Gdy otrzymasz odpowiedź z portfela, sprawdzisz, czy jest ona prawidłowa i czy zawiera odpowiedź credentialJson.

// 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}")
    }
}

Odpowiedź credentialJson zawiera zaszyfrowany identityToken (JWT) zdefiniowany przez W3C. Aplikacja Portfel jest odpowiedzialna za utworzenie tej odpowiedzi.

Przykład:

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

Przekażesz tę odpowiedź z powrotem na serwer, aby sprawdzić jej autentyczność. Kroki sprawdzania poprawności odpowiedzi dotyczącej danych logowania

Sieć

Aby poprosić o dane logowania za pomocą interfejsu Digital Credentials API w Chrome lub innych obsługiwanych przeglądarkach, wyślij to żądanie.

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

Wyślij odpowiedź z tego interfejsu API z powrotem na serwer, aby sprawdzić poprawność odpowiedzi dotyczącej danych logowania.

Sprawdzanie poprawności odpowiedzi

Gdy portfel zwróci zaszyfrowany identityToken (JWT), przed zaufaniem do danych musisz przeprowadzić dokładną weryfikację po stronie serwera.

Odszyfrowywanie odpowiedzi

Aby odszyfrować JWE, użyj klucza prywatnego odpowiadającego kluczowi publicznemu wysłanemu w client_metadata żądania. Spowoduje to wygenerowanie vp_token.

Przykład w Pythonie:

  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 spowoduje wygenerowanie kodu JSON vp_token zawierającego dane logowania 

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

  1. Utwórz transkrypcję sesji

    Następnym krokiem jest utworzenie SessionTranscript na podstawie normy ISO/IEC 18013-5:2021 ze strukturą przekazywania specyficzną dla Androida lub internetu:

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

    W przypadku przekazywania zarówno na Androida, jak i w internecie musisz użyć tego samego nonce, którego użyto do wygenerowania credential_request.

    Przekazywanie na Androida

        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()

    Przekazywanie w przeglądarce

        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()

    Za pomocą SessionTranscript należy sprawdzić poprawność odpowiedzi urządzenia zgodnie z klauzulą 9 normy ISO/IEC 18013-5:2021.

    Sprawdzanie poprawności obejmuje kilka kroków:

  2. Sprawdź certyfikat wystawcy: wyodrębnij łańcuch certyfikatów podpisywania wystawcy z issuerAuth i sprawdź jego poprawność na podstawie zaufanych certyfikatów głównych IACA. Zapoznaj się z obsługiwanymi certyfikatami IACA wystawcy.

  3. Sprawdź podpis MSO (sekcja 9.1.2 normy 18013-5)

  4. Oblicz i sprawdź ValueDigests dla elementów danych (sekcja 9.1.2 normy 18013-5)

  5. Sprawdź podpis deviceSignature (sekcja 9.1.3 normy 18013-5)

{
  "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
}

Weryfikacja wieku chroniąca prywatność (ZKP)

Aby obsługiwać dowody z wiedzą zerową (np. weryfikowanie, czy użytkownik ma ukończone 18 lat, bez sprawdzania dokładnej daty urodzenia), zmień format żądania na mso_mdoc_zk i podaj wymaganą konfigurację zk_system_type.

Ogólne informacje o tym, czym jest ZKP i jakie są jego możliwości, znajdziesz w sekcji Najczęstsze pytania.

  ...
  "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
            {
              ...

Z portfela otrzymasz zaszyfrowany dowód z wiedzą zerową. Możesz sprawdzić poprawność tego dowodu na podstawie certyfikatów IACA wystawców za pomocą biblioteki longfellow-zk Google.

Usługa weryfikacji zawiera gotowy do wdrożenia serwer oparty na Dockerze, który umożliwia sprawdzanie poprawności odpowiedzi na podstawie niektórych certyfikatów IACA wystawcy.

Możesz zmodyfikować plik certs.pem aby zarządzać certyfikatami wystawców IACA którym chcesz zaufać.

Zasoby i pomoc