Passkey'ler ile Dinamik Bağlama: Güvenli Ödeme Onayı (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

Dört bölümden oluşan kapsamlı serimizde (bölüm 1, bölüm 2, bölüm 3 ve bölüm 4) PSD2 üzerine, passkey'lerin PSD2 ile sunulan Güçlü Müşteri Kimlik Doğrulaması (SCA) önlemlerine nasıl entegre olduğunu inceledik. Özellikle SCA'nın bankacılık uygulamalarına erişim için gerektirdiği kimlik doğrulama unsurlarına odaklandık. SCA gereklilikleri sadece uygulamalara erişim için değil, aynı zamanda elektronik ödeme işlemlerini uzaktan başlatmak ve imzalamak için de geçerlidir. Dahası, bu gereklilikler dinamik bağlama olarak bilinen bir mekanizmanın kullanılmasını zorunlu kılar. Bu makalede, dinamik bağlamanın ne olduğunu açıklayacak ve passkey'lerin bu mekanizmayı hem bugün hem de gelecekte etkili bir şekilde uygulamak için nasıl kullanılabileceğini inceleyeceğiz.

Dinamik bağlama, PSD2 direktifi ve onun uygulama eki olan Düzenleyici Teknik Standartlar (RTS) kapsamında bir güvenlik gerekliliğidir. Bu konsept, her işlemin bir kimlik doğrulama kodu aracılığıyla belirli bir tutara ve belirli bir alıcıya benzersiz bir şekilde bağlanmasını sağlayarak elektronik ödemelerin güvenliğini artırmak için tanıtılmıştır. Bu bağlama, ödeme yapan tarafından doğrulandıktan sonra işlem detaylarının herhangi bir şekilde değiştirilmesini önler ve böylece dolandırıcılık riskini azaltır. Elektronik ödemeler, çevrimiçi bankacılık yazılımlarındaki banka havalelerini ve satıcı sitelerindeki kredi kartı ödemelerini içerir.

PSD2 Direktifi ve beraberindeki RTS'ye göre, dinamik bağlama "oluşturulan kimlik doğrulama kodunun, elektronik ödeme işlemi başlatılırken ödeme yapan tarafından kabul edilen tutara ve alıcıya özgü olmasını" sağlayan bir süreç olarak tanımlanır (PSD2 Madde 97(2)). Bu, ödeme detaylarındaki herhangi bir değişikliğin kimlik doğrulama kodunu geçersiz kılacağı ve yeniden kimlik doğrulama gerektireceği anlamına gelir.

Dinamik bağlama, özellikle ortadaki adam (man-in-the-middle) saldırıları gibi farklı dolandırıcılık türlerine karşı savunmasız olan uzaktan elektronik işlemlerle ilişkili güvenlik risklerini doğrudan ele aldığı için PSD2'de kritik bir öneme sahiptir.

İşlemi bu şekilde güvence altına alarak, dinamik bağlama yetkisiz işlem olasılığını önemli ölçüde düşürür.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

RTS Madde 5, dinamik bağlamadaki kimlik doğrulama kodu için gereklilikleri genişletir. Bu gereklilikler şunları içerir:

• Ödeme yapanın farkındalığı: Ödeme yapan, ödeme işleminin tutarı ve alıcısı hakkında bilgilendirilir.

• Kimlik doğrulama kodu benzersizdir: Her işlem için oluşturulan kimlik doğrulama kodu benzersiz olmalı ve başka hiçbir işlem için yeniden kullanılamamalıdır.

• Kimlik doğrulama kodu özeldir: Oluşturulan ve kabul edilen kodlar, ödeme yapan tarafından onaylandığı şekliyle işlem tutarına ve alıcının kimliğine özgü olmalıdır. Tutar veya alıcıdaki herhangi bir değişiklik, kimlik doğrulama kodunun geçersiz olmasına neden olur.

• Güvenli iletim: Kimlik doğrulama kodunun oluşturulması, iletilmesi ve kullanılması da dahil olmak üzere kimlik doğrulamanın tüm aşamalarında işlem tutarı ve alıcı için gizlilik, özgünlük ve bütünlük korunur.

Dinamik bağlamanın bu teknik gerekliliklerini ortaya koyduktan sonra, bir sonraki bölümde passkey'lerin yeni bir teknoloji olarak nasıl yardımcı olabileceğini göreceğiz. Ödeme kimlik doğrulama süreçlerini kolaylaştırma ve güvence altına alma potansiyellerini keşfedeceğiz, böylece dinamik bağlamayı sadece daha sağlam değil, aynı zamanda daha kullanıcı dostu hale getireceğiz.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Kurumsal şirketler, kullanıcılarını korumak ve passkey'ler ile girişleri daha sorunsuz hale getirmek için Corbado'ya güveniyor. Ücretsiz passkey danışmanlığınızı şimdi alın.

