---
url: 'https://www.corbado.com/id/blog/webauthn-signal-api'
title: 'WebAuthn Signal API: Memperbarui & Menghapus Passkey di Sisi Klien'
description: 'Pelajari bagaimana WebAuthn Signal API memungkinkan penghapusan passkey dan pembaruan metadata (user.name, user.displayName) secara lancar di autentikator sisi klien.'
lang: 'id'
author: 'Vincent Delitz'
date: '2025-08-08T11:42:54.462Z'
lastModified: '2026-05-28T06:08:37.667Z'
keywords: 'webauthn signal api, hapus passkey di sisi klien, update passkey di sisi klien, perbarui passkey, hapus passkey, update metadata passkey, update user.displayName passkey, update user.name passkey'
category: 'WebAuthn Know-How'
---

# WebAuthn Signal API: Memperbarui & Menghapus Passkey di Sisi Klien

### WebAuthn Signal API: Dukungan Browser & Platform

_Terakhir diperbarui: 4 November 2025_

Berikut adalah ringkasan cepat mengenai dukungan
[WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api) di berbagai platform:

| Platform    | Dukungan Web                        | Dukungan Native                                                                                                                            |
| :---------- | :---------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- |
| **Windows** | ✅ Chrome + Google Password Manager | N/A                                                                                                                                        |
| **macOS**   | ✅ Safari 26+ (iCloud Keychain)     | N/A                                                                                                                                        |
| **iOS**     | ✅ Safari 26+ (iCloud Keychain)     | ✅ iOS 26+ ([WWDC 2025 Session 279](https://developer.apple.com/videos/play/wwdc2025/279/?time=787))                                       |
| **Android** | 🧪 Chrome 143 (Beta)                | 🧪 Credential Manager Alpha ([v1.6.0-alpha05](https://developer.android.com/jetpack/androidx/releases/credentials); beta di v1.6.0-beta03) |

⚠️ **Masalah yang Diketahui:** Safari 26+ memiliki bug di mana promise tidak terselesaikan
dengan benar ([WebKit Bug #298951](https://bugs.webkit.org/show_bug.cgi?id=298951)).
Perbaikan sedang menunggu proses merge.

## 1. Pendahuluan: WebAuthn Signal API

Ekosistem passkey terus berkembang. Untuk memfasilitasi perubahan ini, standar WebAuthn
yang mendasarinya juga berevolusi dengan cepat. Fitur-fitur baru sering kali dimulai dari
penjelasan teknis (technical explainer) di GitHub, lalu berkembang menjadi _pull request_
ke dalam standar setelah didiskusikan secara matang. Baru-baru ini,
[pull request ini](https://github.com/w3c/webauthn/pull/2093) telah ditambahkan ke dalam
draf standar sebagai [WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api).

Di artikel ini, kita akan membahas:

- **Mengapa WebAuthn Signal API dibutuhkan:** Kasus penggunaan apa saja yang didukung oleh
  [WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api)?
- **Cara kerja WebAuthn Signal API:** Bagaimana tepatnya API ini bekerja? Apa
  rekomendasinya bagi [Relying Party](https://www.corbado.com/glossary/relying-party)?

Saat artikel ini ditulis, WebAuthn Signal API sudah diaktifkan secara default sejak
Chrome 132. Sebelumnya, fitur ini dikenal sebagai Reporting API sebelum namanya diganti
untuk menghindari konflik dengan
[API lain](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API) yang bernama
sama.

## 2. Kegunaan WebAuthn Signal API

WebAuthn Signal API menjawab kebutuhan spesifik terkait pengelolaan passkey di sisi klien
(_client-side_). Secara khusus, API ini membantu menjaga sinkronisasi informasi antara
[Relying Party](https://www.corbado.com/glossary/relying-party) (RP) dan [authenticator](https://www.corbado.com/glossary/authenticator)
yang menjadi bagian dari sistem operasi di sisi klien. Berikut adalah beberapa kasus
penggunaan penting:

### 2.1 Memperbarui Metadata Passkey di Authenticator Sisi Klien

Saat [passkey dibuat](https://www.corbado.com/id/faq/bagaimana-passkey-dibuat), ada beberapa informasi yang
disertakan: `user.id`, `user.name`, dan `user.displayName`. Passkey itu sendiri
diidentifikasi melalui [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) yang unik.

- **user.id:** adalah pengenal unik yang mewakili akun tempat passkey ditautkan. `user.id`
  ini sangat krusial karena digunakan untuk mencocokkan passkey dengan akun pengguna yang
  sebenarnya.
- **user.name dan user.displayName:** ini adalah metadata yang digunakan semata-mata untuk
  tujuan tampilan di antarmuka pengguna (UI).

Ilustrasi berikut menunjukkan struktur database sederhana yang menjelaskan informasi mana
yang biasanya disimpan di kolom (field) mana:

![struktur database passkey](https://www.corbado.com/website-assets/passkey_database_structure_ff43f765dd.png)

Penting untuk dipahami bahwa meskipun `user.name` (sering kali berupa alamat email) dan
`user.displayName` (nama yang lebih mudah dibaca) membantu pengguna mengidentifikasi akun
mereka di UI pemilihan, **asosiasi nyata antara passkey dan akun tetap dijaga melalui**
`user.id` dan **Credential ID**:

- Sebuah akun bisa memiliki banyak passkey, tetapi setiap passkey secara unik
  diidentifikasi dan dicocokkan ke akun menggunakan `user.id`.
- Setiap passkey itu sendiri memiliki [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle)
  unik yang dibuat oleh [authenticator](https://www.corbado.com/glossary/authenticator).

Masalah muncul ketika `user.name` (misalnya alamat email) berubah. Saat ini, tidak ada
mekanisme untuk memperbarui perubahan ini secara langsung di
[authenticator](https://www.corbado.com/glossary/authenticator) sisi klien. `user.name` bisa berubah karena
berbagai alasan, seperti saat pengguna mengganti alamat email mereka. Meskipun metadata
akun di sisi server sudah berubah, `user.name` yang lama akan terus muncul di UI pemilihan
kredensial, yang bisa membingungkan pengguna.

Solusi sementara (_workaround_) untuk masalah ini adalah membuat passkey baru dengan
`user.name` yang sudah diperbarui dan `user.id` yang sama, lalu menimpa passkey yang ada.
Namun, pendekatan ini merepotkan karena beberapa alasan:

1. **Redundansi**: Authenticator hanya dapat menyimpan satu passkey per `user.id` untuk ID
   [Relying Party](https://www.corbado.com/glossary/relying-party) tertentu. Artinya, passkey lama harus diganti
   dengan yang baru hanya untuk memperbarui metadata, yang merupakan langkah tambahan.
2. **User Experience (UX)**: Pengguna tidak akan mengerti mengapa mereka perlu membuat
   passkey baru. Itulah sebabnya solusi ini tidak banyak digunakan.
3. **Kompleksitas**: Mengelola [pembuatan passkey](https://www.corbado.com/id/faq/bagaimana-passkey-dibuat) dan
   penggantian hanya untuk memperbarui metadata adalah kerumitan yang tidak perlu.

Alamat email, nomor telepon, dan pengenal lainnya bisa berubah secara berkala. Tanpa
metode yang mudah untuk memperbarui `user.name` dan `user.displayName` langsung di
authenticator, pengguna mungkin akan terus melihat dan harus memilih passkey yang terkait
dengan email lama mereka. Situasi ini merusak pengalaman mulus yang ingin ditawarkan oleh
passkey. WebAuthn Signal API bertujuan untuk memecahkan masalah ini dengan memungkinkan
Relying Party melaporkan pembaruan metadata passkey tanpa perlu membuat passkey baru.
Sebelum kita membahas cara mengimplementasikan Signal API, mari kita lihat kasus
penggunaan penting kedua.

### 2.2 Menghapus Passkey di Sisi Klien

Kasus penggunaan penting lainnya adalah penghapusan passkey di authenticator sisi klien.
Seiring waktu, pengguna mungkin mencabut kredensial melalui daftar manajemen passkey atau
menghapus akun mereka, dan kita perlu memastikan bahwa kredensial ini dihapus dari
authenticator sisi klien agar tidak muncul lagi di UI pemilihan kredensial di masa
mendatang ([Conditional UI](https://www.corbado.com/glossary/conditional-ui) /
[passkey autofill](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill)).

Kebutuhan akan fungsionalitas ini muncul dalam beberapa skenario:

1. **Passkey dihapus melalui pengaturan akun**: Ketika kredensial tidak lagi valid,
   misalnya setelah pengguna secara eksplisit menghapusnya melalui pengaturan akun:

![daftar passkey](https://www.corbado.com/website-assets/passkey_list_315a76814a.png)

```
Dari sudut pandang pengguna, sulit untuk memahami bahwa penghapusan di pengaturan akun mereka (seperti dialog di atas) tidak secara otomatis menghapus passkey di perangkat klien ini.
```

2. **Penghapusan Akun**: Ketika pengguna menghapus akun mereka, semua passkey yang terkait
   juga harus dihapus.

3. **Kebijakan Keamanan**: Relying Party mungkin memiliki kebijakan keamanan yang
   mengharuskan pencabutan kredensial setelah periode tidak aktif tertentu atau karena
   masalah keamanan yang terdeteksi.

Tanpa metode langsung untuk menghapus passkey di sisi klien, kredensial yang sudah
kedaluwarsa atau tidak valid ini akan terus memenuhi UI pemilihan, yang menyebabkan
kebingungan. Pengguna mungkin melihat dan mencoba menggunakan passkey yang sudah tidak
valid, mengakibatkan kegagalan
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) dan pengalaman pengguna
yang buruk.

Lihat video ini tentang cara menghapus passkey sisi server di Corbado Connect Management
Console:

[Watch on YouTube](https://www.youtube.com/watch?v=wQdQfHuthxU)

## 3. Cara Mengimplementasikan WebAuthn Signal API

Mengimplementasikan WebAuthn Signal API melibatkan beberapa langkah dan pertimbangan untuk
memastikan fungsionalitasnya terintegrasi dengan benar dan aman. Signal API memungkinkan
Relying Party (RP) untuk memperbarui atau menghapus kredensial passkey di authenticator
sisi klien. Bagian ini menguraikan pertimbangan utama dan langkah-langkah implementasinya.

### 3.1 Pertimbangan Penting

Saat mengimplementasikan WebAuthn Signal API, sangat penting untuk mengingat hal-hal
berikut:

- **Menjaga Privasi**: WebAuthn Signal API dirancang untuk menjaga privasi pengguna karena
  ini adalah salah satu fondasi WebAuthn. Artinya, tidak ada umpan balik yang diberikan
  kepada RP tentang apakah perubahan yang diminta berhasil diproses. API ini beroperasi
  secara diam-diam (silent) untuk mencegah potensi kebocoran informasi tentang status
  kredensial.

- **Ketersediaan Authenticator**: Efektivitas WebAuthn Signal API bergantung pada
  ketersediaan authenticator. Ini mencakup ketersediaan fisik dan dukungan perangkat lunak
  (misalnya, kompatibilitas browser dan sistem operasi). Browser hanya dapat melakukan
  tindakan jika authenticator dapat diakses dan mendukung operasi yang diperlukan tanpa
  memerlukan [autentikasi biometrik](https://www.corbado.com/id/faq/apa-itu-passkeys).

- **Batasan Domain**: API memastikan bahwa hanya Relying Party yang terkait dengan domain
  tertentu yang dapat meminta perubahan pada kredensial yang terkait dengan domain
  tersebut. Ini adalah langkah keamanan untuk mencegah modifikasi tidak sah oleh pihak
  ketiga.

- **Credential ID sebagai Kunci**: Saat merujuk passkey,
  [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) adalah kunci utama yang digunakan
  oleh WebAuthn Signal API. ID ini secara unik mengidentifikasi passkey di authenticator
  sisi klien. API memungkinkan RP untuk mengubah metadata yang terkait dengan passkey atau
  memberi sinyal bahwa passkey tertentu tidak boleh lagi diakses, tetapi hanya melalui
  Credential ID. Jika authenticator tidak mengenali Credential ID tertentu, ia akan
  mengabaikannya secara diam-diam.

Pertimbangan ini sangat penting untuk memahami aspek paling krusial agar WebAuthn Signal
API berfungsi dengan benar.

### 3.2 Bagaimana Cara WebAuthn Signal API Mengubah Metadata Passkey?

WebAuthn Signal API menyediakan mekanisme yang efisien bagi Relying Party (RP) untuk
memperbarui metadata yang terkait dengan passkey di authenticator sisi klien. Ini sangat
penting untuk memastikan pengguna melihat informasi yang akurat dan terkini di UI
pemilihan kredensial tanpa harus membuat passkey baru yang tidak perlu. Begini cara API
ini mewujudkannya:

**Memperbarui Metadata dengan signalCurrentUserDetails(options)**

Metode `signalCurrentUserDetails(options)` dalam Signal API dirancang khusus untuk
memperbarui metadata passkey. Metode ini memungkinkan RP memberikan nilai terbaru untuk
`user.name` dan `user.displayName`.

Berikut proses kerjanya (lihat juga
[standar WebAuthn Level 3](https://w3c.github.io/webauthn/#sctn-signalCurrentUserDetails)).

1. **Struktur Metode:** Metode `signalCurrentUserDetails(options)` mencakup `rp.id`,
   `user.id`, serta nilai terbaru untuk `user.name` dan `user.displayName`.

```javascript
PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});
```

2. **Memperbarui Metadata Lokal**: Authenticator akan mencari kredensial yang tersedia
   secara lokal yang cocok dengan `rpId` dan `userId`. Untuk semua kredensial yang cocok,
   authenticator akan memperbarui `name` dan `displayName` kredensial tersebut.

3. **Menjaga Privasi:** Proses ini dirancang untuk menjaga privasi. Signal API tidak
   memberikan umpan balik kepada RP tentang apakah pembaruan berhasil diproses, mencegah
   kebocoran informasi tentang status kredensial.

4. **Konsistensi di Seluruh Perangkat:** Dengan menjalankan metode
   `signalCurrentUserDetails(options)` secara teratur, RP dapat memastikan bahwa metadata
   untuk passkey tetap konsisten di berbagai perangkat dan platform tempat pengguna
   melakukan [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password). Pendekatan
   ini mengurangi kemungkinan informasi usang atau salah ditampilkan di UI pemilihan
   kredensial.

![google-password-manager-passkey-updated](https://www.corbado.com/website-assets/GPM_PK_updated_a1f50063d3.png)

Pada tangkapan layar di atas, Anda dapat melihat bagaimana Google Chrome memberi sinyal
pembaruan tersebut kepada pengguna. WebAuthn Signal API adalah bagian dari Chrome dan
dapat diuji dengan [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) di
desktop.

### 3.3 Bagaimana Cara WebAuthn Signal API Memberi Sinyal Passkey yang Dihapus?

WebAuthn Signal API menyediakan mekanisme bagi Relying Party (RP) untuk memberi sinyal
penghapusan passkey dari authenticator sisi klien. Ini penting untuk memastikan bahwa
kredensial yang usang atau tidak valid tidak muncul di UI pemilihan kredensial, sehingga
menjaga pengalaman pengguna yang rapi dan aman. Ada dua metode untuk menghapus passkey
secara lokal: `signalUnknownCredential(options)` dan
`signalAllAcceptedCredentials(options)`. Metode pertama dapat digunakan dalam situasi di
mana pengguna tidak terautentikasi, sedangkan metode kedua dapat digunakan saat pengguna
terautentikasi. Oleh karena itu, metode kedua lebih disukai karena alasan privasi.

Berikut cara kerja kedua metode tersebut:

#### 3.3.1 Menghapus Passkey dengan signalUnknownCredential

1. **Struktur Metode:** Metode `signalUnknownCredential(options)` mencakup `rpId` (ID
   Relying Party) dan `credentialId` (pengenal unik dari kredensial yang akan dihapus).

```javascript
PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id yang baru saja dicoba user, base64url
});
```

2. **Memanggil Metode**: RP memanggil metode ini kapan pun mereka mendeteksi bahwa sebuah
   kredensial harus dihapus. Ini bisa segera setelah upaya
   [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) dengan kredensial yang
   tidak valid, selama penghapusan akun, atau ketika pengguna mencabut kredensial melalui
   pengaturan akun.

3. **Penanganan Metode**: Saat metode `signalUnknownCredential(options)` dipanggil,
   authenticator sisi klien mencoba menemukan kredensial yang cocok dengan `rpId` dan
   `credentialID` yang ditentukan untuk dihilangkan. Tergantung pada kemampuan
   authenticator, kredensial akan dihapus atau prosedur khusus authenticator akan
   menyembunyikan kredensial tersebut dalam proses autentikasi di masa mendatang.

#### 3.3.2 Menghapus Passkey dengan signalAllAcceptedCredentials

1. **Struktur Metode:** Metode `signalAllAcceptedCredentials(options)` mencakup `rpId` (ID
   Relying Party), `userId`, dan daftar Credential ID yang valid
   `allAcceptedCredentialIds` (daftar pengenal unik kredensial yang harus disimpan).

```javascript
PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});
```

2. **Memanggil Metode**: RP memanggil metode ini kapan pun mereka mendeteksi bahwa
   kredensial harus dihapus dan memberikan sinyal daftar kredensial yang masih valid.
   Metode ini sebaiknya lebih diutamakan dibandingkan `signalUnknownCredential(options)`
   untuk menghapus kredensial.

3. **Penanganan Metode**: Saat metode `signalAllAcceptedCredentials(options)` dipanggil,
   authenticator sisi klien mencocokkan `rpId` dan `userId`. Authenticator kemudian
   mencari semua kredensial lokal yang cocok dengan `rpId` dan `userId`. Hasilnya
   dibandingkan dengan `allAcceptedCredentialIds`. Jika ada kredensial lokal yang tidak
   ada dalam `allAcceptedCredentialIds`, maka kredensial tersebut dihapus secara lokal
   (atau disembunyikan tergantung pada authenticator).

4. **Memunculkan Kembali Kredensial**: Jika kredensial hanya disembunyikan (tergantung
   pada authenticator) dan sekarang menjadi bagian dari `allAcceptedCredentialIds` lagi,
   maka kredensial ini akan hadir kembali dalam proses autentikasi di masa depan.

5. **Tips Bermanfaat**:
    - Saat menggunakan `signalAllAcceptedCredentials(options)`, penting untuk dicatat
      bahwa authenticator mungkin tidak selalu terhubung pada saat metode ini dijalankan.
      Akibatnya, Relying Party bisa mempertimbangkan untuk menjalankan
      `signalAllAcceptedCredentials(options)` secara berkala, seperti pada setiap proses
      masuk (sign-in), untuk memastikan semua kredensial mutakhir.
    - Relying Party harus berhati-hati saat menentukan daftar ID kredensial
      (`allAcceptedCredentialIds`). Kredensial yang tidak termasuk dalam daftar ini
      mungkin disembunyikan atau dihapus oleh authenticator, yang berpotensi tidak dapat
      dikembalikan. Untuk mencegah kredensial valid terhapus secara tidak sengaja, sangat
      penting untuk memastikan daftarnya lengkap. Jika ID kredensial yang valid secara
      tidak sengaja tertinggal, ID tersebut harus ditambahkan kembali ke
      `signalAllAcceptedCredentials(options)` sesegera mungkin agar terlihat lagi, dengan
      asumsi authenticator mendukung hal ini.
    - Jika memungkinkan, authenticator sebaiknya lebih memilih untuk menyembunyikan
      kredensial sementara daripada menghapusnya secara permanen. Pendekatan ini dapat
      membantu memfasilitasi pemulihan jika ID kredensial yang valid secara tidak sengaja
      dihilangkan oleh Relying Party, memungkinkannya dipulihkan tanpa kehilangan
      permanen.

![GPK_PK_deleted_all.png](https://www.corbado.com/website-assets/GPK_PK_deleted_all_c211cc9e0a.png)

Pada tangkapan layar di atas, Anda dapat melihat bagaimana Google Chrome memberi sinyal
penghapusan. WebAuthn Signal API dapat diuji dengan
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) di desktop.

## 4. Rekomendasi

Untuk mengimplementasikan WebAuthn Signal API secara efektif dan memastikan sinkronisasi
metadata passkey yang mulus di seluruh authenticator sisi klien, pertimbangkan rekomendasi
berikut:

- **Pantau pembaruan WebAuthn Signal API dan implementasi aktualnya**: Tetap terinformasi
  tentang perkembangan dan pembaruan terbaru terkait Signal API. WebAuthn Signal API
  diaktifkan dengan
  [Google Chrome 132](https://chromestatus.com/feature/5101778518147072), diikuti oleh
  browser lain (misalnya
  [Safari juga mengumumkan dukungannya](https://github.com/WebKit/standards-positions/issues/400)).
  Periksa kemajuan dan pembaruan WebAuthn Signal API secara berkala untuk memastikan
  implementasi Anda selaras dengan standar dan praktik terbaru. Kami akan memperbarui
  artikel blog ini seiring berkembangnya situasi.
- **Mulai dengan pendekatan `signalAllAcceptedCredentials(options)` setelah setiap login
  berhasil**: Pendekatan ini memastikan bahwa semua metadata dan ID kredensial diperbarui
  dalam satu metode, menyederhanakan proses dan menjaga konsistensi di seluruh perangkat
  dan platform, sekaligus menonaktifkan kredensial yang dihapus atau usang.
- **Pesan waktu nyata (real-time) dengan `signalUnknownCredential(options)` untuk
  penerapan skala besar**: Pertimbangkan menggunakan pesan real-time dengan metode
  `signalUnknownCredential(options)` dalam penerapan skala besar atau ketika ada kebutuhan
  untuk pembaruan segera. Metode ini dapat meningkatkan efisiensi dan akurasi manajemen
  kredensial, memastikan bahwa kredensial yang tidak valid atau usang segera dihapus dari
  UI pemilihan.

Dengan mengikuti rekomendasi ini, Anda dapat mengimplementasikan WebAuthn Signal API
secara efektif setelah didukung, memastikan metadata passkey tetap mutakhir dan konsisten
di semua authenticator sisi klien, sehingga memberikan pengalaman pengguna yang lancar dan
aman untuk passkey.

## 5. Kesimpulan

Standar WebAuthn terus berkembang, menjadi semakin kaya fitur setiap bulannya. Pengenalan
WebAuthn Signal API adalah langkah maju yang signifikan dalam mengelola metadata passkey
dan penghapusan di authenticator sisi klien. API ini menjawab kasus penggunaan krusial
untuk menjaga sinkronisasi informasi antara Relying Party (RP) dan authenticator, serta
memastikan passkey yang tidak valid atau usang dihapus, sehingga meningkatkan pengalaman
pengguna.

- **Mengapa Signal API dibutuhkan?** Signal API sangat penting untuk memperbarui metadata
  passkey dan menghapus passkey di authenticator sisi klien. Ini menyelesaikan masalah
  terkait informasi `user.name` dan `user.displayName` yang usang, yang dapat menyebabkan
  kebingungan saat kredensial ditampilkan di UI pemilihan. Selain itu, ini membantu
  menjaga antarmuka pemilihan kredensial tetap bersih dan aman dengan menghapus passkey
  yang dicabut atau dihapus.
- **Bagaimana cara kerja Signal API?** Signal API bekerja dengan memungkinkan RP memanggil
  metode tentang status kredensial saat ini, termasuk pembaruan metadata dan memberi
  sinyal penghapusan passkey. Laporan ini diproses oleh authenticator sisi klien,
  memastikan informasi yang disajikan kepada pengguna akurat dan mutakhir. API ini
  dirancang untuk menjaga privasi dan beroperasi tanpa memberikan umpan balik kepada RP
  tentang keberhasilan pembaruan.

Seiring berkembangnya standar WebAuthn, standar ini mendapat manfaat dari beragam
kepentingan para pesertanya, yang mendorong berbagai bagian standar ke depan. Mengawasi
perkembangan ini sangat penting untuk tetap mengetahui peningkatan terbaru dan memastikan
implementasi tetap selaras dengan praktik terbaik dan standar terkini. Komunitas WebAuthn
terus mendorong inovasi, membuat autentikasi menjadi lebih aman dan ramah pengguna.