---
url: 'https://www.corbado.com/tr/blog/dinamik-eslestirmede-biyometri-odeme-yapani-farkindaligi'
title: 'Dinamik Eşleştirmede Biyometri ve Ödeme Yapanın Farkındalığı'
description: 'PSD2 dinamik eşleştirme kapsamında biyometrik ödeme yapan farkındalığı: yerel biyometri + PKI ve passkey''lerin EBA/RTS rehberliği ve en iyi uygulamalarla uyumluluğu nasıl sağladığı.'
lang: 'tr'
author: 'Vincent Delitz'
date: '2025-10-02T15:13:44.273Z'
lastModified: '2026-03-27T07:08:51.540Z'
keywords: 'biyometri, ödeme yapan farkındalığı, dinamik eşleştirme'
category: 'Passkeys Strategy'
---

# Dinamik Eşleştirmede Biyometri ve Ödeme Yapanın Farkındalığı

## Yönetici Özeti: Dinamik Eşleştirmede Biyometri ve Ödeme Yapanın Farkındalığı

Corbado'nun yaklaşımı, [PSD2 RTS](https://www.corbado.com/faq/sca-rts-technical-standards) Madde 5'teki ("ne
görüyorsan onu imzalarsın") gerekliliğini karşılamak için oltalama saldırılarına dayanıklı
passkey'leri (SCA) banka kontrollü bir ekran ve sunucu tarafında dinamik eşleştirme ile
birleştirir.

- **Temel uygulama (bugün):** İşlem **tutarını ve alıcısını**, passkey kimlik
  doğrulamasından hemen önce ve sırasında Bison Bank kontrollü bir kullanıcı arayüzünde
  gösteriyoruz. Arka ucumuz, **standartlaştırılmış bir işlem anlık görüntüsüne (tutar,
  alıcı, txnId) bağlı** **tek seferlik bir challenge** oluşturur. Yanıt, yalnızca bu anlık
  görüntüyle eşleşirse kabul edilir; **herhangi bir değişiklik onu geçersiz kılar**.

- **Mevzuat açısından pozisyon:** Passkey'lerle bile uzaktan ödemeler için **dinamik
  eşleştirme zorunlu olmaya devam ediyor** (PSD2 Mad. 97(2); RTS Mad. 5). RTS, dinamik
  eşleştirme "[kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) kodunun" cihaz üzerinde
  hesaplanmasını **gerektirmez**; **ekran bütünlüğü**, **belirginlik** ve **değişiklik
  durumunda geçersiz kılma** zorunlu kılındığında sunucu tarafında oluşturma/doğrulama
  kabul edilebilir (ayrıca kodun nerede hesaplanabileceğine dair EBA Soru-Cevap
  2020_5366'ya bakınız).

- **Güvenlik ve denetlenebilirlik:** **Donanım tabanlı, oltalama saldırılarına dayanıklı**
  bir passkey imzasını belirli işlem verilerine bağlamak, **kurcalamayı ve aktarmayı
  önler** ve ödeme yapanın rızasına dair **güçlü, inkar edilemez kanıt** sunar.
  Desteklendiği durumlarda, arka uç modelini değiştirmeden **görüntülenen ayrıntıların
  kriptografik kanıtını** eklemek için isteğe bağlı olarak **Güvenli Ödeme Onayı'nı
  (SPC)** benimseyebiliriz.

> **Açıklama:** [Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir), kaynaklar
> arası oltalama saldırılarını ortadan kaldırır (sadece oluşturuldukları site/uygulamada
> çalışırlar). **Dinamik eşleştirme**, **bankanın tam olarak ödeme yapanın onayladığı
> şeyi** (tutar + alıcı) uygulamasını sağlar.

## 1. PSD2 SCA ve dinamik eşleştirme

- **SCA**: Farklı kategorilerden (bilgi/sahiplik/biyometrik özellik) iki bağımsız unsur,
  ifşa/kopyalamaya karşı uygun azaltma önlemleriyle korunur (RTS Mad. 6–8). Bağımsızlık
  gereklidir (Mad. 9), çok amaçlı cihazlarda yürütüldüğünde ayrım da buna dahildir (ör.
  işletim sistemi düzeyinde korumalar, güvenli donanım).
- **Dinamik eşleştirme (RTS Mad. 5)**:
    - (i) ödeme yapan, [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) sırasında
      tutar ve alıcıdan haberdar edilir
    - (ii) [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) kodu, o tutar/alıcıya
      özgüdür
    - (iii) herhangi bir değişiklik kodu geçersiz kılar
    - (iv) tutar, alıcı ve kodun gizliliği/bütünlüğü uçtan uca korunur. Bu, düzenlemenin
      “ne görüyorsan onu imzalarsın” amacını yerine getirir.
- **Sonuç**: Tek başına güçlü kullanıcı kimlik doğrulaması ödemeler için yeterli değildir.
  Onay, bağlayıcılığın ve ödeme yapana gösterimin denetlenebilir kanıtıyla birlikte
  belirli işlem verilerine bağlanmalıdır (RTS Mad. 5(1)(a–d)).

**Açıklama — oltalama ve yetkilendirme karşılaştırması:**
[Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) kaynağa bağlıdır, bu
nedenle sahte alan adları geçerli imzalar alamaz. Ancak [PSD2](https://www.corbado.com/blog/psd2-passkeys),
uzaktan ödemelerde _yetkilendirmeyi_ **tam tutar ve alıcıya** bağlamak, **herhangi bir
değişikliği geçersiz kılmak** ve ödeme yapana gösterilenin **bütünlüğünü korumak** için
hâlâ **dinamik eşleştirme** gerektirir (RTS Mad. 5(1)(a–d)). Dinamik eşleştirme, yalnızca
oltalama saldırılarını değil, yetkilendirme bütünlüğünü de (MITM/MITB/TPP değişimi dahil)
ele alır.

### 1.1 Teorik arka plan — yasal metin ve rehberlik

> [PSD2](https://www.corbado.com/blog/psd2-passkeys) Madde 97(2): “Elektronik ödeme işlemlerinin başlatılmasıyla
> ilgili olarak, Üye Devletler, ödeme yapanın, işlemi belirli bir tutara ve belirli bir
> alıcıya dinamik olarak bağlayan unsurları içeren güçlü müşteri kimlik doğrulama
> prosedürlerine erişimini sağlar.”
> [PSD2 Mad. 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> RTS Madde 5: “Ödeme hizmeti sağlayıcıları, oluşturulan kimlik doğrulama kodunun, işlemi
> başlatırken ödeme yapan tarafından kabul edilen ödeme işleminin tutarına ve alıcısına
> özgü olmasını; ödeme yapanın, kimlik doğrulamanın verildiği ödeme işleminin tutarından
> ve alıcıdan haberdar edilmesini; ödeme hizmeti sağlayıcısı tarafından kabul edilen
> kimlik doğrulama kodunun, işlemi başlatırken ödeme yapan tarafından kabul edilen ödeme
> işleminin orijinal tutarına ve alıcının kimliğine karşılık gelmesini; tutar veya
> alıcıdaki herhangi bir değişikliğin kimlik doğrulama kodunun geçersiz kılınmasıyla
> sonuçlanmasını; tutarın ve alıcının gizliliğinin, orijinalliğinin ve bütünlüğünün
> korunmasını sağlar.”
> [RTS Mad. 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

EBA 2019 Görüşü (EBA‑Op‑2019‑06), dinamik eşleştirmenin kimlik doğrulamayı tutara ve
alıcıya bağladığını, faktörlerin bağımsızlığını gerektirdiğini ve benzersiz cihaz bağlama
mevcut olduğunda cihaza bağlı kriptografik anahtarları sahiplik olarak kabul ettiğini
pekiştirir. Ayrıca kimlik doğrulama sırasında ödeme yapana gösterilenin bütünlüğünü de
vurgular. [EBA Görüşü 2019](https://www.eba.europa.eu)

### 1.2 Dinamik eşleştirmenin geçmişi

![dinamik eşleştirmenin geçmişi](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

[PSD2](https://www.corbado.com/blog/psd2-passkeys)'den önce birçok banka, genellikle onay adımıyla birlikte
tutarı veya alıcıyı göstermeyen SMS OTP'lerine veya basılı TAN listelerine güveniyordu. Bu
boşluk, kimlik bilgileri çalındıktan sonra müşterileri istenmeyen transferleri
yetkilendirmeye kandırmayı kolaylaştırıyordu. Dinamik eşleştirme, ödeme yapanın kimlik
doğrulama sırasında tam tutar ve alıcıdan haberdar edilmesini sağlayarak ve kimlik
doğrulama kodunu bu ayrıntılara özgü hale getirerek herhangi bir değişikliğin onu geçersiz
kılmasını sağlamak için (RTS Mad. 5(1)(a–d)) bu boşluğu kapatmak amacıyla getirildi. SMS
akışın bir parçası olduğunda, hizmet sağlayıcılar ayrıca kimlik doğrulamanın tüm
aşamalarında tutar/alıcı ve kodun gizliliğini, orijinalliğini ve bütünlüğünü sağlamalıdır
(Soru-Cevap 2018_4414; RTS Mad. 5(2)). Günümüzün uygulama içi onayları (örneğin, “John
Smith'e [Face ID](https://www.corbado.com/faq/is-face-id-passkey) ile 100 USD yetkilendirmek istiyor musunuz?”)
bu “ne görüyorsan onu imzalarsın” ilkesini müşteri dostu bir şekilde uygular.

### 1.3 Günümüzde dinamik eşleştirme: uygulama anlık bildirimleri ve yerel biyometri

![dinamik eşleştirme anlık bildirimi](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

Bugün mobil cihazlarda iki model öne çıkıyor. Birincisi, bir anlık bildirim, müşteriyi
işlem ayrıntılarını inceleyip onaylaması için uygulamaya derin bağlantı ile
yönlendirebilir. Denetleyiciler, Madde 7 kontrollerinin yetkisiz kullanımı azaltmak ve
kopyalamayı önlemek için mevcut olması ve genel sürecin RTS'ye uyması durumunda anlık
bildirimin sahiplik unsurunun kanıtı olarak hizmet edebileceğini açıklığa kavuşturmuştur;
yine de sosyal mühendislik riskleri devam etmektedir ve UX'te ele alınmalıdır (Soru-Cevap
2019_4984; RTS Mad. 7).

![dinamik eşleştirme yerel biyometri](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

İkincisi, cihazın yerel biyometrik özelliklerini (PIN ile yedeklenmiş) kullanan onaylar,
bir özel anahtar işleminin kilidini açmak için yerel olarak kullanıcı doğrulaması
gerçekleştirir. Özel anahtar, güvenli bir donanım ortamında (Secure Enclave/TEE/TPM)
bulunur ve bir challenge'ı imzalar. Bu, [SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys)'ya net bir
şekilde karşılık gelir: biyometrik özellik (biyometri) artı cihaz bağlama ve cihaza bağlı
bir kriptografik anahtarla kanıtlanan sahiplik (EBA‑Op‑2019‑06, para. 25, 35–37). Uzaktan
ödemeler için, kodun tutara ve alıcıya dinamik olarak bağlanması ve bu ayrıntıların
kullanıcı doğrulamasından önce ödeme yapana gösterilmesi gerekir (RTS Mad. 5). Her iki
faktör de tek bir cihazdaysa, birinin ele geçirilmesinin diğerini tehlikeye atmaması için
ayrı güvenli yürütme ortamları ve bütünlük kontrolleri uygulayın (RTS Mad. 9(2)–(3)).

### 1.4 Yerel biyometri ve PKI, dinamik eşleştirmeyi nasıl uygular?

İşin mutfağında, [yerel biyometri](https://www.corbado.com/tr/blog/passkeys-yerel-biyometri) doğrudan “bankaya
kimlik doğrulaması” yapmaz. Bunun yerine, biyometrik (veya PIN yedeği) cihazda kullanıcı
doğrulaması gerçekleştirir ve donanım destekli bir güvenlik modülünde saklanan dışa
aktarılamayan bir özel anahtara erişimi kontrol eder. Ödeme yapan onayladığında, cihaz bu
özel anahtarı kullanarak banka tarafından sağlanan bir challenge üzerinde dijital bir imza
oluşturur. Banka bu challenge'ı işlemin standart bir anlık görüntüsüyle (tutar, alıcı,
tanımlayıcılar) türetir veya ilişkilendirirse, sonuçtaki imza bu ayrıntılara özgü bir
kimlik doğrulama kodu işlevi görür. Herhangi bir değişiklik, saklanan anlık görüntü artık
eşleşmediği için veya gelişmiş tasarımlarda challenge türetimi değiştiği için kodu
geçersiz kılar. Ödeme yapanın farkındalığı kısmı bir UX gerekliliği olarak kalır:
kullanıcı doğrulamasından hemen önce banka kontrollü bir görünümde tutarı ve alıcıyı
gösterin. Bu, birlikte, RTS Madde 5'in farkındalık, özgünlük/benzersizlik ve değişiklik
durumunda geçersiz kılma gerekliliklerini karşılarken, Madde 7 kontrolleri ve cihaz
bağlama sahiplik unsurunu kanıtlar.

![biyometri dinamik eşleştirme](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Passkey'ler neden SCA uyumludur (cihaza bağlı ve senkronize)?

- **Sahiplik (cihaza bağlı ve senkronize anahtarlar)**: Passkey özel anahtarları güvenli
  donanımda (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM) saklanır. Cihaza bağlı
  [passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) dışa aktarılamaz, bu da
  EBA'nın benzersiz cihaz bağlama beklentileriyle uyumludur (EBA‑Op‑2019‑06, para. 25,
  35–37). Senkronize passkey'ler de, cihaz bağlama ve kopyalamayı önleyici kontroller
  etkili olduğu sürece her kimlik doğrulamada sahipliği kanıtlayabilir; düzenleyiciler
  unsur ile cihaz arasında güvenilir bir bağın gerekliliğini vurgulamıştır
  (EBA‑Op‑2019‑06; RTS Mad. 7).
- **Biyometrik özellik/Bilgi (Kullanıcı Doğrulaması)**: Biyometrik (biyometrik özellik)
  veya cihaz PIN'i (bilgi) aracılığıyla Kullanıcı Doğrulaması, anahtarı yerel olarak
  etkinleştirir. Sahiplikle birleştiğinde, bu faktör bağımsızlığı ile gerçek
  [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security)'dır. Birinin ihlali diğerini tehlikeye atmaz.

## 3. Passkey'ler dinamik eşleştirme gereksinimlerini karşılıyor mu?

Dinamik eşleştirme, **kimlik doğrulamayı işleme bağlamakla** ilgilidir. Bir banka için
soru şudur: bir kullanıcının bir ödemeyi (örneğin, bir OTP veya imzalama cihazı yerine)
bir passkey ile onaylamasına izin verirsek, bu onayın amaçlanan tutar ve alıcıya özgü
olduğunu ve yeniden kullanılamayacağını veya manipüle edilemeyeceğini garanti edebilir
miyiz?

Passkey'lerle dinamik eşleştirmeyi uygulamak için 2 seçenek vardır:

- **Sunucu tarafı eşleştirme (standart):** Arka ucun tam tutar ve alıcıyla
  ilişkilendirdiği tek seferlik bir WebAuthn challenge'ı oluşturun. Kullanıcı, banka
  kontrollü bir görünümde “Y'ye X€” görür ve bir passkey ile onaylar. Yanıt, yalnızca o
  işlem için kabul edilir. Herhangi bir değişiklik onu geçersiz kılar.
- **Kriptografik dahil etme (gelişmiş):** Tutar/alıcının bir hash'ini challenge'a gömün,
  böylece imza işlem verilerine taahhütte bulunur. Bu RTS tarafından gerekli değildir
  ancak arka uç değişikliklerinin bile doğrulamada başarısız olacağına dair güvence ekler.

**Açık uyumluluk notu:** RTS, dinamik eşleştirme “kimlik doğrulama kodunun” ödeme yapanın
cihazında hesaplanmasını **gerektirmez**. Bir ödeme hizmeti sağlayıcısı, **tutar/alıcı**
korunduğu ve **herhangi bir değişiklik** kodu geçersiz kıldığı sürece bunu **sunucuda**
oluşturabilir ve doğrulayabilir (kodun konumu/zamanlaması hakkında EBA Soru-Cevap
2020_5366'ya bakınız). Bu bizim **sunucu tarafı dinamik eşleştirme (standart)**
yaklaşımımızdır.

Her ikisi de işleme özgü, benzersiz, yeniden kullanılamaz bir “kimlik doğrulama kodu”
üretir. Birincil uyarı **ödeme yapanın farkındalığıdır**: WebAuthn'ın kendisi neyin
görüntülendiğini kanıtlamaz. Ekranın bütünlüğü banka kontrollü kullanıcı arayüzünden
gelmelidir.

### 3.1 Ödeme Yapanın Farkındalığı Hususu

RTS Madde 5, ödeme yapanın kimlik doğrulama sırasında tutarı ve alıcıyı görmesini
gerektirir. WebAuthn, neyin gösterildiğini [tasdik](https://www.corbado.com/tr/glossary/attestation) etmez.
Teoride, uygulama veya işletim sistemi ele geçirilirse, kimlik doğrulayıcı hâlâ imzalarken
bir kullanıcı yanıltılabilir. Bu riskin pratikte nasıl ortaya çıktığını ve neden gerçek
bir güvenlik riski olmadığını, daha çok bir düzenleme yorumu sorunu olduğunu aşağıda
ayrıntılı olarak analiz edeceğiz.

**Uyguladığımız ekran bütünlüğü kontrolleri:**

- Banka kontrollü görünüm **tutar + alıcıyı** gösterir: görünüm engellenirse veya odak
  dışındaysa passkey çağrısını **engelleriz**
- Uygulama/web'de **katman/kurcalama tespiti**: gizli
  [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)'lerden passkey istemi gelmez
- **Cihaz bütünlüğü/doğrulama denetimi**: root'lu/jailbreak'li/ele geçirilmiş sinyallerde
  reddetme veya ek güvenlik adımı uygulama
- Sunucuda tutulan **tutar/alıcı anlık görüntüsüne** karşı **atomik onay**: herhangi bir
  parametre değişikliğinde yeni bir challenge gereklidir

**Kriptografik dahil etme hakkında:** WebAuthn “işlem görüntüleme” uzantıları (SPC) bugün
**yaygın olarak desteklenmemektedir**. Taşınabilir temelimiz, imzanın bu değerlere
**taahhütte bulunması** için challenge'ı işlem anlık görüntüsünden (ör. H(tutar ‖ alıcı ‖
txnId ‖ nonce)) türeterek güçlendirilmiş **sunucu tarafı bağlamadır**.

### 3.2 Mevzuat açısından denklik: yerel biyometri ve PKI ile passkey'ler

Her iki model de dışa aktarılamayan cihaz anahtarlarıyla açık anahtar kriptografisi
kullanır ve her ikisi de imzalama işleminin kilidini açmak için yerel kullanıcı
doğrulamasına dayanır. Her ikisinde de banka, kullanıcı doğrulamasından hemen önce tutarı
ve alıcıyı banka kontrollü bir görünümde göstererek ödeme yapanın farkındalığını sağlar ve
kimlik doğrulama kodunu bu ayrıntılara bağlayarak özgünlüğü sağlar — herhangi bir
değişiklikte geçersiz kılar (RTS Mad. 5(1)(a–d)). RTS teknolojiden bağımsızdır ve
tutar/alıcının bir işletim sistemi biyometrik penceresi içinde gösterilmesini gerektirmez;
ödeme yapana gösterilmesini ve kodun bağlanmasını gerektirir (RTS Mad. 5). Her iki
[SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys) unsuru tek bir cihazda yürütüldüğünde, Madde 9'un
bütünlük ve ayırma gereklilikleri eşit şekilde uygulanır (RTS Mad. 9(2)–(3)). Son olarak,
dinamik eşleştirme hesaplamasının konumu esnektir: bütünlük korunursa ve herhangi bir
değişiklik kodu geçersiz kılarsa sunucu tarafında gerçekleştirilebilir (Soru-Cevap
2020_5366). Bunlar, düzenleyicilerin [yerel biyometri](https://www.corbado.com/tr/blog/passkeys-yerel-biyometri)
ve PKI'yi zaten kabul ettiği aynı koşullardır — bu nedenle, aynı ödeme yapan farkındalığı
ve bağlama kontrolleriyle uygulanan passkey'lerin eşdeğer bir temelde kabul edilmesi
gerekir.

### 3.3 Passkey'ler ve dinamik eşleştirmenin amacı

Peki, WebAuthn standardına göre basit passkey'ler dinamik eşleştirmenin _amacını yerine
getiriyor mu_? **Kısmen:**

- **MITM/ağ saldırıları:** Evet. Kaynak bağlama ve challenge başına imzalar kurcalamayı ve
  yeniden oynatmayı önler.
- **İşlem bütünlüğü:** Evet. Sunucu ilişkilendirmesi veya challenge hash'leme, yalnızca
  orijinal tutar/alıcının doğrulanmasını sağlar.
- **Ödeme yapanın rızası:** Daha zor. Passkey'lerde kimlik doğrulayıcı düzeyinde bir ekran
  yoktur. Ele geçirilmiş cihazlarda kullanıcı arayüzü aldatmacası mümkün olabilir. Ödeme
  yapanın rızasını garanti altına almak için üzerine bir şeyler inşa edilmelidir.

**Passkey'lerle dinamik eşleştirmeye neden hala ihtiyaç var?**

- **Yasal:** PSD2 Mad. 97(2) ve RTS Mad. 5, **tüm uzaktan ödeme başlatma işlemleri** için
  dinamik eşleştirmeyi zorunlu kılar. Oltalama saldırılarına dayanıklı yöntemler için bir
  istisna yoktur.
- **Güvenlik:** Passkey'ler **kaynaklar arası oltalama saldırılarını** ortadan kaldırır,
  ancak kendi başlarına ödeme yapana **neyin gösterildiğini kanıtlamazlar**. Dinamik
  eşleştirme + ekran bütünlüğü kontrolleri, kullanıcının gördüğü **belirli
  tutar/alıcının** bankanın uyguladığı şey olmasını ve **herhangi bir değişikliğin** onayı
  **geçersiz kılmasını** sağlar.

**Özetle, passkey'ler işlem verilerine sıkı sıkıya bağlandığında ve güvenilir görüntüleme
mekanizmalarıyla eşleştirildiğinde dinamik eşleştirmeyi karşılayabilir**. Geriye kalan
zorluk, kullanıcının gerçekte ne gördüğünü kanıtlamaktır.

## 4. Corbado, passkey'lerle dinamik eşleştirmeyi nasıl uygular?

Corbado, yukarıdaki ödeme yapanın rızasıyla ilgili hususları açıkça ele alan, dinamik
eşleştirmeyle uyumlu bir çözüm sunar.

### 4.1 Uçtan uca çözüm: akış, teknoloji, UX ve uyumluluk

// TODO KARUNA'DAN MOCKUP'LARI SAĞLA VE ONLARI AÇIKLA

Süreç akışı:

- **Banka kontrollü ekran**, ödeme yapana tam tutarı ve alıcıyı gösterir. Bu görünüm
  görünür olmadıkça hiçbir passkey istemi gösterilmez.
- **Kimlik doğrulama:** İstemci, standartlaştırılmış işlem için tek seferlik, bağlı bir
  challenge ile WebAuthn'ı çağırır. Kimlik doğrulayıcı, kullanıcı doğrulaması (biyometrik
  veya cihaz PIN'i) gerçekleştirir ve challenge ile kaynağı imzalar.
- **Sunucu doğrulaması:** Arka uç, RP ID hash'ini ve kaynağı doğrular, challenge'ı
  saklanan işlemle eşleştirir, UV/flag'leri kontrol eder, tek seferlik kullanımı ve
  süresinin dolmasını zorunlu kılar ve saklanan tutar/alıcı anlık görüntüsünü
  karşılaştırır.
- **Onay ve denetim:** Ancak o zaman işlem atomik olarak onaylanır. Herhangi bir
  uyuşmazlık/değişiklik reddedilir ve yeni bir kimlik doğrulaması gerektirir. Değişmez bir
  denetim kaydı saklanır (kimlik bilgisi ID'si, authenticatorData,
  [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), imza, challenge ve standartlaştırılmış
  tutar/alıcı), isteğe bağlı olarak kurcalama kanıtı için hash zincirine bağlanır.
- **Cihaz bütünlüğü denetimi:** Cihaz bütünlüğünü ve doğrulama sinyallerini değerlendirin:
  cihaz root'lu/jailbreak'li/ele geçirilmişse reddedin veya ek güvenlik adımı uygulayın.
- **Alıcı standardizasyonu:** Kolay anlaşılır bir etiket görüntüleyin (ör. “ACME GmbH”),
  ancak **standart bir alıcı tanımlayıcısına** (ör. IBAN/BIC veya başka bir benzersiz
  şema) karşı bağlayın ve doğrulayın.

Teknik detaylar:

- **Arka uç:** Standartlaştırılmış verilerle bir işlem nesnesi oluşturun (ör.
  normalleştirilmiş para birimi/ondalıklar; standartlaştırılmış IBAN/lehtar). Bu değerlere
  taahhütte bulunan kısa ömürlü bir challenge oluşturun (ör.
  H(tutar||alıcı||txnId||nonce)); beklemede olarak saklayın; istemciye yalnızca opak
  ID'ler sunun.
- **İstemci/kimlik doğrulayıcı:** Ödeme yapan ayrıntılarını banka kontrollü bir görünümde
  oluşturun; yalnızca görünür olduğunda WebAuthn'ı (RP ID = Bison alanı) çağırın;
  kullanıcı doğrulaması gerektirin; kimlik doğrulayıcı,
  [WebAuthn](https://www.w3.org/TR/webauthn-3/) uyarınca challenge + kaynağı imzalar.
- **Doğrulama/sonuçlandırma:** İmza, RP ID hash'i, kaynak/tür, UV flag'lerini doğrulayın;
  yeniden oynatma/süre sonu önlemleri; değişmez tutar/alıcı anlık görüntüsünü
  karşılaştırın; atomik olarak onaylayın; denetim kaydını saklayın.
- **Challenge'ı anlık görüntüden türetin:**:
  `challenge = H(tutar ‖ standartAlıcı ‖ txnId ‖ nonce)`

UX politikaları:

- Tutar/alıcıya net vurgu; erişilebilir onay/iptal kontrolleri; kısa zaman aşımları; her
  zaman yeni bir challenge kullanarak sorunsuz yeniden denemeler; anında makbuzlar (ör.
  “Y'ye X€ onayladınız”). Ekran engellenirse passkey istemini engelleyin ve imzalamadan
  önce parametreler değişirse uyarın.
- Katmanları/engellenmiş içeriği tespit edin: **işlem görünümü görünür değilse** asla bir
  passkey istemi göstermeyin. Akış ortasında parametreler değişirse reddedin ve **yeni bir
  challenge** ile yeniden başlatın.

**Uyumluluk notu:** Bu uçtan uca tasarım RTS Madde 5'i karşılar: **ödeme yapan
farkındalığı** (banka kontrollü ekran), **özgünlük** ve **benzersizlik** (tutar/alıcıya
bağlı tek seferlik kod), **değişiklik durumunda geçersiz kılma** (sıkı sunucu kontrolleri)
ve tüm aşamalarda tutar/alıcı ve kodun **gizliliği/bütünlüğü** (RTS Mad. 5(1)(a–d), 5(2);
SMS bütünlüğü için ayrıca Soru-Cevap 2018_4414'e bakınız). Faktör bağımsızlığı (Mad. 7–9),
uygun korumalara sahip çok amaçlı cihazlarda cihaza bağlı sahiplik ve yerel kullanıcı
doğrulaması yoluyla korunur (RTS Mad. 9(2)–(3)).

_Not:_\* Web akışları için Corbado, Apple'ın geniş destek sağlaması durumunda isteğe bağlı
olarak [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)'ı benimseyecek ve
tutar ile alıcıyı kriptografik olarak [tasdik](https://www.corbado.com/tr/glossary/attestation) eden güvenilir
bir tarayıcı aracılı ekran ekleyecektir.

## 5. Kalan riskler ve telafi edici kontroller

**Endişe: Oltalama saldırıları** **Yanıt:** Passkey'ler tasarımları gereği oltalama
saldırılarına dayanıklıdır: meşru kaynağa bağlıdırlar ve paylaşılan sırlar içermezler, bu
nedenle kimlik bilgileri OTP'lerin aksine sahte bir sitede toplanamaz. Trafiği benzer
görünümlü bir alan adına yönlendiren bir saldırgan, bankanın kaynağı için geçerli bir imza
alamaz. Dinamik eşleştirme bu vektörde daha az katkıda bulunur, ancak herhangi bir onayın
amaçlanan tutar ve alıcıya özgü olmasını sağlamak için zorunlu kalır. Tamamlayıcı önlemler
(oltalama eğitimi, giriş ve ödeme onaylarının net bir şekilde ayrılması, olağandışı ödeme
bağlamları için anomali/risk puanlaması) riski daha da azaltır.

**Endişe: Sosyal mühendislik / Yetkilendirilmiş Anlık Ödeme (APP) dolandırıcılığı**
**Yanıt:** Hiçbir kimlik doğrulayıcı, bir kullanıcının sahte bahanelerle (ör. “güvenli
hesap” dolandırıcılıkları) bir ödemeyi yetkilendirmesini tamamen engelleyemez. Dinamik
eşleştirme, kullanıcının alıcıyı ve tutarı açıkça görmesini sağlar ve rızanın güçlü
kanıtını sunar, ancak ikna edilmiş bir ödeme yapanı geçersiz kılamaz. Telafiler arasında
bağlamsal uyarılar (yeni alıcı, ilk büyük transfer), yüksek riskli alıcılar için bekleme
süreleri veya gecikmeli yürütme, daha güçlü alıcı doğrulaması ve risk sinyallerinde ek
güvenlik kontrolleri (ekstra onay) bulunur. Ödeme sonrası bildirimler ve hızlı itiraz
kanalları, zararın tespit edilmesine ve kontrol altına alınmasına yardımcı olur. Gerçek
zamanlı **bağlamsal uyarılar** (ör. yeni alıcı, ilk büyük transfer), yüksek riskli
alıcılar için **bekleme süreleri**, daha güçlü **alıcı doğrulaması** ve **ödeme sonrası
bildirimler** (“Y'ye X€ onayladınız”) ekleyerek tespiti ve müdahaleyi hızlandırıyoruz.

**Endişe: Kötü amaçlı yazılım veya cihazın ele geçirilmesi** **Yanıt:** Özel anahtarlar
**dışa aktarılamaz** ve her imza için **yerel kullanıcı doğrulaması** gerektirir, bu
nedenle kötü amaçlı yazılımlar kimlik bilgilerini kolayca sızdıramaz. Gerçekçi risk,
tamamen ele geçirilmiş bir işletim sisteminde **kullanıcı arayüzü aldatmacasıdır**.
Güvenli/doğrulanmış kullanıcı arayüzü (ör. korumalı onaylar), cihaz bütünlüğü
kontrolleri/doğrulama ve yüksek riskli cihazları engelleme ve
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) veya mevcut olduğunda bir onay uzantısı gibi
güvenilir onaylarla riski azaltın. Ele geçirme göstergeleri ortaya çıkarsa (katman
tespiti, root/jailbreak), bant dışı yeniden doğrulama kullanın veya yürütmeyi reddedin.
Tamamen ele geçirilmiş bir cihazda hiçbir tüketici yöntemi mükemmel değildir, ancak bu
kontroller pencereyi önemli ölçüde daraltır.

**Endişe: Tarayıcıdaki adam / oturum ele geçirme** **Yanıt:** Kötü amaçlı uzantılar veya
enjekte edilen komut dosyaları, meşru kaynakta eylemler başlatabilir. Kaynağa bağlı
passkey'ler siteler arası oltalama saldırılarını durdurur. **Dinamik eşleştirme**,
tutar/alıcıya yönelik perde arkası düzenlemelerinin **başarısız olmasını** sağlar. Kanalı
CSP/kurcalama önleyici kontrollerle ve her onay için **yeni, tek seferlik bir challenge**
gerektirerek güçlendiriyoruz.

**Endişe: İç tehdit veya sunucu tarafı kurcalama** **Yanıt:** Kimlik doğrulama yanıtı,
orijinal tutar/alıcıya benzersiz bir şekilde bağlıdır, bu nedenle herhangi bir sunucu
tarafı değişikliği doğrulamada başarısız olur. Denetim/inkar edilemezlik için kurcalamaya
dayanıklı, değişmez bağlantı kayıtlarını (challenge, kimlik bilgisi, imza ve
standartlaştırılmış tutar/alıcı) koruyun. İç riski azaltmak için kritik ödeme işleme
yollarında görevlerin ayrılması ve dört göz kontrollerini uygulayın.

**Endişe: Çalınan cihazlar / kimlik bilgisi hırsızlığı** **Yanıt:** Sadece cihaza sahip
olmak yeterli değildir: her imza için kullanıcı doğrulaması (biyometrik/PIN) gereklidir,
işletim sistemi düzeyinde hız sınırlamaları ve kilitlemelerle birlikte. Her ödeme, yeni,
işleme özgü bir challenge gerektirir; genel oturum belirteçleri rastgele ödemeleri
yetkilendiremez. Uzaktan cihaz iptali, yeni cihaz kullanımında ek güvenlik adımı, coğrafi
hız kontrolleri ve bildirimler (“Y'ye X€ yetkilendirdiniz”) gibi eklemeler kötüye
kullanımı daha da kısıtlar.

Genel olarak: passkey'ler oltalama ve yeniden oynatma risklerini önemli ölçüde azaltır;
dinamik eşleştirme, işlem bütünlüğünü garanti etmek, onayları tutar/alıcıya bağlamak ve
kalan tehdit senaryolarında bilgili rızanın güçlü kanıtını sağlamak için temel olmaya
devam eder.

## 6. Uyumluluk SSS

**Soru 1:** Bir passkey kullanırken kullanıcının tutarı ve alıcıyı gerçekten görüp
onayladığını nasıl kanıtlayabiliriz? **Yanıt:** **Ödeme yapanın gösterimini** banka
kontrollü bir görünümde zorunlu kılıyoruz ve onayı tutar/alıcının **sunucu tarafı anlık
görüntüsüne** bağlıyoruz. Passkey onayı (authenticatorData,
[clientDataJSON](https://www.corbado.com/glossary/clientdatajson), imza), **yalnızca** o anlık görüntüden
türetilen challenge için kabul edilir; **herhangi bir değişiklik** yeni bir challenge
gerektirir. **Kurcalamaya dayanıklı denetimimiz**, onayı “Payee-ID Y'ye X€” ile
ilişkilendirir ve sistemimizin ayrıntılar farklı olsaydı devam etmeyeceğini kaydeder.
Desteklendiği durumlarda, **SPC**, kullanıcının görüntülenen ayrıntıları onayladığına dair
**kriptografik kanıt** ekler.

**Soru 1:** Bir passkey kullanırken kullanıcının tutarı ve alıcıyı gerçekten görüp
onayladığını nasıl kanıtlayabiliriz? **Yanıt:** Bu esasen **inkar edilemezlik** sorusudur.
PSD2 kapsamında, dinamik eşleştirme kullanıcının neyi onayladığının farkında olmasını
sağlamak için tasarlanmıştır. Bir passkey ile elimizde tuttuğumuz kanıt, kriptografik imza
(kimlik doğrulama kodu) ve ilgili verilerdir (sunucumuzda hangi tutar/alıcıya bağlı
olduğu). Politika gereği, işlem ayrıntılarını kullanıcıya kimlik doğrulamadan önce
uygulama veya web sayfasında gösteririz. O ekranı/görünümü ve o belirli işlem için sonraki
başarılı passkey kimlik doğrulamasını günlüğe kaydederiz. Bir anlaşmazlık durumunda,
kullanıcının cihazının (örneğin) “ACME Corp.'a 100€” ile ilişkilendirilmiş bir challenge
için geçerli bir imza ürettiğini ve herhangi bir ayrıntı farklı olsaydı sistemimizin devam
etmeyeceğini gösterebiliriz. Uyumluluğumuz güvenli günlük kaydına dayanır: sistemlerimizin
passkey yanıtını işlem verilerine bağlarken kurcalamaya karşı korumalı olduğundan emin
oluruz.

**Soru 2:** Cihaz veya işletim sistemi ele geçirilirse ne olur?
[Kötü amaçlı yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim) işlemi veya passkey sürecini
manipüle edebilir mi? **Yanıt:** Cihazın ele geçirilmesi, herhangi bir dijital bankacılık
senaryosunda kritik bir tehdittir. İşletim sistemi kötü niyetliyse, kullanıcıyı yanıltmaya
veya süreçleri ele geçirmeye çalışabilir. Ancak, bu en kötü durumda bile, **passkey'ler
bazı temel korumaları sürdürür**. Özel anahtar kötü amaçlı yazılımlar tarafından
çıkarılamaz. [Kötü amaçlı yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim), kullanıcının
biyometrik/PIN'i olmadan passkey imzasını üretemeyeceği için bankaya karşı kullanıcıyı
taklit edemez. Yapabileceği en fazla şey, kullanıcıyı sahte bahanelerle bir şeyi
doğrulamaya itmektir. Dinamik eşleştirme burada bütünlük kontrolleri gerektirerek yardımcı
olur: [kötü amaçlı yazılım](https://www.corbado.com/tr/glossary/kotu-amacli-yazilim), işlem ayrıntılarını
sonradan sessizce değiştiremez – yaparsa, imza doğrulanmaz. En zayıf nokta
**ekran/kullanıcı arayüzüdür**: gelişmiş bir Truva atı, kullanıcının gördüğünü
değiştirebilir (ör. temeldeki işlem başka bir alıcıya giderken “ACME Corp” görüntülemek).
Bu, özellikle banka uygulaması güvenli kullanıcı arayüzü çerçeveleri kullanıyorsa, önemsiz
bir iş değildir, ancak düşünülebilir. Tüm bunlara rağmen, cihazın ele geçirildiğine dair
işaretler tespit edersek (olağandışı davranış, bilinen kötü amaçlı yazılım imzaları vb.),
bant dışı doğrulamaya geri döner veya işlemi reddederiz. **Özetle:** Kullanıcının cihazı
bir saldırgan tarafından tamamen ele geçirilmişse hiçbir çözüm %100 değildir.
Passkey'ler + dinamik eşleştirme, saldırı yüzeyini önemli ölçüde azaltır (bir saldırgan
sadece kimlik bilgilerini proxy yapamaz veya ağ verilerini değiştiremez; kullanıcı
üzerinde gerçek zamanlı bir oyun oynamak zorunda kalır). İşletim sistemi ele geçirilirse,
dinamik eşleştirme en azından olması gereken ile onaylanan arasındaki herhangi bir
uyuşmazlığın arka ucumuz tarafından yakalanmasını sağlar.

**Soru 3:** Passkey'in kilidini açmak için bir biyometrik kullanılırsa, bu tek faktör mü
yoksa iki faktör mü sayılır? 2 faktör kuralına uyuyor muyuz? **Yanıt:** Tek başına bir
biyometrik, [SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys) için yeterli **değildir** – sadece bir
biyometrik özellik faktörüdür. Ancak, bir passkey uygulamasında biyometrik _tek başına
değildir_: cihazın sahipliği diğer faktördür. Kullanıcının biyometrisi, _cihazda saklanan_
özel anahtarın kilidini açar. Sahiplik ve biyometrik özellik iki farklı kategoridir. Bu,
birçok bankacılık uygulamasının SCA'yı nasıl karşıladığına benzer: telefona sahipsiniz
(sahiplik) _ve_ uygulamanın kilidini açmak için parmak izinizi veya yüzünüzü kullanırsınız
(biyometrik özellik). EBA, cihaz bağlama artı biyometrik kombinasyonlarını uyumlu SCA
olarak açıkça tanımıştır. Passkey senaryosu tam olarak bu kombinasyondur. Kullanıcı
passkey'in kilidini açmak için biyometrik yerine bir PIN kullanmayı seçerse, o zaman bu
sahiplik + bilgidir, bu da uyumludur. Tüm passkey işlemlerinde kullanıcı doğrulaması
zorunlu kılıyoruz (yani kullanıcının her seferinde biyometrik/PIN sağlaması gerekir), bu
nedenle sadece cihaza sahip olmanın yeterli olduğu bir durum yoktur. Dolayısıyla, passkey
aracılığıyla her ödeme yetkilendirmesi, PSD2 tanımları kapsamında _iki faktörlü_ bir
olaydır.

**Soru 4:** Bir saldırgan bir passkey kimlik doğrulamasını yeniden kullanabilir veya
verileri taşıma sırasında manipüle ederek dinamik eşleştirmeyi bir şekilde atlatabilir mi?
**Yanıt:** Hayır. Passkey'ler ve dinamik eşleştirmenin birlikte güçlü bir şekilde
çalıştığı yer burasıdır. Her WebAuthn kimlik doğrulaması, (her işlem için oluşturduğumuz)
challenge'a bağlı olan ve alan adımızla sınırlı olan **benzersiz bir imza** üretir. Bir
saldırgan bu imzayı farklı bir işlem için yeniden oynatamaz. İmzanın kendisi challenge
nonce'unu içerir ve yalnızca orijinal olarak verildiği şey için geçerlidir. Bir saldırgan
ağ iletişimini ele geçirseydi, imzayı geçersiz kılmadan tutarı veya alıcıyı değiştiremezdi
(çünkü challenge veya işlem bağlamı artık eşleşmezdi). Bu, tartıştığımız MITM korumasıdır.
Ayrıca, passkey imzaları kaynak verilerini içerir – tam web sitemiz/uygulama kaynağımıza
gönderilmezlerse doğrulanmazlar, bu nedenle oltalama veya yönlendirme işe yaramaz.
Kısacası, herhangi bir manipülasyon girişimi, dinamik eşleştirme kurallarına göre kimlik
doğrulama kodunu geçersiz kılar. Bu aslında, kullanıcıların bazen genel bir kodu
onayladığı ve isteğin kurcalanmış olma riskinin bulunduğu bazı mevcut OTP tabanlı
akışlardan daha güvenlidir. Passkey'lerle, kullanıcı kimlik doğrulamasını belirli bir
oturuma/işleme kriptografik olarak bağlarız.

**Soru 5:** SCA için WebAuthn/passkey'ler hakkında bilinen herhangi bir düzenleyici görüş
var mı? Düzenleyicilerin passkey'leri uyumlu olarak kabul edeceğinden emin miyiz?
**Yanıt:** Şu an itibariyle, EBA Soru-Cevap veya rehberliğinde WebAuthn veya “passkey'ler”
terimi hakkında açıkça görüş yayınlamamıştır. Ancak, ortaya koydukları ilkelere dayanarak,
passkey'ler kabul edilebilir yöntemler arasına açıkça girmektedir. EBA'nın 2019 görüşü
esasen [FIDO2](https://www.corbado.com/glossary/fido2) benzeri yaklaşımları öngörmüştür: sahiplik için,
**sahiplik kanıtı olarak uygun cihaz bağlama ile “açık/özel anahtar alışverişini”** açıkça
belirtmişlerdir. Bir WebAuthn passkey'i tam olarak budur – özel yarısı cihaza güvenli bir
şekilde bağlı olan bir açık/özel anahtar çifti. Ayrıca “bir cihaz tarafından oluşturulan
imza”ya geçerli bir sahiplik kanıtı olarak onay vermişlerdir. Dolayısıyla, passkey
terimini kullanmasalar da, yöntem örnekleriyle kapsanmaktadır. Ayrıca, Avrupa'daki büyük
ödeme oyuncularının passkey uygulamalarına (ör. [PayPal](https://www.corbado.com/blog/paypal-passkeys))
yöneldiğini gözlemledik, bu da bunun [PSD2 uyumlu](https://www.corbado.com/tr/blog/psd2-ve-passkeys) olduğuna
dair bir güven seviyesi olduğunu göstermektedir. Bu örnek, dinamik eşleştirme ve genel
gereklilikler karşılandığı sürece passkey'lerin uyumlu SCA akışlarının bir parçası olarak
kabul edildiğini göstermektedir.

**Soru 6:** Passkey'ler
[oltalama saldırılarına dayanıklı](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir)ysa
dinamik eşleştirmeye hâlâ ihtiyaç var mı? **Yanıt:** Evet. Passkey'ler **kaynaklar arası
oltalama saldırılarını** ortadan kaldırır, ancak PSD2 uzaktan ödeme başlatma için hâlâ
**dinamik eşleştirme** zorunlu kılar. Dinamik eşleştirme, **belirli tutarı ve alıcıyı**
SCA sonucuna bağlar ve **herhangi bir değişikliği geçersiz kılar**, bu da oltalama
dışındaki yetkilendirme bütünlüğünü (ör. MITM/MITB/TPP değişimi) ele alır.

## 7. Sonuç: dinamik eşleştirme uyumluluğu ve iyileştirilmiş sonuçlar

Corbado'nun çözümü Dinamik Eşleştirme ve PSD2 uyumludur. Kimlik doğrulama öncesi ödeme
yapan ekranı, tutar ve alıcıya bağlı tek seferlik challenge, sıkı sunucu doğrulaması ve
değişmez denetim, RTS Madde 5'in ödeme yapan farkındalığı, benzersizlik/özgünlük,
değişiklik durumunda geçersiz kılma ve bütünlük/gizlilik gerekliliklerini birlikte
karşılar. Faktör bağımsızlığı, EBA rehberliğiyle uyumlu olarak cihaza bağlı sahiplik ve UV
(biyometrik veya PIN) aracılığıyla korunur.

Günümüzün OTP/SMS yöntemlerine kıyasla Corbado, oltalama ve aktarmaya karşı direnç, sessiz
parametre kurcalamasının önlenmesi, daha güçlü inkar edilemez kanıt ve cihaz içi UV
aracılığıyla azaltılmış sürtünme gibi önemli ölçüde daha iyi güvenlik ve kullanıcı
sonuçları sunar. Kalan riskler (ör. sosyal mühendislik, ele geçirilmiş cihazlar) somut
kontrollerle azaltılır ve eski yöntemlere göre daha dardır. Web için Corbado, platform
desteği (özellikle Apple) geniş olduğunda [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)'yi
benimseyebilir ve temel uyumluluk duruşunu değiştirmeden ekranın kriptografik kanıtını
ekleyebilir.

Kısacası, Corbado'nun passkey tabanlı işlem yetkilendirmesi, PSD2 dinamik eşleştirmenin
lafzına ve ruhuna uyar ve eski yaklaşımlara kıyasla dolandırıcılığa karşı dayanıklılığı ve
denetlenebilirliği artırırken, ekosistem olgunlaştıkça gelecekteki geliştirmelere (SPC)
açık bir yol sunar.

Pratikte, passkey'ler üç şeyi yaptığımızda dinamik eşleştirmeyi karşılar: kullanıcı
doğrulamasından önce tutarı ve alıcıyı ödeme yapana gösteririz; bu kesin ayrıntılara özgü
bir kimlik doğrulama kodu oluştururuz; ve herhangi bir değişiklikte kodu geçersiz kılarız
(RTS Mad. 5(1)(a–d)). Bu, düzenleyicilerin
[yerel biyometri](https://www.corbado.com/tr/blog/passkeys-yerel-biyometri) için zaten kabul ettiği ilkeleri
yansıtır, ek olarak passkey'lerin işletim sistemi yerel olması ve ek bir uygulama olmadan
web ve uygulama kanallarında çalışması rahatlığıyla birlikte. Kaynak bağlama ile
birleştirildiğinde, sahte istekleri yüzeye çıkarmazlar — yalnızca orijinal siteden veya
uygulamadan gelen meşru istemler kullanıcıya görünür.