Ücretsiz danışmanlık alın

Öncelikle passkey'lerin dinamik bağlamada nasıl kullanılabileceğine dair farklı seçenekleri analiz edelim.

Bu yaklaşımda, passkey'in kendisi doğrudan kimlik doğrulama kodu olarak kullanılan kriptografik bir assertion görevi görür. İşlem sürecinde verilen challenge, tutar ve alıcı gibi belirli işlem ayrıntılarını yansıtacak şekilde özel olarak oluşturulur ve bu bilgilerle birlikte saklanır. Kullanıcı, passkey'ini kullanarak işlemi onayladığında, doğrulanabilen ve işlemle birlikte saklanabilen benzersiz, kriptografik olarak güvenli bir imza oluşturulur. Bu yanıt, yalnızca sağlam bir kimlik doğrulama faktörü olarak hizmet etmekle kalmaz, aynı zamanda onayı belirli işlem ayrıntılarına doğrudan bağlayarak PSD2'nin dinamik bağlama gerekliliklerine sıkı sıkıya uyar.

Become part of our Passkeys Community for updates & support.

Join

Daha gelişmiş bir entegrasyon, WebAuthn challenge'ının kendisine ek işlem ayrıntılarının kodlanmasını içerir (teknik olarak PSD2/RTS tarafından zorunlu tutulmasa da). Bu yöntem, alıcının ve tutarın kriptografik bir özetini (hash), diğer rastgele verilerle birlikte challenge'a dahil etmeyi önerir. Bunu yaparak, kimlik doğrulama süreci yalnızca passkey aracılığıyla kullanıcının kimliğini doğrulamakla kalmaz, aynı zamanda işlem ayrıntılarının bütünlüğünü de kriptografik olarak kanıtlar. Bu yaklaşım, tutar veya alıcı ayrıntılarında yapılacak herhangi bir oynamanın son ödeme noktasında tespit edilebilir olmasını sağlayarak ek bir güvenlik katmanı sunar. Kriptografik kanıt, kimlik doğrulama kodunun değişmez bir parçası haline gelir ve yüksek riskli işlem ortamlarında güveni ve güvenliği artırır (daha fazla bilgi burada).

Bu iki seçeneğin sınırlamalarını ve zorluklarını analiz edelim.

Passkey'leri dinamik bağlama bağlamında, özellikle ödeme kimlik doğrulaması için kullanmanın sınırlamalarından biri, ödeme yapanın alıcı bilgileri hakkında doğru bir şekilde bilgilendirildiğine dair somut bir belgelendirme veya güvence eksikliğidir.

Passkey'ler kullanıcı kimlik doğrulaması için güvenli bir yöntem sağlarken, özellikle alıcıyla ilgili olanlar olmak üzere tüm işlem ayrıntılarının ödeme yapana doğru bir şekilde gösterilip gösterilmediğini doğası gereği doğrulamazlar.

Bu sorun sadece passkey'lere özgü değildir; çeşitli çevrimiçi ödeme sistemlerinde ortak bir zorluktur. Ödeme yapanın, ödemeyi başlatmadan önce tüm işlem ayrıntılarının tam olarak farkında olmasını ve bunlara rıza göstermesini sağlamak, güveni ve güvenliği sürdürmek için çok önemlidir.

Passkey'leri dinamik bağlamaya entegre etmenin en önemli sınırlaması, birinci taraf ve üçüncü taraf kaydı arasındaki ayrımda ortaya çıkar.

Birinci Taraf Ödeme Bağlamı Nedir?

✔️ Birinci Taraf ödeme bağlamında, kullanıcı doğrudan ihraççı / banka ile kendi internet hizmeti ve alan adı üzerinden etkileşim halindedir. Passkey'ler sorunsuz bir şekilde kaydedilebilir ve doğrulanabilir. Örnek olarak, kendi web sitesinde bir passkey kaydeden ve bunu çevrimiçi bankacılık yazılımından bir ödeme başlatmayı yetkilendirmek için kullanan bir banka verilebilir. Burada passkey'ler sorunsuz çalışır. Banka, passkey'in kendi alan adı içinde kullanılmasını sağlayarak ödeme ortamı ve işlemin güvenliği üzerinde kontrolü elinde tutar.

Birinci taraf ödeme bağlamında Mastercard'ın passkey uygulaması için blog yazımıza göz atabilirsiniz.

Üçüncü Taraf Ödeme Bağlamı Nedir?

Üçüncü Taraf ödeme bağlamında, kullanıcı farklı bir alan adındaki (ör. amazon.com) bir satıcı sayfasında ödeme sürecindedir ve bir kredi kartı işlemi başlatmak istemektedir:

• ✔️ Durum 1 – Kullanıcının ihraççısından / bankasından zaten bir passkey'i var: Satıcı, passkey ile kimlik doğrulamanın gerçekleşebileceği bir iframe gösterir. IFRAME, SCA ve dinamik bağlamayı desteklemesi gereken kredi kartı işlemleri için zaten mevcut olan altta yatan 3-D Secure 2 (3DSS/EMV 3DS) süreci tarafından gösterilir.

• ❌ Durum 2 – Kullanıcının ihraççısından / bankasından bir passkey'i yok: Yine, satıcı iframe gösterir. Henüz passkey mevcut olmadığından, kullanıcı mevcut kimlik doğrulama faktörleriyle (ör. SMS OTP veya akıllı telefonlarındaki yerel bankacılık uygulaması) doğrulanır. Bu noktada, başarılı bir kimlik doğrulamasından sonra, kullanıcı için bir passkey kaydetmek ideal bir an olurdu, ancak bu, WebAuthn standart kısıtlamaları nedeniyle izin verilmez. Cross-origin bir iframe'de passkey kaydına izin verilmez (ana sayfanın ve iframe'in alan adının aynı olması gerekir). Aşağıdaki ekran görüntüsündeki gibi aşamalı bir kayıt imkansız olurdu:

Gelecekte cross-origin iframe'lerde passkey kaydı desteklenecek mi?

Passkey'ler tek bir alan adı içindeki birinci taraf ödeme bağlamında dinamik bağlama için iyi bir çözüm sunarken, üçüncü taraf ödeme bağlamlarında şu anda WebAuthn Level 2 tarafından desteklenmemektedir. Ancak iyi haber şu ki, cross-origin iframe desteği, devam eden WebAuthn Level 3 spesifikasyonuna (2024 sonuna kadar genel kullanıma sunulacak) zaten dahil edilmiştir. Ancak, tarayıcıların spesifikasyona yetişmesi hala gerekmektedir:

Bugün itibarıyla, 2024 yılına kadar büyük tarayıcılarda passkey'lerin cross-origin kaydı için kapsama alanının bir gerçeklik haline gelebileceği görülüyor, bu da passkey'leri ödemeler için kullanmadaki en önemli teknik sınırlamayı ortadan kaldıracaktır.

Google tarafından başlatılan W3C çalışma grupları tarafından web'deki ödeme deneyimini iyileştirmek için (ör. BasicCard, PaymentHandler veya PaymentManifest) birkaç girişimde bulunulmuştur. Şimdiye kadar hiçbiri önemli bir pazar kapsamı ve kullanımı elde edemedi. E-ticaret işlemleri için ödeme sürecindeki sürtünme, dolandırıcılığa karşı artan düzenlemelerle birlikte büyük bir zorluk olmaya devam ediyor. Google ve Stripe tarafından başlatılan Güvenli Ödeme Onayı standardı, şu anda WebAuthn standardı üzerine inşa edilen en umut verici standarttır.

Güvenli Ödeme Onayı (SPC), dinamik bağlama gerekliliği de dahil olmak üzere PSD2 SCA'nın tüm önemli unsurlarını ele alırken, aynı zamanda kullanıcı deneyimini (UX) iyileştirmeye çalışır.

• Tarayıcıya Özgü UX Sunma: SPC, farklı satıcı siteleri ve relying party'ler arasında tutarlı ve akıcı bir kimlik doğrulama deneyimi sağlamak için tarayıcıdan yararlanır. Bu yaklaşımın, tutarlı bir görünüme sahip olarak ve ödeme yapanın farkındalığını garanti ederek, genellikle bir iframe'de oluşturulan içerikle elde edilenden daha fazla işlem güvenliği artırması amaçlanmıştır:

Örnek: https://www.w3.org/press-releases/2023/spc-cr/

• Kriptografik Kanıt Sağlama: Standart, kullanıcının ödeme ayrıntılarını onayladığına dair kriptografik kanıtın oluşturulmasını ve bilgileri WebAuthn challenge'ına kodlamaya gerek kalmadan WebAuthn assertion'ına dahil edilmesini sağlar.

• Üçüncü Taraf Kaydına İzin Verme: Bir authenticator kaydının birinci taraf bağlamında gerçekleşmesi gereken WebAuthn Level 2 standardının aksine, SPC, passkey'lerin doğrudan bir cross-origin iframe'den kaydedilmesini sağlar. Bu yetenek, ödeme ekosistemindeki yaygın kullanım durumlarını ele alır ve satıcılar ve ödeme işlemcileri için daha kolay entegrasyonu kolaylaştırır. Yukarıda tartıştığımız gibi, bu işlevsellik zaten altta yatan standardın bir sonraki sürümünün bir parçasıdır ve bu nedenle gelecekte muhtemelen SPC'den kaldırılacaktır.

• Ödemelerin Cross-Origin Kimlik Doğrulaması: SPC, başka bir Relying Party'den kimlik bilgilerini kullansa bile (sayfadan ayrılmaya gerek kalmadan) herhangi bir origin'in bir işlem için bir assertion oluşturmasına izin vererek WebAuthn'ın faydasını genişletir. Bu durumda, satıcıdan / ihraççıdan bir iframe bile gerekmez. Bu özellik, kimlik doğrulama sürecine birden fazla tarafın (satıcı + ihraççı / banka) dahil olduğu ve assertion'ın daha sonra doğrulama için orijinal Relying Party'ye (hesap sağlayıcı, ör. bir banka) taşınabildiği senaryolarda özellikle kullanışlıdır.

Yukarıdaki örnek SPC Açıklayıcısından alınmıştır ve ödemelerin Cross-Origin Kimlik Doğrulaması konseptini göstermektedir: SPC kullanan bir ödeme sürecinde, kullanıcı işlem boyunca satıcının sitesinde (mavi ile vurgulanmış) kalır. Web tarayıcısı (yeşil renkte) satıcının origin'inin görüntülenmesini sürdürür ve ayrıca işlemi onaylamak için dinamik bağlama için tüm önemli bilgileri (tutar + alıcı) içeren önceden tanımlanmış, özelleştirilemeyen bir diyalog sunar. Kullanıcının onayından sonra, işletim sistemi (turuncu renkte tasvir edilmiş) işlemi doğrulamak için gereken biyometrik kimlik doğrulamasını yönetir.

Bu hedefler, SPC'nin hem çevrimiçi ödemelerin güvenliğini hem de kullanıcı deneyimini iyileştirme taahhüdünü göstermekte, dijital ödeme ortamında yüksek güvenlik standartlarını korurken kimlik doğrulama süreçlerini basitleştirmeyi amaçlamaktadır.

SPC'nin izin vereceği tüm olası akışları gözden geçirelim ve faydalarını anlamak için bunları standart passkey'lerle karşılaştıralım.

Burada görebileceğimiz gibi, en önemli ayrım, satıcı web sitesinde bir iframe içinde henüz passkey'ler tarafından desteklenmeyen kayıt (yukarıdaki tartışmamıza bakın) ve tamamen yeni bir Cross-Origin Kimlik Doğrulama olasılığıdır. Bunları tek tek inceleyelim.

İşte doğrudan Mastercard sayfasında bir SPC passkey kaydetmenin bir maket örneği. Burada görebileceğiniz gibi, passkey oluşturma bu durumda SMS OTP ile kimlik doğrulamanın tamamlanmasından hemen sonra sunulmaktadır.

Bu durumda, iletişim standart bir passkey kayıt süreci gibi görünürdü çünkü bu tamamen birinci taraf bağlamında gerçekleşir.

Kaynak: https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Bu SPC passkey'i artık bir satıcı sitesinde kimlik doğrulama için, satıcı sitesindeki bir iframe'de ve Cross-Origin Kimlik Doğrulama için (aşağıya bakın) kullanılabilir.

Daha önce tartıştığımız gibi, bir satıcı web sitesinde bir SPC passkey kaydetme süreci tipik olarak ödeme işlemi sırasında, 3-D Secure (3DS) akışı bağlamında gerçekleşir. Bu akış, kart sahibinin kimliğini doğrulayan ek bir kimlik doğrulama adımı içererek çevrimiçi kredi ve banka kartı işlemlerinin güvenliğini artırmak için tasarlanmıştır.

Bir ödeme işlemi sırasında, 3DS akışı başlatıldığında, kimlik doğrulama süreci satıcının sitesinde (ör. amazon.com) barındırılan ancak ödeme hizmeti sağlayıcısı veya ihraççı banka (ör. mastercard.com) tarafından kontrol edilen bir iframe aracılığıyla kolaylaştırılır. Bu iframe, müşterinin mevcut kimlik doğrulama faktörlerini kullanarak kimliğini doğrulaması için güvenli bir ortam görevi görür.

Müşteri, bu geleneksel faktörleri (ör. SMS OTP veya bankacılık uygulaması) kullanarak kendini başarıyla doğruladıktan sonra, gelecekteki işlemler için bir SPC passkey kaydetme fırsatı doğar. SPC Standardı, iframe'ler içinden cross-origin passkey oluşturulmasına izin verdiği için bu çalışacaktır. Bu passkey'in iframe'de kaydedilmesi, tipik olarak müşterinin uyumlu bir cihazda parmak izini veya yüz tanımayı doğrulamak gibi passkey'i oluşturan ve kredi kartına bağlayan bir eylem gerçekleştirmesini içerir. Unutmayın ki iframe, ödeme hizmeti sağlayıcısı (ör. PayPal) veya ihraççı banka (ör. mastercard.com) tarafından kontrol edilir. Bu nedenle, SPC passkey'i satıcı ile değil, doğrudan ihraççı / banka ile oluşturulur. Basitleştirilmiş akış şöyle görünürdü:

Kaynak: https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

https://spc-merchant.glitch.me/ adresinde, Google, Windows ve Mac'te Chrome aracılığıyla erişilebilen ve bunun bir iframe içinden nasıl çalışacağını gösteren bir demo uygulaması kurmuştur:

Ayrıca, https://spc-rp.glitch.me/reauth altında barındırılan bankanın sitesiyle doğrudan oynamanıza da olanak tanır. Bu örnekte, satıcı ile ihraççı / banka arasında API'lerle bant dışı iletişime gerek yoktur – her şey tarayıcı tarafından halledilir. Mevcut bir passkey kullanarak kimlik doğrulama, iframe içinden aynı şekilde çalışır.

Aşağıdaki örnekte, kullanıcının Mastercard ile zaten bir SPC Passkey kaydettiği Cross-Origin Kimlik Doğrulamasını görüyoruz. Örnek satıcı sitesi (decorshop.com) Cross-Origin Kimlik Doğrulamasını tetikleyebilir. En büyük ve önemli fark, kimlik doğrulama işlemi sırasında satıcı / ihraççı sayfasının hiçbir zaman görünür olmamasıdır. Tarayıcı, işletim sistemi ile birlikte önceden tanımlanmış ödeme UX'ini (SPC standardının tarayıcı uygulaması tarafından sağlanır) ve kimlik doğrulama modalını (WebAuthn standardı) sunar. Satıcı ve ihraççı / banka arasındaki iletişim arka planda halledilir.

Orijinal kaynak (kısmen düzenlenmiştir): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Orijinal kaynak (kısmen düzenlenmiştir): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Cross-Origin Kimlik Doğrulama kullanıldığında, satıcı, mevcut kimlik bilgileri hakkında bilgi alışverişi yapmak için bir tür API aracılığıyla ihraççı / banka ile iletişim kurar (yukarıdaki sıra şemasında #2). Kimlik bilgileri mevcutsa ve kullanıcının tarayıcısı SPC'yi destekliyorsa, kimlik doğrulama başlar. Sonunda, assertion, EMV 3DS gibi mevcut protokoller aracılığıyla ihraççı / bankaya geri döndürülür ve burada assertion sonunda kriptografik olarak doğrulanabilir (#16).

Assertion aynı zamanda tarayıcı tarafından görüntülenen bilgiler hakkında da bilgi içerdiğinden, dinamik bağlama için tüm gereklilikler yerine getirilir. Bu, UX ve müşteri ödeme deneyimi iyileştirmeleri açısından büyük bir adım olacaktır.

Güvenli Ödeme Onayı (SPC) standardı, güvenliği artırırken kullanıcı deneyimini kolaylaştırmayı amaçlayan çevrimiçi ödeme kimlik doğrulaması dünyasında ilginç bir gelişmedir. Bugün itibarıyla, Google Chrome, SPC'yi bir şekilde destekleyen tek büyük tarayıcıdır. Ancak, standardın kısmen Google tarafından başlatıldığı düşünüldüğünde bu şaşırtıcı değildir. Apple'ın Safari'si ve Mozilla Firefox gibi diğer büyük tarayıcılardan, SPC'yi destekleme planları hakkında net sinyaller olmaksızın belirgin bir taahhüt eksikliği vardır. Özellikle Apple, kendi tescilli Standardı olan Apple Pay'i zorlamakta ve diğer ödeme standartlarıyla ilgilenmiyor gibi görünmektedir.

SPC'nin WebAuthn ile bağlantısı, geliştirme sürecini daha zor hale getirmiştir. Bunun nedeni, SPC standardındaki herhangi bir geliştirme veya değişikliğin, fazlalığı önlemek ve mevcut yetenekler üzerinde gerçek iyileştirmeler sağladıklarından emin olmak için dikkatlice değerlendirilmesi gerektiğidir. Amaç, SPC'yi, ödeme sürecinde WebAuthn tarafından tam olarak kapsanmayan belirli ihtiyaçlara hizmet edecek şekilde iyileştirmektir; örneğin, ödeme akışına doğrudan entegrasyon ve farklı satıcı sitelerinde sorunsuz bir şekilde çalışabilen daha kullanıcı dostu bir kimlik doğrulama deneyimi sağlamak gibi.

SPC gelişmeye devam ettikçe, farklı tarayıcılarda benimsenmesi, yaygın uygulama için çok önemli olacaktır. Google gibi büyük oyuncuların katılımı olumlu bir yönü işaret etse de, SPC'yi çevrimiçi ödeme endüstrisinde bir standart olarak yerleştirmek için daha geniş destek gerekli olacaktır.

Yukarıda özetlenen zorluklar, özellikle ödeme yapanın farkındalığı etrafında, WebAuthn Çalışma Grubu'nda WebAuthN Standardı içinde onay uzantısı (confirmation extension) (eski adıyla “txAuthSimple”) olarak adlandırılan bir eklenti üzerinde devam eden çalışmalara yol açmıştır. Amacı, authenticator'ın veya tarayıcının/işletim sisteminin (ayrıcalıklı bir kullanıcı arayüzünde) işlem ayrıntılarını kullanıcıya göstermesine ve relying party'nin, kullanıcının bu ayrıntıları gerçekten onayladığına dair kriptografik kanıt almasını sağlamaktır. Bu, bölüm 3.3.1'de açıklanan “garantili kullanıcı farkındalığı eksikliği” sorununu doğrudan ele alır.

Güvenli Ödeme Onayı'nın (SPC) özel, tarayıcı odaklı bir diyalog sağlamasına benzer şekilde, onay uzantısı da “Ne Görürsen Onu İmzalarsın” (WYSIWYS) endişesini ele alır. Ana hedefleri şunlardır:

• İşlem Ayrıntılarının Güvenilir Gösterimi: Tutarı ve alıcıyı göstermeyi web içeriğine bırakmak yerine, uzantı ya bir cihazın güvenli ekranından ya da işletim sisteminin kontrolü altındaki bir tarayıcı kullanıcı arayüzü diyaloğundan yararlanır.
• Kriptografik Kanıt: Authenticator (veya istemci platformu), görüntülenen metnin tam bir kaydını imzalar. Bu imzayı doğrulayarak, relying party, kullanıcıya doğru ayrıntıların gösterildiğini onaylayabilir.
• Authenticator Görüntülemeyi Desteklemiyorsa Geri Çekilme (Fallback): Bir donanım authenticator'ının metin gösteremediği durumlarda, tarayıcı bunu görüntüleyebilir ve [=client data=] içine dahil edebilir. Bu daha zayıf bir garantidir ancak daha geniş uyumluluk sağlar.

Uzantı, mevcut WebAuthn uzantı yapılarına yeni bir alan ekler. Relying Party'ler, confirmation adı verilen basit bir metin dizesi (isteğe bağlı temel biçimlendirme ile) sağlarlar:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

İstemci (tarayıcı) bunu aldığında:

1. Kullanıcıyı özel bir onay diyaloğu ile yönlendirir (böylece bunun temel bir girişten daha fazlası olduğunu bilirler).
2. Authenticator uzantıyı destekliyorsa, aynı dizeyi CBOR verisi olarak authenticator'a iletir.
3. Herhangi bir authenticator çıktısını Relying Party'ye döndürür.

Authenticator metin görüntülemeyi destekliyorsa, kullanıcı doğrulamasını tamamlamadan önce bu metni (örneğin, kendi ekranında veya güvenilir kullanıcı arayüzünde) göstermelidir. Ardından aynı dizeyi imzalı çıktısına dahil eder.

Relying Party tarafında, doğrulama adımları, döndürülen confirmation metninin gönderilenle eşleştiğini sağlar. Authenticator uzantı çıktısı eksikse ancak Relying Party politikası bir geri çekilmeye izin veriyorsa, Relying Party, istemci verilerinden gelen confirmation değerine güvenebilir—bu, metni authenticator yerine tarayıcının görüntülediğini gösterir.

Alıcıyı ve tutarı bu uzantıya gömerek, kullanıcı güvenilir bir ekranda tam olarak neyi yetkilendirdiğini görür. Kullanıcının imzası artık sadece özetlenmiş bir challenge'ı değil, aynı zamanda tam işlem metnini de yansıtır. Bu, PSD2'nin dinamik bağlama gerekliliği için özellikle değerlidir, çünkü:

• Görüntülemeden sonra işlem ayrıntılarının herhangi bir uyuşmazlığı veya değiştirilmesi imzayı geçersiz kılar.
• Relying Party, imzalama sırasında kullanıcıya doğru işlem ayrıntılarının verildiğini kanıtlayabilir, bu da PSD2'nin “ödeme yapanın farkındalığı” gerekliliğini sadece challenge'daki verileri özetlemekten çok daha sağlam bir şekilde yerine getirir.

Onay uzantısı hala tartışma aşamasında olsa da, daha güvenli ve kullanıcı dostu işlem akışlarına doğru önemli bir adımı temsil etmektedir. Doğrudan WebAuthn spesifikasyonuna dahil edilerek şunları sunar:

• Birlikte Çalışabilirlik: Uzantıyı uygulayan herhangi bir authenticator veya istemci aynı standartlaştırılmış formatı izleyecektir.
• Esneklik: Relying Party'ler daha güçlü politikalar (authenticator düzeyinde görüntüleme gerektiren) uygulayabilir veya gerekirse tarayıcı düzeyinde geri çekilmeyi kabul edebilir.
• Daha Geniş Ekosistem Uyumu: Özellikle sağlam dinamik bağlama etrafında, PSD2 gibi düzenleyici zorunluluklarla iyi uyum sağlar.

Daha fazla teknik ayrıntı için devam eden tartışmaya göz atabilirsiniz: GitHub pull request #2020. Özetle, onay uzantısı, standart passkey tabanlı akışlardaki son büyük boşluğu da kapatabilir: kullanıcının onayını verdiğinde tam olarak ne gördüğüne dair kriptografik kanıt sağlamak, ancak Güvenli Ödeme Onayı'na göre daha az yapılandırılmış bir şekilde. Tarayıcılar ve authenticator satıcıları arasında ilgi görürse, PSD2 dinamik bağlama altında—ve ötesinde—gerekli olan WYSIWYS güvenlik garantisini sunmak için oldukça standartlaştırılmış bir yöntem haline gelebilir.

SPC ve onay uzantısı, WebAuthn'da dinamik bağlamayı güçlendirmek için ortak bir hedefi paylaşsalar da, kapsam ve yaklaşım açısından farklılık gösterirler. Aşağıdaki tablo bu farklılıklardan bazılarını vurgulamaktadır:

Özünde, SPC kapsamlı bir ödeme çözümü sunmaya çalışır* ve akışının bir parçası olarak dinamik bağlamayı da içerir*. Onay uzantısı* ise, tam bir ödeme akışı dayatmadan standart WebAuthn mesajları içinde “ne görürsen onu imzalarsın” gerekliliğini ele alır. Her iki yaklaşım da PSD2 uyumluluğunu kolaylaştırabilir, ancak her biri gerçek dünya faydaları sunmak için tarayıcı ve authenticator desteğine bağlıdır.

İhraççılar, bankalar ve finans kurumları için önerimiz, bu nedenle hangi kullanım durumlarının kapsanması gerektiğini dikkatlice değerlendirmeleri ve ekosistemin gelişimini izlemeleridir, çünkü passkey'lerin kolaylığı mevcut SCA ve dinamik bağlama çözümleri üzerinde UX'lerini iyileştirmeleri için önemli bir baskı oluşturacaktır. Müşteriler web'de biyometrik çözümler talep edecektir. Şu anki operasyonel önerimiz şudur:

• ✔️ İhraççı / Banka Web Sitesinde Başlatılan Ödemeler için Passkey'ler: Passkey'ler, ihraççılar / bankaların dinamik bağlamayı doğrudan web sitelerine ve uygulamalarına uygulamaları için çok iyi bir çözümdür. Yüksek riskli ödemeler için güvenliği daha da artırmak amacıyla anlık bildirimler, e-posta / SMS OTP veya TOTP gibi diğer kimlik doğrulama seçenekleriyle birleştirilebilirler. Elbette, SCA uyumluluğuna ilişkin hususlar her zaman bu tartışmanın bir parçası olmalıdır (ayrıca passkey'ler ve SCA üzerine 4 bölümlük serimize bakın).

  Önerilen bir çözüm, passkey'ler açık WebAuthn standardına dayandığı için ihraççılar / bankalar tarafından kendileri uygulanabilir. Ancak bu, önemli bir bilgi birikimi, istisnai durumlarla başa çıkma ve tüm yeni düzenlemeleri ve teknik gelişmeleri sürekli takip etmeyi gerektirir. Alternatif, üçüncü taraf bir kimlik doğrulama sağlayıcısı kullanmaktır. Örneğin, Corbado Connect, ayarlanmış WebAuthn challenge'larından yararlanarak işlem imzalama yoluyla dinamik bağlamayı destekler. Tüm bilgiler denetim günlüğüne kaydedilir. Bu sadece finansal kurumlar için değil, aynı zamanda her türlü imza (ör. belge imzalama, yüksek riskli kullanıcı eylemleri) için de kullanılabilir. İsteğe bağlı olarak, güvenliği daha da artırmak için ek bir SMS veya E-posta OTP kullanılabilir.

• ❌ Satıcı Sayfalarındaki Ödemeler için Passkey'ler: Satıcı sayfalarındaki ödemeler için passkey'leri kullanıma sunmak henüz mümkün değildir. Cross-origin kullanım durumları hala geliştirme aşamasındadır ancak 2024'ün sonunda geçerli bir seçenek olabilir. Ancak, satıcı sayfalarında kimlik doğrulama için passkey'leri kullanmak bugün zaten harika bir fikirdir ve gelecekte ödemeler için de kullanılabilecek passkey'leri toplamaya başlamak için de kullanılabilir.

• ❌ Dinamik Bağlama için SPC Passkey'leri veya Onay Uzantısı: SPC Standardı henüz üretim ortamlarında kullanılacak olgun bir duruma ve desteğe ulaşmamıştır.

Genel olarak, satıcıların ve bankaların standartla etkileşime girmeye ve gereksinimlerini ve desteklerini ekosisteme eklemeye başlamasından memnunuz. İleriye bakıldığında, finansal kurumlar ve e-ticaret platformları bu teknolojik gelişmeleri yakından izlemeli ve passkey'leri sistemlerine nasıl entegre edebileceklerini düşünmelidir. Düzenlemeler gelişmeye devam ettikçe, ödeme kimlik doğrulama süreçlerinin en son güvenlik standartlarıyla uyumlu olmasını ve tüketiciler için dönüşümü iyileştiren ve sürtünmeyi azaltan güvenli, verimli bir kullanıcı deneyimi sunmasını sağlamak için eğrinin önünde kalmak çok önemlidir.

Passkey'ler neden önemlidir?

Kurumsal Şirketler için Passkey'ler

Şifreler ve kimlik avı saldırıları kurumsal şirketleri riske atar. Passkey'ler, güvenlik ve kullanıcı deneyimini dengeleyen tek MFA çözümünü sunar. Whitepaper'ımız, uygulama ve iş etkisini kapsar.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Dinamik bağlama için passkey'leri incelediğimizde, passkey'lerin SCA ve dinamik bağlamaya uymaya yardımcı olabilmesine rağmen, başlangıçta birinci taraf bağlamları için tasarlanmış olan WebAuthn standardı ile üçüncü taraf hizmetlerdeki teknik entegrasyonun bazı zorluklar sunduğu açıktır. Bu standartlar, uygulamalarında daha fazla esneklik gösterme yönünde bir kayma sergileyerek, üçüncü taraf senaryolarını daha iyi desteklemek için yavaş yavaş gelişmektedir. Güvenli Ödeme Onayı (SPC), çeşitli satıcı sitelerinde daha kullanıcı dostu ve sorunsuz etkileşimler içererek ödeme kimlik doğrulama süreçlerini geliştirmeyi amaçlayarak bu adaptasyonu daha da ileriye taşımayı hedeflemektedir.

HBununla birlikte, SPC standardının veya Onay Uzantısının ilerlemesi ve daha geniş kabul görmesi, büyük tarayıcılar tarafından benimsenmesine büyük ölçüde bağlıdır—bu süreç yavaş ilerlemiş ve şu anda yalnızca Google Chrome destekçi konumundadır. Bu yavaş benimsenme oranı, daha fazla tarayıcı entegre etmeye başlamadıkça, özellikle SPC'nin mevcut durumunun ötesine geçmesini potansiyel olarak engelleyebilir. Passkey'lerin devam eden gelişimi ve artan çekiciliği, güvenli enklavlar, TEE'ler ve TPM'ler gibi donanım güvenlik modüllerine (HSM'ler) dayanan sistemlerin ödeme uygulamaları için de önemli bir rol oynayacağı umut verici bir yönü işaret etmektedir, çünkü bu teknolojiler, ödemelerin dinamik bağlanmasını sadece bankacılık sitelerinde başlatılan işlemler için değil, aynı zamanda üçüncü taraf satıcı platformlarında da daha pratik ve konforlu hale getirebilecek gelişmiş güvenlik sunar.

Passkey'lerin faydalarını çevrimiçi ödeme süreçlerine genişletme potansiyeli, web tabanlı işlemleri güvence altına almada ve genel olarak İnternet'i daha güvenli bir yer haline getirmede önemli bir yönü vurgulamaktadır.