Deployment Considerations: High Value and Regulated Consumer
-
Content
-
2HCY23
-
-
-
Deployment Considerations: Work/School
-
Content
-
H2CY23
-
-
-
Persona-based demo site
-
Demo
-
H2CY23
-
-
-
-
-You can request content by [creating an issue on GitHub ](https://github.com/passkeydeveloper/passkeys.dev/issues/new/choose) (select the New Content Suggestion option).
diff --git a/content/device-support/_index.md b/content/device-support/_index.md
deleted file mode 100644
index b6ddbbaf..00000000
--- a/content/device-support/_index.md
+++ /dev/null
@@ -1,703 +0,0 @@
----
-layout: fullpage
-title: "Device Support"
-description: "Detailed information about passkey support across devices and ecosystems"
-lead: ""
-date: 2022-08-05T18:08:48.678Z
-draft: false
-images: []
-weight: 100
----
-
-This page, along with the rest of passkeys.dev, is targeted at relying party developers and is not intended to be an end user facing resource.
-
-> Said differently, **please don’t link to this page from end user focused resources** 😉
-
-## Overview
-
-Support for passkeys is currently rolling out across major operating systems and browsers. This page will be updated as the ecosystem evolves. The [matrix below](#matrix) maps out the various features that support the passkey experience. Additional information about each platform is available in the [Reference section of Docs](/docs/reference/android).
-
-Passkeys created in **iOS or iPadOS** can be used on:
-
-- The same iPhone or iPad
-- iPhones and iPads using the same Apple ID (synced automatically)
-- Macs using the same Apple ID (synced automatically)
-- Macs using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Windows devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Chromebooks and other ChromeOS devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Ubuntu devices in Edge and Chrome using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-
-Passkeys created in **Android** can be used on:
-
-- The same Android device
-- Android devices using the same Google account (synced automatically)
-- Macs using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Windows devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- iPhones and iPads using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Chromebooks and other ChromeOS devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-- Ubuntu devices in Edge and Chrome using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
-
-Passkeys created in **macOS** can be used on:
-
-- Macs using the same Apple ID (synced automatically)
-- iPhones and iPads using the same Apple ID (synced automatically)
- - Passkeys created on a Mac and synced to an iPhone and/or iPad via iCloud Keychain can be used in all the places listed above under "iOS or iPadOS"
-
-[Device-bound passkeys](/docs/reference/terms/#device-bound-passkey) created in **Windows** can be used on:
-
-- the same Windows device that created them
-
-## Matrix {#matrix}
-
-Test this client!
-
-
diff --git a/content/docs/_index.md b/content/docs/_index.md
deleted file mode 100644
index 9f778c29..00000000
--- a/content/docs/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title : "Docs"
-description: "Docs Doks."
-lead: ""
-date: 2020-10-06T08:48:23+00:00
-draft: false
-images: []
-sidebar:
- collapsed: true
----
diff --git a/content/docs/advanced/_index.md b/content/docs/advanced/_index.md
deleted file mode 100644
index 65cc18d7..00000000
--- a/content/docs/advanced/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Advanced"
-description: "Implement passkeys"
-lead: ""
-date: 2024-08-22T15:19:38.508Z
-draft: false
-images: []
-weight: 500
-sidebar:
- collapsed: true
----
diff --git a/content/docs/demos-examples/_index.md b/content/docs/demos-examples/_index.md
deleted file mode 100644
index 7a6311bc..00000000
--- a/content/docs/demos-examples/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Demos"
-description: "Resources for demoing and testing passkeys"
-lead: ""
-date: 2023-09-19T16:40:11.007Z
-draft: false
-images: []
-weight: 1100
-sidebar:
- collapsed: true
----
diff --git a/content/docs/implement/_index.md b/content/docs/implement/_index.md
deleted file mode 100644
index c0312737..00000000
--- a/content/docs/implement/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Implement"
-description: "Implement passkeys"
-lead: ""
-date: 2022-09-24T15:57:34.857Z
-draft: true
-images: []
-weight: 500
-sidebar:
- collapsed: true
----
diff --git a/content/docs/implement/requirements.md b/content/docs/implement/requirements.md
deleted file mode 100644
index 9a1a0668..00000000
--- a/content/docs/implement/requirements.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: "Requirements"
-description: ""
-lead: ""
-date: 2022-09-24T16:02:27.390Z
-draft: true
-images: []
-menu:
- docs:
- parent: "implement"
-weight: 501
-toc: true
----
-
-## Back End
-
-Your back end will need to generate a challenge, and a set of configuration parameters for WebAuthn.
-
-This challenge
-
-### Session Data
-
-### Persistent Data
-
-Each passkey will
-
-## Front End
diff --git a/content/docs/intro/_index.md b/content/docs/intro/_index.md
deleted file mode 100644
index 0c10f461..00000000
--- a/content/docs/intro/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Intro"
-description: "Intro to passkeys"
-lead: ""
-date: 2022-09-24T15:57:34.857Z
-draft: false
-images: []
-weight: 100
-sidebar:
- collapsed: true
----
diff --git a/content/docs/intro/what-are-passkeys.md b/content/docs/intro/what-are-passkeys.md
deleted file mode 100644
index 3b839280..00000000
--- a/content/docs/intro/what-are-passkeys.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: "What are passkeys?"
-description: "Passkeys are a replacement for passwords. A password is something that can be remembered and typed, and a passkey is a secret stored on one’s devices, unlocked with biometrics."
-lead: "Passkeys are a replacement for passwords. A password is something that can be remembered and typed, and a passkey is a secret stored on one’s devices, unlocked with biometrics."
-date: 2022-09-24T16:02:27.390Z
-draft: false
-images: []
-menu:
- docs:
- parent: "intro"
-weight: 102
-toc: true
----
-
-Passkeys are:
-
-**Intuitive** Creating and using passkeys is as simple as consenting to save and use them. No having to create a password.
-
-**Automatically unique per-service** By design, passkeys are unique per-service. There’s no chance to reuse them.
-
-**Breach-resistant** A passkey is only stored on a user’s devices. [Relying Party (RP)](/docs/reference/terms/#relying-party-rp) servers store public keys. Even servers that assist in the syncing of passkeys across a user’s devices never have the ability to view or use the private keys for a user's passkeys.
-
-**Phishing-resistant** Rather than trust being rooted in a human who has to verify they’re signing into the right website or app, browser, and operating systems enforce that passkeys are only ever used for the appropriate service.
-
-
-
-> The guidance on this site is currently targeted towards sites and services that are using either password only or password + OTP (SMS, app TOTP, app push, magic link) sign in flows. Future guidance will include more advanced and higher assurance scenarios.
diff --git a/content/docs/reference/_index.md b/content/docs/reference/_index.md
deleted file mode 100644
index 5d78af68..00000000
--- a/content/docs/reference/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Reference"
-description: ""
-lead: ""
-date: 2020-10-06T08:49:15+00:00
-draft: false
-images: []
-weight: 1000
-sidebar:
- collapsed: true
----
diff --git a/content/docs/reference/chromeos.md b/content/docs/reference/chromeos.md
deleted file mode 100644
index 8e59b8bc..00000000
--- a/content/docs/reference/chromeos.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: "Chrome OS"
-description: "Resources for passkeys in Google's Chrome OS"
-lead: "Resources for passkeys in Google's Chrome OS"
-date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1002
-toc: true
----
-
-{{% ds-cda %}}
-
-## Overview
-
-Creation of passkeys in Chrome OS is not currently supported.
-
-Passkeys from Android, iOS, and iPadOS can be used to sign in to web services on Chrome OS using [FIDO Cross-Device Authentication](../terms#cross-device-authentication-cda).
-
-## Platform Notes
-
-> Coming Soon
-
-## Resources
-
-> Coming Soon
diff --git a/content/docs/tools-libraries/_index.md b/content/docs/tools-libraries/_index.md
deleted file mode 100644
index ed744f4d..00000000
--- a/content/docs/tools-libraries/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Tools & Libraries"
-description: "Tools and libraries for FIDO2, WebAuthn, and passkeys"
-lead: "Tools and libraries for FIDO2, WebAuthn, and passkeys"
-date: 2022-09-24T15:57:34.857Z
-draft: false
-images: []
-weight: 700
-sidebar:
- collapsed: true
----
diff --git a/content/docs/use-cases/_index.md b/content/docs/use-cases/_index.md
deleted file mode 100644
index 33664237..00000000
--- a/content/docs/use-cases/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title : "Use Cases"
-description: "Implement passkeys"
-lead: ""
-date: 2022-09-28T18:53:38.996Z
-draft: false
-images: []
-weight: 300
-sidebar:
- collapsed: true
----
diff --git a/content/en/_index.md b/content/en/_index.md
new file mode 100644
index 00000000..0cdb62af
--- /dev/null
+++ b/content/en/_index.md
@@ -0,0 +1,10 @@
+---
+title: passkeys
+description: Hello passkeys! Goodbye passwords.
+actions:
+ getstarted:
+ url: "docs/intro/what-are-passkeys/"
+ title: "Get Started"
+ icon: "fas book-open"
+ weight: 1
+---
\ No newline at end of file
diff --git a/content/en/about/_index.md b/content/en/about/_index.md
new file mode 100644
index 00000000..02b5877d
--- /dev/null
+++ b/content/en/about/_index.md
@@ -0,0 +1,82 @@
+---
+title: About passkeys.dev
+description: A chronological overview of key releases since the initial launch of Hinode.
+layout: minimal
+type: minimal
+---
+
+passkeys.dev is brought to you by members of the [W3C WebAuthn Community Adoption Group](https://www.w3.org/community/webauthn-adoption/) and the [FIDO Alliance](https://fidoalliance.org/).
+
+## Engage and Contribute
+
+{{< card-group padding="3" gutter="3" wrapper="mt-4 mb-4" cols="2">}}
+ {{< card title="Ask & Discuss" icon="fa fa-comments" >}}
+
+- [W3C WebAuthn Community Adoption Group](https://www.w3.org/community/webauthn-adoption/)
+- [Passkeys Developer Discussions (passkeys.dev/discuss)](https://github.com/orgs/passkeydeveloper/discussions)
+ {{< /card >}}
+ {{< card title="Github" icon="fab github" >}}
+- [Suggest content or report a site issue](https://github.com/passkeydeveloper/passkeys.dev/issues/new/choose)
+ {{< /card >}}
+ {{< card title="Bluesky" icon="fab bluesky" >}}
+- [Passkeys Developer](https://fosstodon.org/@passkeysdev)
+ {{< /card >}}
+ {{< card title="Mastodon" icon="fab mastodon" >}}
+- [Passkeys Developer](https://fosstodon.org/@passkeysdev)
+- [W3C Developer](https://w3c.social/@w3cdevs)
+ {{< /card >}}
+{{< /card-group >}}
+
+Contributing guidance coming soon!
+
+## Maintainers
+
+Tim Cappalli
+[{{< fab fa-github >}}](https://github.com/timcappalli)
+[{{< fab fa-mastodon >}}](https://infosec.exchange/@timcappalli)
+[{{< fas fa-at >}}](https://www.threads.net/@timcappalli)
+[{{< fas fa-house >}}](https://timcappalli.me/)
+
+Matthew Miller
+[{{< fab fa-github >}}](https://github.com/MasterKale)
+[{{< fab fa-mastodon >}}](https://infosec.exchange/@iamkale)
+[{{< fas fa-house >}}](https://millerti.me/)
+
+## Contributors
+
+- Anders Åberg
+- Dirk Balfanz
+- Arnar Birgisson
+- Christiaan Brand
+- Garrett Davidson
+- Jesse Endahl
+- Eiji Kitamura [{{< fab github >}}](https://github.com/agektmr)
+- Akshay Kumar
+- Dominique Hazael-Massieux [{{< fab github >}}](https://github.com/dontcallmedom)
+- Jeff Hodges
+- Adam Langley
+- Ricky Mondello
+- Maud Nalpas [{{< fab github >}}](https://github.com/maudnals)
+- Cody Salas
+
+## Copyright and Attributions
+
+Unless otherwise indicated, passkeys.dev content is licensed under a [Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License](https://creativecommons.org/licenses/by-nc-nd/4.0/). Additional Terms: You may only link to this content. Copying, distributing, or modifying the content is not permitted.
+
+Code samples are in the [public domain CC0](https://creativecommons.org/publicdomain/zero/1.0/). No licensing notice is necessary but if you need one, you can use: `Any copyright is dedicated to the Public Domain: https://creativecommons.org/publicdomain/zero/1.0/`.
+
+### Other Attributions
+
+**passkeys.dev is powered by [Hinode](https://gethinode.com/) and [Hugo](https://gohugo.io/).**
+
+AirDrop, Apple, iPadOS, iCloud Keychain, iPhone, MacBook, and macOS are trademarks of Apple Inc., registered in the U.S. and other countries and regions.
+
+Android and ChromeOS are trademarks of Google LLC.
+
+Ubuntu is a trademark of Canonical Limited and is used under license.
+
+Windows is a registered trademark of Microsoft Corporation in the United States and/or other countries.
+
+The passkey icon is a trademark of FIDO Alliance, Inc.
+
+FIDO® is a trademark (registered in numerous countries) of FIDO Alliance, Inc.
diff --git a/content/en/device-support/_index.md b/content/en/device-support/_index.md
new file mode 100644
index 00000000..4f64456d
--- /dev/null
+++ b/content/en/device-support/_index.md
@@ -0,0 +1,724 @@
+---
+title: "Device Support"
+description: "Detailed information about passkey support across devices and ecosystems"
+layout: full-page
+type: misc
+---
+
+This page, along with the rest of passkeys.dev, is targeted at relying party developers and is not intended to be an end user facing resource.
+
+> Said differently, **please don’t link to this page from end user focused resources** 😉
+
+## Overview
+
+Support for passkeys is currently rolling out across major operating systems and browsers. This page will be updated as the ecosystem evolves. The [matrix below](#matrix) maps out the various features that support the passkey experience. Additional information about each platform is available in the [Reference section of Docs](/docs/reference/android).
+
+Passkeys created in **iOS or iPadOS** can be used on:
+
+- The same iPhone or iPad
+- iPhones and iPads using the same Apple ID (synced automatically)
+- Macs using the same Apple ID (synced automatically)
+- Macs using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Windows devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Chromebooks and other ChromeOS devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Ubuntu devices in Edge and Chrome using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+
+Passkeys created in **Android** can be used on:
+
+- The same Android device
+- Android devices using the same Google account (synced automatically)
+- Macs using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Windows devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- iPhones and iPads using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Chromebooks and other ChromeOS devices using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+- Ubuntu devices in Edge and Chrome using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda)
+
+Passkeys created in **macOS** can be used on:
+
+- Macs using the same Apple ID (synced automatically)
+- iPhones and iPads using the same Apple ID (synced automatically)
+ - Passkeys created on a Mac and synced to an iPhone and/or iPad via iCloud Keychain can be used in all the places listed above under "iOS or iPadOS"
+
+[Device-bound passkeys](/docs/reference/terms/#device-bound-passkey) created in **Windows** can be used on:
+
+- the same Windows device that created them
+
+## Matrix {#matrix}
+
+{{< button color="dark" href="https://featuredetect.passkeys.dev" size="md" >}}Test this client!{{< /button >}}
+
+### Basic Capabilities {#basics}
+
+{{< unsafe >}}
+
+
+
+{{< /unsafe >}}
diff --git a/content/en/discussions.md b/content/en/discussions.md
new file mode 100644
index 00000000..8a6fcc33
--- /dev/null
+++ b/content/en/discussions.md
@@ -0,0 +1,3 @@
+---
+redirect: "https://github.com/orgs/passkeydeveloper/discussions"
+---
\ No newline at end of file
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
new file mode 100644
index 00000000..d5797773
--- /dev/null
+++ b/content/en/docs/_index.md
@@ -0,0 +1,7 @@
+---
+title: Docs
+redirect: "/docs/"
+_build:
+ list: false
+ render: false
+---
\ No newline at end of file
diff --git a/content/docs/advanced/related-origins/index.md b/content/en/docs/advanced/related-origins/index.md
similarity index 81%
rename from content/docs/advanced/related-origins/index.md
rename to content/en/docs/advanced/related-origins/index.md
index 2f3c1bfd..2ea7cf8e 100644
--- a/content/docs/advanced/related-origins/index.md
+++ b/content/en/docs/advanced/related-origins/index.md
@@ -1,15 +1,8 @@
---
title: "Related Origin Requests"
description: "The Related Origin Requests (ROR) feature allows an RP to enable a passkey to be created and used across a limited set of related origins."
-lead: "The Related Origin Requests (ROR) feature allows an RP to enable a passkey to be created and used across a limited set of related origins."
date: 2024-08-22T15:20:51.937Z
-draft: false
-images: []
-menu:
- docs:
- parent: "advanced"
-weight: 510
-toc: true
+layouts: docs
---
## Use Cases
@@ -18,9 +11,10 @@ The two use cases for Related Origin Requests (ROR) are deployments which use di
To address these use cases, it is recommended to leverage industry-standard federation protocols such as [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html). This approach facilitates a centralized login experience, by using a dedicated login page (e.g., login.example.com) that serves as the authentication point for all origins and services.
-ROR is designed to be used when federation is not possible.
+**ROR is designed to be used when federation is _not_ possible.**
-{{< callout context="note" title="Websites vs Apps" icon="outline/note" >}} ROR is a WebAuthn feature for the web. App platforms have existing mechanisms for mapping native apps to one or more web origins: [Digital Asset Links](https://developers.google.com/identity/credential-sharing/set-up) for Android and [Associated Domains](https://developer.apple.com/documentation/xcode/supporting-associated-domains) on Apple platforms. {{< /callout >}}
+> [!NOTE]
+> ROR is a WebAuthn feature for the web. App platforms have existing mechanisms for mapping native apps to one or more web origins: [Digital Asset Links](https://developers.google.com/identity/credential-sharing/set-up) for Android and [Associated Domains](https://developer.apple.com/documentation/xcode/supporting-associated-domains) on Apple platforms.
### Country Code Top Level Domains (ccTLDs) {#cctld}
@@ -42,10 +36,10 @@ If there are 30 origins in the list, all with the same label, these count as 1 u
Below are three examples of origin lists and their respective label counts.
-{{< tabs "label-examples" >}}
-{{< tab "1 Label" >}}
+{{< nav type="pills" id="pills-1" >}}
+ {{< nav-item header="1 Label" show="true" >}}
-1. `shopping`
+ 1. `shopping`
```json
{
@@ -62,43 +56,43 @@ Below are three examples of origin lists and their respective label counts.
}
```
-{{< /tab >}}
-{{< tab "3 Labels" >}}
-
-1. `shopping`
-1. `myshoppingrewards`
-1. `myshoppingtravel`
-
-```json
-{
- "origins": [
- "https://shopping.com",
- "https://shopping.co.uk",
- "https://shopping.co.jp",
- "https://shopping.ie",
- "https://shopping.ca",
- "https://myshoppingrewards.com",
- "https://myshoppingrewards.co.uk",
- "https://myshoppingrewards.co.jp",
- "https://myshoppingrewards.ie",
- "https://myshoppingrewards.ca",
- "https://myshoppingtravel.com",
- "https://myshoppingtravel.co.uk",
- "https://myshoppingtravel.co.jp",
- "https://myshoppingtravel.ie",
- "https://myshoppingtravel.ca"
- ]
-}
-```
-
-{{< /tab >}}
-{{< tab "5 Labels" >}}
-
-1. `shopping`
-1. `myshoppingcard`
-1. `myshoppingrewards`
-1. `myshoppingcreditcard`
-1. `myshoppingtravel`
+ {{< /nav-item >}}
+ {{< nav-item header="3 Labels" >}}
+
+ 1. `shopping`
+ 1. `myshoppingrewards`
+ 1. `myshoppingtravel`
+
+ ```json
+ {
+ "origins": [
+ "https://shopping.com",
+ "https://shopping.co.uk",
+ "https://shopping.co.jp",
+ "https://shopping.ie",
+ "https://shopping.ca",
+ "https://myshoppingrewards.com",
+ "https://myshoppingrewards.co.uk",
+ "https://myshoppingrewards.co.jp",
+ "https://myshoppingrewards.ie",
+ "https://myshoppingrewards.ca",
+ "https://myshoppingtravel.com",
+ "https://myshoppingtravel.co.uk",
+ "https://myshoppingtravel.co.jp",
+ "https://myshoppingtravel.ie",
+ "https://myshoppingtravel.ca"
+ ]
+ }
+ ```
+
+ {{< /nav-item >}}
+ {{< nav-item header="5 Labels" >}}
+
+ 1. `shopping`
+ 1. `myshoppingcard`
+ 1. `myshoppingrewards`
+ 1. `myshoppingcreditcard`
+ 1. `myshoppingtravel`
```json
{
@@ -127,8 +121,8 @@ Below are three examples of origin lists and their respective label counts.
}
```
-{{< /tab >}}
-{{< /tabs >}}
+ {{< /nav-item >}}
+{{< /nav >}}
## Requirements
@@ -152,7 +146,10 @@ The JSON document must have a member named `origins`, containing an array of val
Below is an example for the RP ID `shopping.com`.
-```json {title="https://shopping.com/.well-known/webauthn"}
+{{< nav type="tabs" id="tabs-1" >}}
+ {{< nav-item header="https://shopping.com/.well-known/webauthn" show="true" >}}
+
+```json
{
"origins": [
"https://shopping.com",
@@ -167,6 +164,9 @@ Below is an example for the RP ID `shopping.com`.
}
```
+ {{< /nav-item >}}
+{{< /nav >}}
+
## Deployment Considerations
### Greenfield Deployments
@@ -179,12 +179,12 @@ It is recommended to pick the most commonly used and/or understood domain for th
For deployments where passkeys are already rolled out with multiple RP IDs, there are some unique considerations and requirements.
-__Considerations__
+#### Considerations
- Users with a passkey for the "local" RP ID / origin will be able to use all passkeys experiences as normal.
- Users with a passkey for another RP ID / related origin, will require an identifier first flow and a backend lookup.
-__Requirements__
+#### Requirements
- Each existing RP ID will need to host the WebAuthn well-known document, with all of the other origins listed in it. This will allow reciprocal use of passkeys
- The account database will need to know which RP ID was used for each passkey (this could be an explicit property or inferred based on other data)
@@ -215,4 +215,4 @@ A user with a passkey for `shopping.co.uk` has traveled to the US and navigates
## Additional Information
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://w3c.github.io/webauthn/#sctn-related-origins" >}}WebAuthn Spec Reference{{< /button >}}
diff --git a/content/docs/demos-examples/demos.md b/content/en/docs/demos-examples/demos.md
similarity index 80%
rename from content/docs/demos-examples/demos.md
rename to content/en/docs/demos-examples/demos.md
index 529eaf48..9e11baa5 100644
--- a/content/docs/demos-examples/demos.md
+++ b/content/en/docs/demos-examples/demos.md
@@ -1,15 +1,8 @@
---
title: "Demo Sites & Services"
description: "Sites and services to demo passkeys"
-lead: "Sites and services to demo passkeys"
date: 2023-09-19T16:45:00.148Z
-draft: false
-images: []
-menu:
- docs:
- parent: "demos-examples"
-weight: 1120
-toc: true
+layout: docs
---
## General Passkey Demo Sites
diff --git a/content/en/docs/intro/what-are-passkeys.md b/content/en/docs/intro/what-are-passkeys.md
new file mode 100644
index 00000000..629e0ae3
--- /dev/null
+++ b/content/en/docs/intro/what-are-passkeys.md
@@ -0,0 +1,30 @@
+---
+title: "What are passkeys?"
+description: "Passkeys are a replacement for passwords. A password is something that can be remembered and typed, and a passkey is a secret stored on one’s devices, unlocked with biometrics."
+date: 2022-09-24T16:02:27.390Z
+layout: docs
+aliases:
+ - "/docs/intro/"
+ - "/docs/"
+---
+
+
+
+## Passkeys are:
+
+{{< card-group padding="3" gutter="3" cols="2" wrapper="mt-4 mb-5">}}
+ {{< card title="Intuitive" icon="fa-solid fa-wand-magic-sparkles" align="center">}}
+ Creating and using passkeys is as simple as consenting to save and use them. No having to create a password.
+ {{< /card >}}
+ {{< card title="Automatically unique" icon="fa-regular fa-snowflake" align="center">}}
+ By design, passkeys are unique per-service. There’s no chance to reuse them.
+ {{< /card >}}
+ {{< card title="Breach-resistant" icon="fa-solid fa-people-robbery" align="center">}}
+ A passkey is only stored on a user’s devices. [Relying Party (RP)](/docs/reference/terms/#relying-party-rp) servers store public keys. Even servers that assist in the syncing of passkeys across a user’s devices never have the ability to view or use the private keys for a user's passkeys.
+ {{< /card >}}
+ {{< card title="Phishing-resistant" icon="fa-solid fa-user-shield" align="center">}}
+ Rather than trust being rooted in a human who has to verify they’re signing into the right website or app, browser, and operating systems enforce that passkeys are only ever used for the appropriate service.
+ {{< /card >}}
+{{< /card-group >}}
+
+> The guidance on this site is currently targeted towards sites and services that are using either password only or password + OTP (SMS, app TOTP, app push, magic link) sign in flows. Future guidance will include more advanced and higher assurance scenarios.
diff --git a/content/docs/reference/android.md b/content/en/docs/reference/android.md
similarity index 74%
rename from content/docs/reference/android.md
rename to content/en/docs/reference/android.md
index 47d420db..566d64f9 100644
--- a/content/docs/reference/android.md
+++ b/content/en/docs/reference/android.md
@@ -2,34 +2,36 @@
title: "Android"
description: "Resources for passkeys in Android"
date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1001
-toc: true
+type: docs
+layout: docs
---
-{{% ds-full %}}
+{{< card-group padding="3" gutter="3" cols="2">}}
+ {{< card title="Local Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from the local device)
+ {{< /card >}}
+ {{< card title="External Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from another device)
+ {{< /card >}}
+{{< /card-group >}}
## Overview
The platform authenticator in Android 9+ has the following capabilities:
- creating and using passkeys that are backed up to Google Password Manager
-- using a passkey from the local Android device to sign into services on another device (such as a laptop or desktop), using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
+- using a passkey from the local Android device to sign into services on another device (such as a laptop or desktop), using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
Android 14 adds the following capabilities:
-- creating and using passkeys in a [third-party passkey provider](../terms/#third-party-passkey-provider)
+- creating and using passkeys in a [third-party passkey provider](/terms/#third-party-passkey-provider)
- NOTE: some Android devices from a small number of OEMs do not support third party passkey providers in Android 14
## Platform Notes
### Cross-Device Authentication
-Android devices can be an [authenticator](../terms/#cda-authenticator) for [FIDO Cross-Device Authentication (CDA)](../terms#cross-device-authentication-cda).
+Android devices can be an [authenticator](/terms/#cda-authenticator) for [FIDO Cross-Device Authentication (CDA)](/terms#cross-device-authentication-cda).
Android devices can be persistently linked to the browsers/platforms below:
@@ -48,7 +50,9 @@ When an authenticator is not persistently linked, a QR code must be scanned on e
### Native APIs
-- **Credential Manager** is a new Android Jetpack API that supports multiple sign-in methods, including passkeys, in a single API, thus simplifying the integration for developers.
+- **Credential Manager** is a new Android Jetpack API that supports multiple sign-in methods, including passkeys, in a single API, thus simplifying the integration for developers.
+
+ {{< button color="light" size="sm" icon="fab fa-android" cue=false order="first" tooltip="Go to the Android developer docs" href="https://developer.android.com/training/sign-in/passkeys" >}}Credential Manager API{{< /button >}}
### WebViews
@@ -58,16 +62,17 @@ When an authenticator is not persistently linked, a QR code must be scanned on e
WebAuthn is currently not directly supported in embedded WebViews on Android, but adding additional code can allow you to break out of the EWV to call the platform's Credential Manager APIs.
-This is documented at [Android Developer: "Integrate Credential Manager with WebView {{< icon-external-link size=20 >}}](https://developer.android.com/training/sign-in/credential-manager-webview).
+This is documented at [Android Developer: "Integrate Credential Manager with WebView](https://developer.android.com/training/sign-in/credential-manager-webview).
-> **NOTE:**
+> **NOTE:**
+>
> Embedded WebViews run in the context of the calling app, meaning only passkeys for the linked web domain (RP ID) can be created or used for sign in.
>
> Said differently, only use EWV when sign in is handled by your own service (non-federated). When supporting multiple identity providers, System WebView should be used (see below).
-
+{{< button color="light" size="sm" icon="fab fa-android" cue=false order="first" tooltip="Go to the Android developer docs" href="https://developer.android.com/develop/ui/views/layout/webapps/webview" >}}WebView docs @ Android Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
#### System WebViews (SWV)
@@ -75,9 +80,9 @@ This is documented at [Android Developer: "Integrate Credential Manager with Web
Sites loaded in `Custom Tabs` are isolated from the calling app and run in the context of the top level site, just like in a full browser. This means that sign in flows on third party domains, such as a federated identity provider, can use passkeys for signing in.
-
+{{< button color="light" size="sm" icon="fab fa-android" cue=false order="first" tooltip="Go to the Android developer docs" href="https://developer.chrome.com/docs/android/custom-tabs/guide-get-started" >}}Custom Tabs docs @ Android Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
### User Verification Behavior
diff --git a/content/en/docs/reference/chromeos.md b/content/en/docs/reference/chromeos.md
new file mode 100644
index 00000000..3d4fbb53
--- /dev/null
+++ b/content/en/docs/reference/chromeos.md
@@ -0,0 +1,30 @@
+---
+title: "Chrome OS"
+description: "Resources for passkeys in Google's Chrome OS"
+date: 2022-09-03T16:09:38.358Z
+type: docs
+layout: docs
+---
+
+{{< card-group padding="3" gutter="3" cols="2">}}
+ {{< card title="Local Authenticator" align="center" color="body" icon="fa fa-calendar-plus fa-2xl" style="text-warning">}}
+ (create and use passkeys from the local device)
+ {{< /card >}}
+ {{< card title="External Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from another device)
+ {{< /card >}}
+{{< /card-group >}}
+
+## Overview
+
+Creation of passkeys in Chrome OS is not currently supported.
+
+Passkeys from Android, iOS, and iPadOS can be used to sign in to web services on Chrome OS using [FIDO Cross-Device Authentication](/terms#cross-device-authentication-cda).
+
+## Platform Notes
+
+> Coming Soon
+
+## Resources
+
+> Coming Soon
diff --git a/content/docs/reference/ios.md b/content/en/docs/reference/ios.md
similarity index 70%
rename from content/docs/reference/ios.md
rename to content/en/docs/reference/ios.md
index d080e1bd..05fe3d72 100644
--- a/content/docs/reference/ios.md
+++ b/content/en/docs/reference/ios.md
@@ -2,16 +2,18 @@
title: "iOS & iPadOS"
description: "Resources for passkeys in Apple's iOS and iPadOS"
date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1003
-toc: true
+type: docs
+layout: docs
---
-{{% ds-full %}}
+{{< card-group padding="3" gutter="3" cols="2">}}
+ {{< card title="Local Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from the local device)
+ {{< /card >}}
+ {{< card title="External Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from another device)
+ {{< /card >}}
+{{< /card-group >}}
## Overview
@@ -19,18 +21,22 @@ The platform authenticators in iOS 16+ and iPadOS 16+ have the following capabil
- creating and using passkeys that are backed up to iCloud Keychain
- creating and using passkeys on/from another device, such as:
- - an iPhone or iPad signed in to a different iCloud account, using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
- - an Android phone or tablet, using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
- - a FIDO2 security key1
-- using a passkey from the local iOS or iPadOS device to sign into services on another device (such as a laptop or desktop), using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
+ - an iPhone or iPad signed in to a different iCloud account, using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
+ - an Android phone or tablet, using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
+ - a FIDO2 security key{{< sup 1 >}}
+- using a passkey from the local iOS or iPadOS device to sign into services on another device (such as a laptop or desktop), using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
-
1 On iOS and iPadOS, user verification methods (device PIN, biometric, etc) must already be configured on the security key prior to credential creation
+{{< unsafe >}}
+
+
{{< sup 1 >}} On iOS and iPadOS, user verification methods (device PIN, biometric, etc) must already be configured on the security key prior to credential creation
+
+{{< /unsafe >}}
## Platform Notes
### Cross-Device Authentication
-iOS and iPadOS support both [client](../terms/#cda-client) and [authenticator](../terms/#cda-client) roles for [Cross-Device Authentication (CDA)](../terms#cross-device-authentication-cda).
+iOS and iPadOS support both [client](/terms/#cda-client) and [authenticator](/terms/#cda-client) roles for [Cross-Device Authentication (CDA)](/terms#cross-device-authentication-cda).
iOS and iPadOS devices (as authenticators) do not support persistent linking for Cross-Device Authentication. When an authenticator is not persistently linked, a QR code must be scanned on every use.
@@ -38,7 +44,7 @@ iOS and iPadOS devices (as authenticators) do not support persistent linking for
WebAuthn credentials created using the platform authenticator in iOS/iPadOS 15 and earlier ***will not*** not be converted to passkeys but will remain available for the lifetime of the device.
-
+{{% comment %}} TODO: cross link to generic content about "upgrading to a passkey" {{% /comment %}}
To replace a legacy platform credential with a passkey, start a credential registration ceremony and pass **the same user handle** (user.id) in the request. iOS/iPadOS will overwrite the legacy credential with a new passkey that will be backed up to iCloud Keychain.
### WebViews
@@ -47,14 +53,15 @@ To replace a legacy platform credential with a passkey, start a credential regis
`WKWebView` is the embedded WebView (EWV) on iOS and iPadOS. Embedded WebViews allow the calling app full control over the embedded web session, including modifying and intercepting requests, so many web platform features are limited in these contexts.
-> **NOTE:**
+> **NOTE:**
+>
> Embedded WebViews run in the context of the calling app, meaning only passkeys for the linked web domain (RP ID) can be created or used for sign in.
>
> Said differently, only use EWV when sign in is handled by your own service (non-federated). When supporting multiple identity providers, System WebView should be used (see below).
-
+{{< button color="light" size="sm" icon="fab fa-apple" cue=false order="first" tooltip="Go to the Apple developer docs" href="https://developer.apple.com/documentation/webkit/wkwebview" >}}WKWebView docs @ Apple Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
#### System WebViews
@@ -62,9 +69,9 @@ To replace a legacy platform credential with a passkey, start a credential regis
Sites loaded in `ASWebAuthenticationSession` are isolated from the calling app and run in the context of the top level site, just like in a full browser. This means that sign in flows on third party domains, such as a federated identity provider, can use passkeys for signing in.
-
+{{< button color="light" size="sm" icon="fab fa-apple" cue=false order="first" tooltip="Go to the Apple developer docs" href="https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession" >}}ASWebAuthenticationSession docs @ Apple Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
### User Verification Behavior
diff --git a/content/docs/reference/known-issues.md b/content/en/docs/reference/known-issues.md
similarity index 94%
rename from content/docs/reference/known-issues.md
rename to content/en/docs/reference/known-issues.md
index 27c2760d..0f1122e1 100644
--- a/content/docs/reference/known-issues.md
+++ b/content/en/docs/reference/known-issues.md
@@ -2,25 +2,21 @@
title: "Known Issues"
description: "A list of known issues with passkey implementations"
date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1101
toc: false
-layout: matrix
+type: docs
+layout: docs
---
## Passkey Metadata
### Samsung Pass
-According to Samsung documentation ([source](https://www.samsung.com/us/apps/samsung-pass/)), Samsung Pass creates [synced passkeys](../terms#synced-passkey) which are available on other devices where Samsung Pass is installed.
+According to Samsung documentation ([source](https://www.samsung.com/us/apps/samsung-pass/)), Samsung Pass creates [synced passkeys](terms#synced-passkey) which are available on other devices where Samsung Pass is installed.
-During testing on 2024-09-05, it was observed that passkeys created in Samsung Pass return the backup eligible flag as false, signaling a [device-bound passkey](../terms#device-bound-passkey).
+During testing on 2024-09-05, it was observed that passkeys created in Samsung Pass return the backup eligible flag as false, signaling a [device-bound passkey](terms#device-bound-passkey).
-{{< details "Sample passkey registration from Samsung Pass" >}}
+{{< accordion id="accordion-default" >}}
+ {{< accordion-item header="Sample passkey registration from Samsung Pass" show="false" >}}
Test device details:
- Galaxy S22
@@ -54,11 +50,15 @@ Test device details:
"authenticatorAttachment": "platform"
}
```
-{{< /details >}}
+
+ {{< /accordion-item >}}
+{{< /accordion >}}
## User Verification
-The following list of passkey providers have not implemented [User Verification](../terms#user-verification-uv) in a spec-compliant manner.
+The following list of passkey providers have not implemented [User Verification](terms#user-verification-uv) in a spec-compliant manner.
+
+{{< table >}}
| **Provider** | **Architecture** | **UV Required Behavior** | **UV Flag** |
| ------------ | ---------------- | ----------------------------- | ------------------------ |
@@ -69,5 +69,6 @@ The following list of passkey providers have not implemented [User Verification]
| Proton Pass | Extension | ❌ Handles request without UV | ❌ Always replies `True` |
| Proton Pass | Native | ❌ Handles request without UV | ❌ Always replies `True` |
| Strongbox | Native | ❌ Handles request without UV | ❌ Always replies `True` |
+{{< /table >}}
> **Architecture**: `Extension` = web browser extension, `Native` = OS native app using provider APIs
diff --git a/content/docs/reference/macos.md b/content/en/docs/reference/macos.md
similarity index 77%
rename from content/docs/reference/macos.md
rename to content/en/docs/reference/macos.md
index 96ac4a5a..52ce4b47 100644
--- a/content/docs/reference/macos.md
+++ b/content/en/docs/reference/macos.md
@@ -2,16 +2,18 @@
title: "macOS"
description: "Resources for passkeys in Apple macOS"
date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1004
-toc: true
+type: docs
+layout: docs
---
-{{% ds-full %}}
+{{< card-group padding="3" gutter="3" cols="2">}}
+ {{< card title="Local Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from the local device)
+ {{< /card >}}
+ {{< card title="External Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from another device)
+ {{< /card >}}
+{{< /card-group >}}
## Overview
@@ -19,17 +21,21 @@ The platform authenticator in macOS Ventura (13) has the following capabilities:
- creating and using passkeys that are backed up to iCloud Keychain
- creating and using passkeys on/from another device, such as:
- - an iPhone or iPad signed in to a different iCloud account, using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
- - an Android device, using FIDO [Cross-Device Authentication](../terms#cross-device-authentication-cda)
- - a FIDO2 security key1
+ - an iPhone or iPad signed in to a different iCloud account, using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
+ - an Android device, using FIDO [Cross-Device Authentication](/terms#cross-device-authentication-cda)
+ - a FIDO2 security key{{< sup 1 >}}
-
1 On macOS, user verification methods (device PIN, biometric, etc) must already be configured on the security key prior to credential creation
+{{< unsafe >}}
+
+
{{< sup 1 >}} On macOS, user verification methods (device PIN, biometric, etc) must already be configured on the security key prior to credential creation
+
+{{< /unsafe >}}
## Platform Notes
### Cross-Device Authentication
-macOS does not currently support persistent linking of external authenticators for [Cross-Device Authentication](../terms#cross-device-authentication-cda) at the operating system level.
+macOS does not currently support persistent linking of external authenticators for [Cross-Device Authentication](/terms#cross-device-authentication-cda) at the operating system level.
Persistent linking is available between Android devices (authenticator) and Chrome and Edge (clients) on macOS.
@@ -39,12 +45,12 @@ When an authenticator is not persistently linked, a QR code must be scanned on e
WebAuthn credentials created using the platform authenticator in macOS Monterey (12) and earlier ***will not*** be converted to passkeys but will remain available for the lifetime of the device.
-
+{{% comment %}} TODO: cross link to generic content about "upgrading to a passkey" {{% /comment %}}
To replace a legacy platform credential with a passkey, start a credential registration ceremony and pass **the same user handle** (user.id) in the request. macOS will overwrite the legacy credential with a new passkey that will be backed up to iCloud Keychain.
### Browser Behavior
-**Edge**: credentials created by Edge are currently [***device-bound*** passkeys](/docs/reference/terms/#device-bound-passkey), are not backed up to iCloud Keychain, and are ***not available outside of Edge***.
+**Edge**: credentials created by Edge are currently [***device-bound*** passkeys](/terms/#device-bound-passkey), are not backed up to iCloud Keychain, and are ***not available outside of Edge***.
### WebViews
@@ -52,14 +58,15 @@ To replace a legacy platform credential with a passkey, start a credential regis
`WKWebView` is the embedded WebView (EWV) on macOS. Embedded WebViews allow the calling app full control over the embedded web session, including modifying and intercepting requests, so many web platform features are limited in these contexts.
-> **NOTE:**
+> **NOTE:**
+>
> Embedded WebViews run in the context of the calling app, meaning only passkeys for the linked web domain (RP ID) can be created or used for sign in.
>
> Said differently, only use EWV when sign in is handled by your own service (non-federated). When supporting multiple identity providers, System WebView should be used (see below).
-
+{{< button color="light" size="sm" icon="fab fa-apple" cue=false order="first" tooltip="Go to the Apple developer docs" href="https://developer.apple.com/documentation/webkit/wkwebview" >}}WKWebView docs @ Apple Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
#### System WebViews
@@ -67,9 +74,9 @@ To replace a legacy platform credential with a passkey, start a credential regis
Sites loaded in `ASWebAuthenticationSession` are isolated from the calling app and run in the context of the top level site, just like in a full browser instance. This means that sign in flows on third party domains, such as a federated identity provider, can use passkeys for signing in.
-
+{{< button color="light" size="sm" icon="fab fa-apple" cue=false order="first" tooltip="Go to the Apple developer docs" href="https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession" >}}ASWebAuthenticationSession docs @ Apple Developer{{< /button >}}
-
+{{% comment %}} TODO: add screenshot example {{% /comment %}}
### User Verification Behavior
diff --git a/content/docs/reference/specs.md b/content/en/docs/reference/specs.md
similarity index 95%
rename from content/docs/reference/specs.md
rename to content/en/docs/reference/specs.md
index f13b3fdb..ea582a19 100644
--- a/content/docs/reference/specs.md
+++ b/content/en/docs/reference/specs.md
@@ -1,15 +1,9 @@
---
title: "Specifications"
description: "List of specifications that enable passkeys"
-lead: ""
date: 2022-08-04T17:33:14.682Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1111
-toc: true
+layout: docs
+
---
The two primary technical specifications that work together to enable passkeys are Web Authentication, commonly referred to as WebAuthn, and the Client to Authenticator Protocol (CTAP), commonly referred to as FIDO2.
diff --git a/content/docs/reference/terms/index.md b/content/en/docs/reference/terms/index.md
similarity index 75%
rename from content/docs/reference/terms/index.md
rename to content/en/docs/reference/terms/index.md
index b9cb9e40..5cde46e0 100644
--- a/content/docs/reference/terms/index.md
+++ b/content/en/docs/reference/terms/index.md
@@ -1,15 +1,8 @@
---
title: "Terms"
description: "A list of terms which are used frequently throughout this site and in discussions about passkeys, FIDO2, and WebAuthn."
-lead: "Here's a list of terms which are used frequently throughout this site and in discussions about passkeys, FIDO2, and WebAuthn."
date: 2020-11-12T13:26:54+01:00
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1110
-toc: true
+layout: docs
---
## 2FA user
@@ -32,7 +25,7 @@ A [Relying Party (RP)](#relying-party-rp) authenticates a user without any prior
Attestation is an optional statement provided by an authenticator which can be used by a Relying Party to identify and verify the provenance of the authenticator.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-attestation" >}}WebAuthn Spec Reference{{< /button >}}
## Authentication factor
@@ -44,15 +37,15 @@ A privacy preserving list UI element that is rendered by the browser (or the OS
This UI element provides a list of passkeys that are available for the [Relying Party (RP)](#relying-party-rp) on the local device, and may also provide an option to kick off [Cross-Device Authentication (CDA)](#cross-device-authentication-cda) or use a FIDO2 security key.
-A generic example of an autofill UI for passkeys is shown below:
-
-
+{{< image src="pkdd-signin-username-autofill.png" class="col-10 col-md-7" wrapper="text-center" caption="A generic example of an autofill UI for passkeys" title="Sample sign in screen with the autofill UI rendered under the username field, showing a passkey for bob@example.com, an other accounts option and a passkey from another device option">}}
The technical name for this feature in the WebAuthn and Credential Management specifications is "Conditional Mediation".
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://w3c.github.io/webauthn/#dom-publickeycredential-isconditionalmediationavailable" >}}WebAuthn Spec Reference{{< /button >}}
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the Credential Management specification" href="https://w3c.github.io/webappsec-credential-management/#mediation-requirements">}}
+ Credential Management Spec Reference
+{{< /button >}}
## Cross-Device Authentication (CDA)
@@ -86,7 +79,7 @@ A Discoverable Credential (known in previous version of WebAuthn as a "resident
[Passkeys](#passkey) are Discoverable Credentials.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#discoverable-credential" >}}WebAuthn Spec Reference{{< /button >}}
## First-Party Passkey Provider
@@ -128,15 +121,13 @@ The informal name for creating a relationship between a [Cross-Device Authentica
Both the client and authenticator must support the functionality.
-Example with an Android phone linked to a Windows 11 device:
-
-
+{{< image src="pkdd-terms-cda-pl-androidwin.png" class="col-10 col-md-7" wrapper="text-center" caption="Example with an Android phone linked to a Windows 11 device" title="A screenshot of the Windows Hello prompt asking the user to choose where to save their new passkey. The list of options includes an entry with a phone icon titled cappy-p7p as an example of a phone that has been persistently linked to the access device the user is current registering a new passkey from.">}}
## Platform authenticator
A FIDO authenticator that is built-in to a user's device.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#sctn-authenticator-taxonomy" >}}WebAuthn Spec Reference{{< /button >}}
## Reauthentication
@@ -148,13 +139,13 @@ For example, this can happen before making sensitive changes to an account (addi
The website that is trying to ascertain and verify the identity of the user or perform FIDO authentication.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#webauthn-relying-party" >}}WebAuthn Spec Reference{{< /button >}}
## Roaming authenticator
A FIDO authenticator usable with any device the user is trying to sign-in from. Roaming authenticators attach to users' devices in using USB, NFC, and/or Bluetooth. These authenticators are often referred to as "security keys". A smartphone can also act as a roaming authenticator using [FIDO Cross-Device Authentication](#cross-device-authentication-cda).
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#sctn-authenticator-taxonomy" >}}WebAuthn Spec Reference{{< /button >}}
## Signing in
@@ -178,16 +169,16 @@ A [Passkey Provider](#passkey-provider) that plugs in to the OS via platform API
A test of User Presence (UP) is used to ensure the user is in local proximity to the authenticator during an authentication or credential creation ceremony. UP is often satisfied by pressing a button or metallic area of a security key, or interacting with a platform authenticator on a device.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#test-of-user-presence" >}}WebAuthn Spec Reference{{< /button >}}
## User Verification (UV)
User Verification (UV) requires the user to either perform a biometric gesture, enter the device PIN, or enter the device password for the authenticator to authorize creation and/or use of the credential.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#user-verification" >}}WebAuthn Spec Reference{{< /button >}}
## User-Verifying Roaming Authenticator
A User-Verifying Roaming Authentication (UVRA), also known as a first-factor roaming authenticator, can [verify individual](#user-verification-uv) users through the use of biometrics, or through the user entering a device PIN. An important class of UVRAs are smartphones, in which case the “attachment” typically happens over a wireless connection.
-
+{{< button color="light" size="sm" icon="fas fa-circle-info" cue=false order="first" tooltip="Go to reference in the WebAuthn specification" href="https://www.w3.org/TR/webauthn-2/#first-factor-roaming-authenticator" >}}WebAuthn Spec Reference{{< /button >}}
diff --git a/content/docs/reference/terms/pkdd-signin-username-autofill.png b/content/en/docs/reference/terms/pkdd-signin-username-autofill.png
similarity index 100%
rename from content/docs/reference/terms/pkdd-signin-username-autofill.png
rename to content/en/docs/reference/terms/pkdd-signin-username-autofill.png
diff --git a/content/docs/reference/terms/pkdd-terms-cda-pl-androidwin.png b/content/en/docs/reference/terms/pkdd-terms-cda-pl-androidwin.png
similarity index 100%
rename from content/docs/reference/terms/pkdd-terms-cda-pl-androidwin.png
rename to content/en/docs/reference/terms/pkdd-terms-cda-pl-androidwin.png
diff --git a/content/docs/reference/windows.md b/content/en/docs/reference/windows.md
similarity index 59%
rename from content/docs/reference/windows.md
rename to content/en/docs/reference/windows.md
index 547a3f95..74fb904a 100644
--- a/content/docs/reference/windows.md
+++ b/content/en/docs/reference/windows.md
@@ -2,43 +2,45 @@
title: "Windows"
description: "Resources for passkeys in Microsoft Windows"
date: 2022-09-03T16:09:38.358Z
-draft: false
-images: []
-menu:
- docs:
- parent: "reference"
-weight: 1005
-toc: true
+type: docs
+layout: docs
---
-{{% ds-la_p-ea_s %}}
+{{< card-group padding="3" gutter="3" cols="2">}}
+ {{< card title="Local Authenticator" align="center" color="body" icon="fa fa-circle-check fa-2xl" style="text-warning">}}
+ (create and use passkeys from the local device)
+ {{< /card >}}
+ {{< card title="External Authenticator" align="center" color="body" icon="fas fa-circle-check fa-2xl" style="text-success">}}
+ (create and use passkeys from another device)
+ {{< /card >}}
+{{< /card-group >}}
## Overview
Windows Hello, the local platform authenticator in Windows 10 and 11, has the following capabilities:
-- creating and using [***device-bound*** passkeys](../terms#device-bound-passkey) on the local device
-- creating and using [***device-bound*** passkeys](../terms#device-bound-passkey) on a FIDO2 security key
+- creating and using [***device-bound*** passkeys](/terms#device-bound-passkey) on the local device
+- creating and using [***device-bound*** passkeys](/terms#device-bound-passkey) on a FIDO2 security key
The following is also possible in Windows 11 version 23H2 and newer:
-- using passkeys from iOS and iPadOS devices for signing into services in all browser and native apps using [FIDO Cross-Device Authentication](../terms#cross-device-authentication-cda)
-- using passkeys from Android devices for signing into services in all browser and native apps using [FIDO Cross-Device Authentication](../terms#cross-device-authentication-cda)
+- using passkeys from iOS and iPadOS devices for signing into services in all browser and native apps using [FIDO Cross-Device Authentication](/terms#cross-device-authentication-cda)
+- using passkeys from Android devices for signing into services in all browser and native apps using [FIDO Cross-Device Authentication](/terms#cross-device-authentication-cda)
The following is also possible in both Windows 10 and Windows 11 (earlier than 23H2):
-- using passkeys from iOS and iPadOS devices in Chrome (108+) and Edge (108+) for signing in to web services using [FIDO Cross-Device Authentication](../terms#cross-device-authentication-cda)
-- using passkeys from Android devices in Chrome (108+) and Edge (108+) for signing in to web services using [FIDO Cross-Device Authentication](../terms#cross-device-authentication-cda)
+- using passkeys from iOS and iPadOS devices in Chrome (108+) and Edge (108+) for signing in to web services using [FIDO Cross-Device Authentication](/terms#cross-device-authentication-cda)
+- using passkeys from Android devices in Chrome (108+) and Edge (108+) for signing in to web services using [FIDO Cross-Device Authentication](/terms#cross-device-authentication-cda)
## Platform Notes
-- The [authenticatorAttachment property of responses](https://w3c.github.io/webauthn/#dom-publickeycredential-authenticatorattachment), planned for specification delivery in WebAuthn L3, is not currently available in responses to `navigator.credentials.get` when using the platform authenticator or a hardware security key. It is supplied during credential creation, or when using [FIDO Cross-Device Authentication](/docs/reference/terms/#cross-device-authentication-cda) for an authentication ceremony.
+- The [authenticatorAttachment property of responses](https://w3c.github.io/webauthn/#dom-publickeycredential-authenticatorattachment), planned for specification delivery in WebAuthn L3, is not currently available in responses to `navigator.credentials.get` when using the platform authenticator or a hardware security key. It is supplied during credential creation, or when using [FIDO Cross-Device Authentication](/terms/#cross-device-authentication-cda) for an authentication ceremony.
### Cross-Device Authentication
-Starting in Windows 11 version 23H2, [FIDO Cross-Device Authentication (CDA)](../terms#cross-device-authentication-cda) is supported globally at the operating system level and available for all apps and browsers. Persistent linking is available between Android devices (authenticator) and Windows 11 23H2+. iOS and iPadOS do not support persistent linking.
+Starting in Windows 11 version 23H2, [FIDO Cross-Device Authentication (CDA)](/terms#cross-device-authentication-cda) is supported globally at the operating system level and available for all apps and browsers. Persistent linking is available between Android devices (authenticator) and Windows 11 23H2+. iOS and iPadOS do not support persistent linking.
-In Windows versions prior to 11 23H2, including Windows 10, support for [FIDO Cross-Device Authentication (CDA)](../terms#cross-device-authentication-cda) is only available in Chrome and Edge. It is not available globally. Persistent linking is available between Android devices (authenticator) and Chrome and Edge (clients) on these versions. iOS and iPadOS do not support persistent linking.
+In Windows versions prior to 11 23H2, including Windows 10, support for [FIDO Cross-Device Authentication (CDA)](/terms#cross-device-authentication-cda) is only available in Chrome and Edge. It is not available globally. Persistent linking is available between Android devices (authenticator) and Chrome and Edge (clients) on these versions. iOS and iPadOS do not support persistent linking.
### User Verification Behavior
@@ -46,7 +48,7 @@ When a user tries to interact with a passkey on Windows 11, an available screen
Where these biometrics are not configured or available, both passkey creation and authentication fall back to asking for the Windows Hello PIN.
-#### Chrome 120
+#### Chrome 120+
- When biometrics are not configured on Windows, or not available on the device:
- The behavior for both `userVerification='required'` and `userVerification='preferred'` are the same: Windows Hello asks for the device PIN for both passkey creation and authentication. Since user verification fails locally, the server only receives a successful response with the UV flag to be `true`.
diff --git a/content/docs/tools-libraries/libraries.md b/content/en/docs/tools-libraries/libraries.md
similarity index 98%
rename from content/docs/tools-libraries/libraries.md
rename to content/en/docs/tools-libraries/libraries.md
index b59589da..b6faa10f 100644
--- a/content/docs/tools-libraries/libraries.md
+++ b/content/en/docs/tools-libraries/libraries.md
@@ -1,15 +1,9 @@
---
title: "Libraries"
description: "A list of libraries for passkeys and FIDO2/WebAuthn"
-lead: ""
date: 2022-09-24T16:02:27.390Z
-draft: false
-images: []
-menu:
- docs:
- parent: "tools-libraries"
-weight: 701
-toc: true
+layout: docs
+type: docs
---
## Selection criteria
diff --git a/content/docs/tools-libraries/test-sites.md b/content/en/docs/tools-libraries/test-sites.md
similarity index 87%
rename from content/docs/tools-libraries/test-sites.md
rename to content/en/docs/tools-libraries/test-sites.md
index 7537c5d7..1e2536e7 100644
--- a/content/docs/tools-libraries/test-sites.md
+++ b/content/en/docs/tools-libraries/test-sites.md
@@ -1,15 +1,9 @@
---
title: "Test Sites & Tools"
description: ""
-lead: ""
date: 2022-09-24T16:02:27.390Z
-draft: false
-images: []
-menu:
- docs:
- parent: "tools-libraries"
-weight: 702
-toc: true
+layout: docs
+type: docs
---
## FIDO2/WebAuthn Tools
diff --git a/content/docs/use-cases/bootstrapping/index.md b/content/en/docs/use-cases/bootstrapping/index.md
similarity index 71%
rename from content/docs/use-cases/bootstrapping/index.md
rename to content/en/docs/use-cases/bootstrapping/index.md
index 623d0f8f..69e666bc 100644
--- a/content/docs/use-cases/bootstrapping/index.md
+++ b/content/en/docs/use-cases/bootstrapping/index.md
@@ -1,11 +1,8 @@
---
title : "Bootstrapping"
description: "Bootstrapping an account on the web"
-lead: "Bootstrapping an account on the web"
date: 2022-10-10T19:52:26.819Z
-draft: false
-images: ['pkdd-signin-username-next.png']
-weight: 310
+#images: ['pkdd-signin-username-next.png']
---
## Authenticating the user
@@ -16,7 +13,7 @@ To bootstrap an account, serve the user a sign-in page.
Start off by asking the user for their account identifier, typically a username or email address:
-
+{{< image src="pkdd-signin-username-next.png" class="col-10 col-md-7" wrapper="text-center" title="Sample sign in screen with a username field and next button">}}
To support the [autofill UI](/docs/reference/terms/#autofill-ui) for passkeys, make sure to:
@@ -32,50 +29,54 @@ To support the [autofill UI](/docs/reference/terms/#autofill-ui) for passkeys, m
2. On page load, check to see if autofill UI (conditional mediation) is available using an if statement, then call `navigator.credentials.get()` with `mediation: "conditional"` and `userVerification: "preferred"`.
-```html
-
-```
+ })();
+
+ ```
This will cause the following to happen:
- Retrieve the authentication options from your server. Return at least a random challenge to be associated with this authentication request.
-- When the user interacts with the username field, the browser and platform will check whether a passkey exists in the platform authenticator that can be used with the relying party.
If this is the case, the passkey will be presented to the user as an option to choose (along with other credentials that can be auto-filled, such as usernames stored in the browser’s password manager). The browser/platform might render a UI similar to the one shown below, although the exact look and feel will vary from platform to platform (Windows vs. Android vs. iOS), and from form factor to form factor (desktop vs. mobile):
+- When the user interacts with the username field, the browser and platform will check whether a passkey exists in the platform authenticator that can be used with the relying party
+
+ If this is the case, the passkey will be presented to the user as an option to choose (along with other credentials that can be auto-filled, such as usernames stored in the browser’s password manager).
+
+ The browser/platform might render a UI similar to the one shown below, although the exact look and feel will vary from platform to platform (Windows vs. Android vs. iOS), and from form factor to form factor (desktop vs. mobile):
-
+{{< image src="pkdd-signin-username-autofill.png" class="col-10 col-md-7" wrapper="text-center" title="Sample sign in screen with the autofill UI rendered under the username field, showing a passkey for bob@example.com, an other accounts option and a passkey from another device option">}}
- If the user selects the passkey, the platform UI will guide the user through a (often biometrics-based) user verification check.
@@ -107,7 +108,7 @@ If the user used a passkey from another device (such as a phone, tablet, or FIDO
In such a scenario, offer the user the choice to create a passkey on their local device. This will result in a more seamless user experience in the future, as the user will not be required to use their other device.
-
+{{< image src="pkdd-interstitial-cdalocal.png" class="col-10 col-md-7" wrapper="text-center" title="A sample interstitial with the title: Set up a passkey on this device, with the passkey icon to the left. Below is text that reads: Next time you sign in, would you like to use this device instead of your phone? Under that is a button that says yes and a link that says not now.">}}
### A note about user verification
@@ -133,7 +134,7 @@ If passkeys are supported, this will return `true`. If they aren't supported, th
Serve an opt-in or "upsell" modal/interstitial or page to the user offering them to create a passkey:
-
+{{< image src="pkdd-interstitial-upgradeaccount.png" class="col-10 col-md-7" wrapper="text-center" title="A sample interstitial with the title: Faster, safer sign-in with passkeys, with the passkey icon to the left. Below is text that reads: You can now sign into this site using your face, fingerprint, or device PIN! Under that is a button that says create a passkey and a link that says not now.">}}
> Consider showing (or linking to) longer descriptions explaining that all users that are able to unlock the current device will be able to access the account at the relying party to ensure that the user is giving fully informed consent.
@@ -201,8 +202,7 @@ navigator.credentials.create({
})
```
-{{< callout context="note" title="A note on attestation" icon="info-circle" >}}
-We recommend that most relying parties not specify the attestation conveyance parameter `attestation` (thus defaulting to none), or instead explicitly use the value `indirect`. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).
-{{< /callout >}}
+> [!NOTE] A note on attestation
+> We recommend that most relying parties not specify the attestation conveyance parameter `attestation` (thus defaulting to none), or instead explicitly use the value `indirect`. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).
When the WebAuthn call resolves, send the response to your server and associate the returned public key and credential ID with the previously authenticated user account.
diff --git a/content/docs/use-cases/bootstrapping/pkdd-interstitial-cdalocal.png b/content/en/docs/use-cases/bootstrapping/pkdd-interstitial-cdalocal.png
similarity index 100%
rename from content/docs/use-cases/bootstrapping/pkdd-interstitial-cdalocal.png
rename to content/en/docs/use-cases/bootstrapping/pkdd-interstitial-cdalocal.png
diff --git a/content/docs/use-cases/bootstrapping/pkdd-interstitial-upgradeaccount.png b/content/en/docs/use-cases/bootstrapping/pkdd-interstitial-upgradeaccount.png
similarity index 100%
rename from content/docs/use-cases/bootstrapping/pkdd-interstitial-upgradeaccount.png
rename to content/en/docs/use-cases/bootstrapping/pkdd-interstitial-upgradeaccount.png
diff --git a/content/docs/use-cases/bootstrapping/pkdd-signin-username-autofill.png b/content/en/docs/use-cases/bootstrapping/pkdd-signin-username-autofill.png
similarity index 100%
rename from content/docs/use-cases/bootstrapping/pkdd-signin-username-autofill.png
rename to content/en/docs/use-cases/bootstrapping/pkdd-signin-username-autofill.png
diff --git a/content/docs/use-cases/bootstrapping/pkdd-signin-username-next.png b/content/en/docs/use-cases/bootstrapping/pkdd-signin-username-next.png
similarity index 100%
rename from content/docs/use-cases/bootstrapping/pkdd-signin-username-next.png
rename to content/en/docs/use-cases/bootstrapping/pkdd-signin-username-next.png
diff --git a/content/docs/use-cases/reauth/index.md b/content/en/docs/use-cases/reauth/index.md
similarity index 63%
rename from content/docs/use-cases/reauth/index.md
rename to content/en/docs/use-cases/reauth/index.md
index 1e47da3c..ba02d82a 100644
--- a/content/docs/use-cases/reauth/index.md
+++ b/content/en/docs/use-cases/reauth/index.md
@@ -1,11 +1,9 @@
---
title : "Reauthentication"
description: "Performing a reauthentication with passkeys"
-lead: "Performing a reauthentication with passkeys"
date: 2022-10-10T19:52:16.153Z
-draft: false
-images: []
-weight: 320
+type: docs
+layout: docs
---
Reauthentication might happen for the following reasons:
@@ -14,7 +12,7 @@ Reauthentication might happen for the following reasons:
- The user session expired due to inactivity, and the user wants to sign in again
- The user is about to perform a sensitive action, and needs to re-confirm control over the user session
-You’ll use passkeys that you set up in the [previous section](../bootstrapping) to reauthenticate the user in each of these situations. The WebAuthn API call is the same in all three cases, but the UI treatment that you provide is slightly different. Since the particular account is specified by you, the platform will not offer the user to select a different account on your service.
+You’ll use passkeys that you set up in the [previous section](/bootstrapping) to reauthenticate the user in each of these situations. The WebAuthn API call is the same in all three cases, but the UI treatment that you provide is slightly different. Since the particular account is specified by you, the platform will not offer the user to select a different account on your service.
## Sensitive Actions
@@ -22,13 +20,13 @@ Let’s look at the UI for the last case first: when it’s time to re-authentic
If _no such credential ID is available_, serve a traditional login challenge suitable for reauthentication, for example:
-
+{{< image src="pkdd-reauth-password.png" class="col-10 col-md-7" wrapper="text-center" title="Sample reauthentication screen with a title of: Let's make sure it's you, then showing Account: bob@example.com with a password caption and password field below, and a try another way link and next button at the bottom">}}
> We recommend that on this login challenge page, users can’t change their account identifier. Also, the login challenge should be something that an unauthorized user of the device can’t pass.
If, however, you do find at least one passkey credential ID for the user, then you can use passkeys for reauthentication:
-
+{{< image src="pkdd-reauth-passkey.png" class="col-10 col-md-7" wrapper="text-center" title="Sample reauthentication screen with a title of: Let's make sure it's you, then showing Account: bob@example.com, with text below reading: You'll use your passkey to verify it's you, and a try another way link and a Go button with the passkey icon at the bottom">}}
When the user is ready (in the above example, when they click on the "Go" button), call `navigator.credentials.get()`, passing in all the user’s passkey credential IDs:
@@ -52,7 +50,7 @@ navigator.credentials.get({
});
```
-> NOTE: Be sure to read the guidance around userVerification from the [previous page](../bootstrapping#a-note-about-user-verification)
+> NOTE: Be sure to read the guidance around userVerification from the [previous page](/bootstrapping#a-note-about-user-verification)
If the user instead clicks on "Try another way", you should offer them other sign in methods (password, etc.) to reauthenticate them (assuming the user has such other sign in methods available to them).
@@ -64,19 +62,19 @@ Now let’s look at the case where the reauthentication is triggered because the
You, as the relying party, might then serve a sign-in page like this:
-
+{{< image src="pkdd-reauth-logout-passkey.png" class="col-10 col-md-7" wrapper="text-center" title="Sample reauthentication screen with a title of: Welcome back!, then showing a button with the passkey icon and text reading sign in as bob@example.com, with a link below saying Use a different account">}}
-If the user clicks on "Use a different account", then you should enter an account bootstrap flow as explained on the previous page, repeating the steps in [Bootstrapping an account](../bootstrapping), where the platform will let them select which account they want to use.
+If the user clicks on "Use a different account", then you should enter an account bootstrap flow as explained on the previous page, repeating the steps in [Bootstrapping an account](/bootstrapping), where the platform will let them select which account they want to use.
> In this case, you should also give the user the ability to completely remove the suggested account from being listed on the sign-in page.
But if the user clicks the "Sign in as" button, check whether you have at least one passkey credential ID associated with the user. If no credential ID is available, serve a traditional login challenge suitable for reauthentication, for example:
-
+{{< image src="pkdd-reauth-logout-password.png" class="col-10 col-md-7" wrapper="text-center" title="Sample reauthentication screen with a title of: Welcome back!, then showing a button with the passkey icon and text reading sign in as bob@example.com, with a link below saying Use a different account">}}
If, however, you _do_ find at least one passkey credential ID for the user, then you can use passkeys for reauthentication:
-
+{{< image src="pkdd-reauth-logout-passkey-knowncid.png" class="col-10 col-md-7" wrapper="text-center" title="Sample reauthentication screen with a title of: Welcome back!, then showing a button with the passkey icon and text reading sign in as bob@example.com, with a link below saying Try another way">}}
When the user is ready (in the above example, when they click on the “Go!” button), call `navigator.credentials.get()`, exactly as shown above (i.e., by passing in all the user’s passkey credential IDs).
diff --git a/content/docs/use-cases/reauth/pkdd-reauth-logout-passkey-knowncid.png b/content/en/docs/use-cases/reauth/pkdd-reauth-logout-passkey-knowncid.png
similarity index 100%
rename from content/docs/use-cases/reauth/pkdd-reauth-logout-passkey-knowncid.png
rename to content/en/docs/use-cases/reauth/pkdd-reauth-logout-passkey-knowncid.png
diff --git a/content/docs/use-cases/reauth/pkdd-reauth-logout-passkey.png b/content/en/docs/use-cases/reauth/pkdd-reauth-logout-passkey.png
similarity index 100%
rename from content/docs/use-cases/reauth/pkdd-reauth-logout-passkey.png
rename to content/en/docs/use-cases/reauth/pkdd-reauth-logout-passkey.png
diff --git a/content/docs/use-cases/reauth/pkdd-reauth-logout-password.png b/content/en/docs/use-cases/reauth/pkdd-reauth-logout-password.png
similarity index 100%
rename from content/docs/use-cases/reauth/pkdd-reauth-logout-password.png
rename to content/en/docs/use-cases/reauth/pkdd-reauth-logout-password.png
diff --git a/content/docs/use-cases/reauth/pkdd-reauth-passkey.png b/content/en/docs/use-cases/reauth/pkdd-reauth-passkey.png
similarity index 100%
rename from content/docs/use-cases/reauth/pkdd-reauth-passkey.png
rename to content/en/docs/use-cases/reauth/pkdd-reauth-passkey.png
diff --git a/content/docs/use-cases/reauth/pkdd-reauth-password.png b/content/en/docs/use-cases/reauth/pkdd-reauth-password.png
similarity index 100%
rename from content/docs/use-cases/reauth/pkdd-reauth-password.png
rename to content/en/docs/use-cases/reauth/pkdd-reauth-password.png
diff --git a/content/privacy-policy.en.md b/content/en/privacy-policy.md
similarity index 90%
rename from content/privacy-policy.en.md
rename to content/en/privacy-policy.md
index d91f0d9e..345c72c4 100644
--- a/content/privacy-policy.en.md
+++ b/content/en/privacy-policy.md
@@ -1,9 +1,8 @@
---
title: "Privacy Policy"
description: "We do not use cookies and we do not collect any personal data."
-date: 2022-10-11T01:40:04.273Z
-draft: false
-images: []
+type: minimal
+layout: minimal
---
__TLDR__: We do not use cookies and we do not collect any personal data.
diff --git a/content/faq/_index.md b/content/faq/_index.md
deleted file mode 100644
index 9b3e8644..00000000
--- a/content/faq/_index.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: "Frequently Asked Questions"
-description: ""
-lead: "put some intro text here"
-date: 2022-08-04T18:01:38.505Z
-draft: true
-images: []
-toc: true
----
-
-## Intro to passkeys
-
-{{< details "What is a passkey?" >}}
-Commodo pariatur laboris excepteur excepteur ut nostrud voluptate.
-{{< /details >}}
-
-{{< details "What is the difference between a passkey and a multi-device credential?" >}}
-They are the same. "Multi-device credential" is the official name in the WebAuthn specification, whereas "passkey" is a more user friendly term (similar to "password").
-{{< /details >}}
-
-{{< details "What is the difference between a single-device passkey and a passkey?" >}}
-A single-device passkey is bound to a device and cannot be backed up or synced.
-{{< /details >}}
-
-{{< details "Do security keys support passkeys?" >}}
-Today, security keys can hold single-device passkeys, as they are bound to the authenticator. Security key vendors may decide to offer multi-device passkey authenticators in the future.
-
-Security keys also support second-factor only credentials (often referred to as U2F credentials), which are _not_ passkeys.
-{{< /details >}}
-
-{{< details "What is the difference between a passkey and a multi-device credential?" >}}
-Pariatur aliquip ea ea ea.
-{{< /details >}}
-
-## Ecosystem and Compatibility
-
-{{< details "Which platforms support passkeys?" >}}
-Aliquip pariatur qui dolore proident cillum officia. See the [Ecosystem](/ecosystem) page for more details.
-{{< /details >}}
-
-{{< details "Can I use passkeys to authenticate across different platforms and/or ecosystems?" >}}
-Lorem aute quis laborum non adipisicing sit anim minim laborum reprehenderit deserunt aliquip culpa.
-{{< /details >}}
-
-{{< details "How does the user sign-in if a passkey for the Relying Party (RP) is not already available on the device?" >}}
-This is best understood with an example: say the user has an Android phone where they already have a credential for the [RP](/docs/reference/terms/#relying-party-rp). Now they want to sign-in to the RP’s website on Windows where they have never signed into the website before.
-
-For existing devices, the user will point their browser to the RP’s website in Windows. They see a 'sign-in' button on the login web page and hit that button.The user sees the option to link a new phone or use a previously linked one. If the user selects the linked phone and the phone is physically close to the Windows device, the user sees a pop-up from Android asking in essence “I see you are trying to sign-in on this nearby computer, here are the accounts I have.” The user chooses an account at which point Android asks "Please perform your unlock to approve sign-in to the computer with this account". The user performs the unlock and they are signed-in to the website.
-
-Alternatively, the user can use a security key that has been enrolled with the RP. In this instance, the user will point their browser to the RP website on the Windows computer. They see a ‘sign-in’ button on the RP’s login web page and hit that button. When the RP asks for FIDO authentication, the user is able to insert or tap their Security Key to unlock and they are signed-in to the website.
-
-The flow described in this example would work regardless of the OS the user’s mobile phone is running and the OS and browser available on the target device for login (eg, computer, tablet, TV etc). The target user experience is very similar to that of a phone push notification approval prompt commonly used today as a second-factor today. The crucial difference is that the approval is now phishing-resistant — this is because, when you approve a login on another device on a conventional phone approval, you don’t really know whether your other device is pointed to the correct website or a look-alike phishing site relaying information in real-time. In addition, the mobile device approval also replaces the password (as opposed to being used as a second factor adjunct).
-{{< /details >}}
-
-{{< details "How can the user switch to a new mobile platform using passkeys (eg, from iOS to Android or vice versa)?" >}}
-If the user still has their old device, they can use it to sign into their new device (using the FIDO Cross Device Authentication flow). If they don’t, then the [RP](/docs/reference/terms/#relying-party-rp) can treat sign-in from the new device (which might be from a different vendor) as a normal account recovery situation and take appropriate steps to sign in the user. The RP would then usually create a new multi-device credential on the new device (which runs a different platform OS than the user’s previous device). If the user no longer plans to use their old device, they can let the RP know, and the RP can then delete the credential of the old device from their server records — thus, the credential on the old device will no longer be accepted for sign-in.
-
-If the user is still in possession of their old device, the RP can also use the credential on that old device (say, an Android device) to sign the user into the new device (say, an iOS device) without going through an account recovery step. See previous question for more detail the old mobile can be used to sign-in to the new mobile in a simple phishing resistant way.
-
-Additionally, a user can use a security key to securely authenticate to a new device.
-{{< /details >}}
-
-## Security
-
-{{< details "Why are passkeys better than password + second factor?" >}}
-Passwords and second-factors, such as one time passwords (OTPs) and phone push notification approvals, are inconvenient and insecure. They can be phished, and they are being phished at scale today. Passkeys are designed to solve this problem. They have three fundamental advantages over using passwords (even when used with traditional second-factors):
-
-**Sign-in is easier for the user:** It’s the same biometric or PIN users use to unlock their device. The user doesn’t need to deal with typing passwords or OTPs.
-
-**Sign-in is fundamentally safer (phishing-resistant):** Phishing-resistance of sign-in is a core design goal of FIDO and is built into every sign-in event that leverages FIDO. Furthermore, breaches of password databases (which can be an attractive target for hackers) no longer pose a threat.
-
-**Sign-in is more robust:** Users often forget passwords and don’t set up backup emails and phone numbers. With passkeys, the credentials are backed up and are therefore protected from loss. If the user gets a new phone the credentials can easily be restored to the new phone. When signing in from a new device, the existence of a passkey is a powerful trust signal that websites can leverage to make recovering access to the account radically safer and simpler, since it means that the platform vendor has already verified the user.
-{{< /details >}}
-
-{{< details "Are passkeys considered multi-factor authentication?" >}}
-Passkeys are present on a user’s devices (something the user "has") and – if the Relying Party requests this – can only be exercised by the user with a biometric or PIN (something the user “is” or ”knows”). Thus, authentication with a passkey embodies the core principle of multi-factor security.
-{{< /details >}}
-
-{{< details "Can I use passkeys to authenticate across different platforms and/or ecosystems?" >}}
-Lorem aute quis laborum non adipisicing sit anim minim laborum reprehenderit deserunt aliquip culpa.
-{{< /details >}}
-
-## Privacy
-
-{{< details "Do passkeys change FIDO's privacy posture?" >}}
-We expect all platforms implementing passkeys to adhere to FIDO’s [Privacy Principles](https://media.fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf), including usage of personal data for the sole purpose of FIDO operations.
-{{< /details >}}
-
-{{< details "Is the user's biometric information safe?" >}}
-Yes, there are no changes to user verification methods or their security properties as part of the effort – and user biometrics will never leave the device.
-{{< /details >}}
-
-{{< details "Can I use passkeys to authenticate across different platforms and/or ecosystems?" >}}
-Lorem aute quis laborum non adipisicing sit anim minim laborum reprehenderit deserunt aliquip culpa.
-{{< /details >}}
diff --git a/data/docs-versions.yml b/data/docs-versions.yml
deleted file mode 100644
index 8e7e5dd9..00000000
--- a/data/docs-versions.yml
+++ /dev/null
@@ -1,60 +0,0 @@
-# - group: v1.x
-# baseurl: "https://getbootstrap.com"
-# description: "Every minor and patch release from v1 is listed below."
-# versions:
-# - v: "1.0.0"
-# - v: "1.1.0"
-# - v: "1.1.1"
-# - v: "1.2.0"
-# - v: "1.3.0"
-# - v: "1.4.0"
-#
-# - group: v2.x
-# baseurl: "https://getbootstrap.com"
-# description: "Every minor and patch release from v2 is listed below."
-# versions:
-# - v: "2.0.0"
-# - v: "2.0.1"
-# - v: "2.0.2"
-# - v: "2.0.3"
-# - v: "2.0.4"
-# - v: "2.1.0"
-# - v: "2.1.1"
-# - v: "2.2.0"
-# - v: "2.2.1"
-# - v: "2.2.2"
-# - v: "2.3.0"
-# - v: "2.3.1"
-# - v: "2.3.2"
-#
-# - group: v3.x
-# baseurl: "https://getbootstrap.com/docs"
-# description: "Every minor and patch release from v3 is listed below. Last update was v3.4.1."
-# versions:
-# - v: "3.3"
-# - v: "3.4"
-#
-# - group: v4.x
-# baseurl: "https://getbootstrap.com/docs"
-# description: "Our previous major release with its minor releases. Last update was v4.6.0."
-# versions:
-# - v: "4.0"
-# - v: "4.1"
-# - v: "4.2"
-# - v: "4.3"
-# - v: "4.4"
-# - v: "4.5"
-# - v: "4.6"
-
-- group: v0.x
- baseurl: "/docs"
- description: "Current major release. Last update was v0.2.0."
- versions:
- - v: "0.1"
- - v: "0.2"
-
-- group: v1.x
- baseurl: "/docs"
- description: "Every minor and patch release from v1 is listed below. Last update was v1.0.0."
- versions:
- - v: "1.0"
diff --git a/data/docs.yml b/data/docs.yml
new file mode 100644
index 00000000..bd2dfcfa
--- /dev/null
+++ b/data/docs.yml
@@ -0,0 +1,41 @@
+# This file holds all menu entries for the docs sidebar
+
+- title: Intro
+ pages:
+ - title: What are passkeys?
+
+- title: Use Cases
+ pages:
+ - title: Bootstrapping
+ - title: Reauthentication
+ link: reauth
+
+- title: Advanced
+ pages:
+ - title: Related Origin Requests
+ link: related-origins
+
+- title: Tools & Libraries
+ pages:
+ - title: Libraries
+ - title: Test Sites
+
+
+- title: Reference
+ pages:
+ - title: Android
+ - title: "iOS & iPadOS"
+ link: iOS
+ - title: Chrome OS
+ link: chromeos
+ - title: macOS
+ - title: Windows
+ - title: Known Issues
+ - title: Specifications
+ link: specs
+ - title: Terms
+
+- title: Demos
+ pages:
+ - title: Demos Sites
+ link: ../demos-examples/demos.md
diff --git a/functions/hi-from-lambda.js b/functions/hi-from-lambda.js
deleted file mode 100644
index 88e4fa00..00000000
--- a/functions/hi-from-lambda.js
+++ /dev/null
@@ -1,11 +0,0 @@
-exports.handler = (event, context, callback) => {
- callback (null, {
- statusCode: 200,
- headers: {
- 'Content-Type': 'application/json',
- },
- body: JSON.stringify({
- message: 'Hi from Lambda.',
- }),
- });
-}
diff --git a/go.mod b/go.mod
new file mode 100644
index 00000000..459013b9
--- /dev/null
+++ b/go.mod
@@ -0,0 +1,5 @@
+module hinode.passkeys.dev
+
+go 1.23.4
+
+require github.com/gethinode/hinode v0.27.18 // indirect
diff --git a/go.sum b/go.sum
new file mode 100644
index 00000000..9370dffc
--- /dev/null
+++ b/go.sum
@@ -0,0 +1,4 @@
+github.com/gethinode/hinode v0.27.17 h1:rPQmxmFCBIT+S3WBfHRp41d6QYzf/Z/i0BuLi8cvEeo=
+github.com/gethinode/hinode v0.27.17/go.mod h1:k+TUNPNBbNY2kNlzDySw3k/GuDHetfKN/qTXKHwlbk0=
+github.com/gethinode/hinode v0.27.18 h1:rlksX+VmW37ORcoyE9n33uFF6NdINgmN5fsTtgag7lk=
+github.com/gethinode/hinode v0.27.18/go.mod h1:k+TUNPNBbNY2kNlzDySw3k/GuDHetfKN/qTXKHwlbk0=
diff --git a/hugo_stats.json b/hugo_stats.json
index 778f5141..8f0bb46c 100644
--- a/hugo_stats.json
+++ b/hugo_stats.json
@@ -2,41 +2,28 @@
"htmlElements": {
"tags": [
"a",
- "article",
- "aside",
- "base",
"blockquote",
"body",
"br",
"button",
- "circle",
"code",
- "details",
"div",
"em",
"figcaption",
"figure",
"footer",
"form",
- "g",
- "h1",
"h2",
"h3",
"h4",
"h5",
"head",
- "header",
- "hr",
"html",
- "i",
"img",
"input",
- "kbd",
"label",
"li",
- "line",
"link",
- "main",
"meta",
"nav",
"noscript",
@@ -45,373 +32,463 @@
"path",
"pre",
"script",
- "section",
"small",
"span",
"strong",
- "style",
- "summary",
"sup",
"svg",
+ "symbol",
"table",
"tbody",
"td",
- "template",
"th",
"thead",
- "time",
"title",
"tr",
"ul",
- "wbr"
+ "use"
],
"classes": [
- "DocSearch-Label",
- "about",
+ "accordion",
+ "accordion-body",
+ "accordion-button",
+ "accordion-collapse",
+ "accordion-header",
+ "accordion-item",
"active",
- "align-middle",
+ "align-items-center",
+ "align-self-center",
+ "align-top",
"anchor",
- "badge",
- "bg-color-green",
- "bg-light",
- "bi",
- "bi-box-arrow-up-right",
- "bi-calendar-plus",
- "bi-chat-square-text-fill",
- "bi-check-circle",
- "bi-check-circle-fill",
- "bi-circle-half",
- "bi-github",
- "bi-house-heart",
- "bi-mastodon",
- "bi-pencil",
- "bi-twitter-x",
- "bi-usb-drive",
- "bi-wrench-adjustable-circle-fill",
- "bi-x-circle-fill",
+ "ball",
+ "bg-body",
+ "bg-body-tertiary",
+ "blockquote",
+ "blockquote-alert",
+ "blockquote-alert-heading",
+ "blockquote-alert-note",
"border",
+ "border-0",
+ "border-top",
+ "bottom-0",
+ "bottom-bar",
"btn",
- "btn-black",
"btn-close",
- "btn-lg",
+ "btn-dark",
"btn-light",
- "btn-link",
- "callout",
- "callout-body",
- "callout-content",
- "callout-icon",
- "callout-note",
- "callout-title",
+ "btn-outline-secondary",
+ "btn-primary",
+ "btn-sm",
+ "btn-social",
+ "btn-toggle",
+ "btn-toggle-nav",
"card",
"card-body",
- "card-list",
- "categories",
- "chroma",
+ "card-icon",
+ "card-text",
+ "card-title",
+ "checkbox",
"col",
- "col-lg-10",
- "col-lg-11",
- "col-lg-12",
- "col-lg-16",
- "col-lg-5",
+ "col-10",
+ "col-12",
+ "col-4",
+ "col-lg-2",
"col-lg-8",
- "col-lg-9",
"col-md-12",
- "col-xl-3",
- "col-xl-4",
- "col-xl-8",
- "col-xl-9",
- "color-black",
- "color-green",
- "color-red",
- "container",
+ "col-md-2",
+ "col-md-3",
+ "col-md-4",
+ "col-md-7",
+ "col-md-8",
+ "col-md-9",
+ "col-sm-12",
+ "collapse",
+ "collapsed",
"container-fluid",
- "container-lg",
- "content",
- "contributors",
- "created-date",
+ "container-xxl",
+ "d-block",
"d-flex",
+ "d-grid",
+ "d-inline-flex",
"d-lg-block",
- "d-lg-none",
"d-md-block",
"d-md-none",
"d-none",
- "d-xl-block",
- "d-xl-none",
- "device-support",
- "docs",
- "docs-content",
- "docs-links",
- "docs-sidebar",
- "docs-sidebar-offset",
- "docs-sidebar-top",
- "docs-toc",
- "docs-toc-offset",
- "doks-sidebar",
- "error404",
- "expressive-code",
+ "d-none-dark",
+ "d-none-inline-dark",
+ "d-none-inline-light",
+ "d-none-light",
+ "display-1",
+ "display-4",
+ "display-6",
+ "emphasis",
+ "end-0",
+ "fa",
+ "fa-10x",
+ "fa-2xl",
+ "fa-4x",
+ "fa-android",
+ "fa-apple",
+ "fa-at",
+ "fa-bluesky",
+ "fa-calendar-plus",
+ "fa-circle-check",
+ "fa-circle-info",
+ "fa-circle-xmark",
+ "fa-comments",
+ "fa-ellipsis",
+ "fa-face-frown",
+ "fa-fw",
+ "fa-github",
+ "fa-house",
+ "fa-key",
+ "fa-link",
+ "fa-linkedin",
+ "fa-mastodon",
+ "fa-moon",
+ "fa-people-robbery",
+ "fa-share-nodes",
+ "fa-snowflake",
+ "fa-sort",
+ "fa-sun",
+ "fa-threads",
+ "fa-user-shield",
+ "fa-wand-magic-sparkles",
+ "fa-whatsapp",
+ "fa-xl",
+ "fab",
+ "fas",
+ "figure-caption",
+ "fixed-top",
"flex-column",
- "flex-grow-1",
- "flex-lg-row",
- "flex-md-row",
- "flex-row",
- "flex-sm-row",
- "flex-xl-nowrap",
+ "flex-fill",
+ "flex-shrink-0",
"footer",
+ "footer-muted",
"form-control",
- "form-control-lg",
- "frame",
- "fs-4",
- "fs-5",
+ "fs-3",
"fs-6",
+ "fs-lg-5",
+ "fs-md-5",
"fst-italic",
+ "fw-30",
"fw-bold",
- "fw-semibold",
- "gx-5",
- "h-auto",
- "h4",
- "h5",
- "header",
- "header-bar",
+ "fw-bolder",
+ "fw-medium",
+ "fw-normal",
+ "g-3",
+ "gap-1",
+ "gap-2",
+ "h-100",
+ "h6",
+ "heading",
"highlight",
- "home",
- "icon",
- "icon-tabler",
- "icon-tabler-arrow-left",
- "icon-tabler-arrow-right",
- "icon-tabler-dots-vertical",
- "icon-tabler-menu",
- "icon-tabler-moon",
- "icon-tabler-search",
- "icon-tabler-sun",
- "icon-tabler-x",
- "info-circle",
+ "hstack",
+ "img-fluid",
+ "invisible",
+ "is-search",
"justify-content-between",
"justify-content-center",
- "justify-content-end",
+ "label",
"lead",
- "list",
- "list-inline",
- "list-inline-item",
- "list-nested",
+ "lh-1",
+ "link-bg-footer",
"list-unstyled",
- "list-view",
- "m-2",
- "mb-0",
+ "m-0",
+ "main-content",
+ "main-nav-toggler",
+ "mb-1",
"mb-2",
"mb-3",
"mb-4",
"mb-5",
- "me-2",
+ "mb-lg-5",
"me-auto",
- "me-lg-1",
- "me-lg-3",
- "message",
- "modal",
- "modal-body",
- "modal-content",
- "modal-dialog",
- "modal-dialog-scrollable",
- "modal-footer",
- "modal-fullscreen-md-down",
- "modal-header",
- "modal-title",
- "ms-2",
- "ms-3",
+ "middle-bar",
+ "min-vh-100",
+ "mode-switch",
"ms-auto",
- "ms-lg-2",
+ "ms-md-3",
"mt-0",
+ "mt-2",
"mt-3",
"mt-4",
"mt-5",
- "mt-n3",
- "mx-2",
+ "mt-md-0",
"mx-auto",
- "mx-xl-auto",
- "my-3",
+ "my-2",
+ "my-auto",
+ "my-md-0",
"nav",
"nav-item",
"nav-link",
+ "nav-pills",
+ "nav-tabs",
"navbar",
"navbar-brand",
- "navbar-expand-lg",
+ "navbar-collapse",
+ "navbar-container",
+ "navbar-expand-md",
+ "navbar-fixed-top",
+ "navbar-mode-selector",
"navbar-nav",
- "not-content",
+ "navbar-nav-scroll",
+ "navbar-toggler",
+ "no-js",
"offcanvas",
"offcanvas-body",
- "offcanvas-end",
"offcanvas-header",
"offcanvas-start",
"offcanvas-title",
- "order-3",
- "order-lg-4",
+ "order-first",
"p-0",
+ "p-1",
"p-2",
"p-3",
- "page-footer-meta",
- "page-links",
- "page-nav",
+ "p-4",
"pb-2",
"pb-3",
+ "pb-5",
"pe-1",
- "pe-4",
- "privacy-policy",
+ "position-fixed",
+ "position-relative",
+ "ps-0",
+ "ps-1",
"ps-3",
+ "pt-2",
+ "pt-3",
"pt-4",
- "px-0",
- "px-4",
- "query-no-results",
- "rounded-pill",
+ "pt-5",
+ "pt-md-0",
+ "px-3",
+ "px-xxl-0",
+ "py-1",
+ "py-3",
+ "py-5",
+ "rounded",
"row",
- "search-form",
+ "row-cols-1",
+ "row-cols-2",
+ "row-cols-lg-3",
+ "row-cols-md-2",
+ "row-cols-sm-1",
+ "row-cols-sm-3",
+ "search",
"search-input",
- "search-loading",
- "search-no-recent",
- "search-no-results",
- "search-result",
- "search-results",
- "search-text",
- "section",
- "section-nav",
- "section-sm",
- "single",
- "social-link",
- "status",
+ "search-suggestions",
+ "shadow",
+ "show",
+ "sidebar",
+ "sidebar-item",
+ "sidebar-overflow",
+ "small",
"sticky-top",
- "stretched-link",
- "submitted",
- "svg-icon-bw",
- "svg-inline",
+ "svg-inline--fa",
+ "syntax-highlight",
+ "tab-content",
+ "tab-pane",
"table",
"table-responsive",
"table-striped",
- "tags",
- "taxonomy",
- "text-bg-secondary",
- "text-bg-warning",
+ "text-bg-body",
+ "text-body",
"text-body-secondary",
"text-center",
+ "text-danger",
+ "text-dark",
"text-decoration-none",
"text-end",
- "text-lg-end",
- "text-lg-start",
"text-muted",
- "text-reset",
- "title",
- "title-submitted",
- "toc-mobile",
- "visually-hidden",
+ "text-nowrap",
+ "text-secondary",
+ "text-start",
+ "text-success",
+ "text-uppercase",
+ "text-warning",
+ "toast",
+ "toast-body",
+ "toast-container",
+ "toast-header",
+ "toc",
+ "toc-button",
+ "toc-panel",
+ "toc-sidebar",
+ "toggler-icon",
+ "top-bar",
"w-100",
- "wrap",
- "youtube-preview"
+ "w-25"
],
"ids": [
"2-factor-authentication-2fa",
"2fa-user",
- "Layer_1",
"TableOfContents",
"a-note-about-user-verification",
- "about",
+ "about-passkeysdev",
+ "accordion-default",
+ "accordion-default-heading-0",
+ "accordion-default-item-0",
"account-bootstrapping",
+ "additional-information",
"advanced",
+ "alternate-branding",
"attestation",
"authenticating-the-user",
"authentication-factor",
"autofill-ui",
"basic",
+ "basics",
"browser-behavior",
- "buttonColorMode",
+ "categories",
+ "cctld",
"cda-authenticator",
"cda-client",
"chrome-120",
"chrome-120-with-icloud-keychain-on-macos-14",
+ "client-support",
"client-to-authenticator-protocol-ctap",
"community-resources",
"conditional-mediation",
"conditional-ui",
- "content",
- "content-and-tools",
- "contribute",
+ "considerations",
"contributors",
"copyright-and-attributions",
"cross-device-authentication",
"cross-device-authentication-cda",
- "date",
+ "deployment-considerations",
"developer-experience",
"developer-involvement-and-maintenance",
"device-bound-passkey",
+ "device-support-native-apps",
"device-support-table",
+ "device-support-table-adv",
"discoverable-credential",
"docs",
- "doks-docs-nav",
+ "embedded-webviews",
+ "embedded-webviews-ewv",
"engage-and-contribute",
+ "example",
+ "existing-deployments",
"expired-sessions-and-logout",
+ "fa-calendar-plus",
+ "fa-circle-check",
+ "fa-comments",
+ "fa-face-frown",
+ "fa-snowflake",
+ "fab-android",
+ "fab-apple",
+ "fab-bluesky",
+ "fab-github",
+ "fab-linkedin",
+ "fab-mastodon",
+ "fab-threads",
+ "fab-whatsapp",
+ "fas-angle-left",
+ "fas-angle-right",
+ "fas-angles-left",
+ "fas-angles-right",
+ "fas-at",
+ "fas-circle-check",
+ "fas-circle-info",
+ "fas-circle-xmark",
+ "fas-ellipsis",
+ "fas-house",
+ "fas-key",
+ "fas-link",
+ "fas-moon",
+ "fas-people-robbery",
+ "fas-share-nodes",
+ "fas-sort",
+ "fas-sun",
+ "fas-user-shield",
+ "fas-wand-magic-sparkles",
"fido2webauthn-tools",
"first-party-passkey-provider",
+ "flow",
+ "fn1",
+ "fn2",
+ "fn3",
+ "fn4",
+ "fn5",
+ "fn6",
+ "fn7",
+ "fn8",
"general-passkey-demo-sites",
"go",
- "h-rh-i-0",
- "h-rh-i-1",
- "h-rh-i-2",
- "h-rh-i-3",
- "h-rh-i-4",
- "icon-protected",
+ "greenfield-deployments",
+ "how-it-works",
"java",
"java-1",
"legacy-credentials",
"licensing",
"logging-in",
"login-challenge",
- "main",
"maintainers",
"matrix",
- "meta",
+ "native-apis",
+ "native-apps",
+ "nav-pills-1",
+ "nav-tabs-1",
+ "navbar-0-collapse",
+ "navbar-mode",
+ "navbar-mode-checkbox",
"net",
- "offcanvasNavMain",
- "offcanvasNavMainLabel",
- "offcanvasNavSection",
- "offcanvasNavSectionLabel",
+ "offcanvas-label",
+ "offcanvass-sidebar",
"opting-the-user-into-passkeys",
"other-attributions",
"other-fido2webauthn-libraries",
"overview",
"passkey",
+ "passkey-metadata",
"passkey-provider",
+ "passkeys-are",
"persistent-linking",
+ "pills-1-0",
+ "pills-1-1",
+ "pills-1-2",
+ "pills-1-btn-0",
+ "pills-1-btn-1",
+ "pills-1-btn-2",
"platform-authenticator",
"platform-notes",
"python",
- "query",
"reauthentication",
+ "relying-party-changes",
"relying-party-rp",
+ "requirements",
+ "requirements-1",
"resources",
"roaming-authenticator",
+ "ror",
"ruby",
"rust",
"safari-on-ios--ipados-17",
"safari-on-macos-14",
"sample-code",
- "search-form",
- "searchModal",
- "searchModalLabel",
- "searchResults",
- "searchToggleDesktop",
- "searchToggleMobile",
+ "samsung-pass",
"selection-criteria",
"sensitive-actions",
+ "sidebar-collapse-0-1",
+ "sidebar-collapse-1-1",
+ "sidebar-collapse-2-1",
+ "sidebar-collapse-3-1",
+ "sidebar-collapse-4-1",
+ "sidebar-collapse-5-1",
"signing-in",
"single-device-passkey",
- "socialMenu",
- "supfive",
- "supfour",
- "supone",
- "supthree",
- "suptwo",
"synced-passkey",
+ "system-webviews",
+ "system-webviews-swv",
+ "tabs-1-0",
+ "tabs-1-btn-0",
"third-party-passkey-provider",
- "title",
- "toc",
+ "toast-container",
+ "toast-copied-code-message",
+ "toast-message-link-0",
+ "toc-collapse",
"typescript",
"updated-for-passkeys",
+ "use-cases",
"user-presence-up",
"user-verification",
"user-verification-behavior",
@@ -424,7 +501,7 @@
"w3c-web-authentication-webauthn",
"webauthn-versions-and-capabilities",
"website-visitors",
- "whats-next"
+ "webviews"
]
}
}
diff --git a/i18n/de.yaml b/i18n/de.yaml
deleted file mode 100644
index d1f125ee..00000000
--- a/i18n/de.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-- id: get-started
- translation: "Loslegen"
-
-- id: on-this-page
- translation: "Auf dieser Seite"
diff --git a/i18n/en.yaml b/i18n/en.yaml
deleted file mode 100644
index 05ff248f..00000000
--- a/i18n/en.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-- id: get-started
- translation: "Get Started"
-
-- id: on-this-page
- translation: "On this page"
-
-- id: search-text
- translation: "Search docs..."
-
-- id: 404-title
- translation: "Page not found :("
-
-- id: 404-text
- translation: "The page you are looking for doesn't exist or has been moved."
-
-- id: browse
- translation: "Browse"
diff --git a/i18n/nl.yaml b/i18n/nl.yaml
deleted file mode 100644
index 2899edae..00000000
--- a/i18n/nl.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-- id: get-started
- translation: "Aan de slag"
-
-- id: on-this-page
- translation: "Op deze pagina"
-
-- id: search-text
- translation: "Zoeken..."
-
-- id: 404-title
- translation: "Pagina niet gevonden :("
-
-- id: 404-text
- translation: "De gezochte pagina bestaat niet of deze is verplaatst."
-
-- id: browse
- translation: "Browse"
diff --git a/images/doks.png b/images/doks.png
deleted file mode 100644
index 1f5d0800..00000000
Binary files a/images/doks.png and /dev/null differ
diff --git a/images/screenshot.png b/images/screenshot.png
deleted file mode 100644
index 072753bb..00000000
Binary files a/images/screenshot.png and /dev/null differ
diff --git a/images/tn.png b/images/tn.png
deleted file mode 100644
index ff29c682..00000000
Binary files a/images/tn.png and /dev/null differ
diff --git a/layouts/_default/_markup/render-link.html b/layouts/_default/_markup/render-link.html
deleted file mode 100644
index 5a977469..00000000
--- a/layouts/_default/_markup/render-link.html
+++ /dev/null
@@ -1 +0,0 @@
-{{ .Text | safeHTML }}
\ No newline at end of file
diff --git a/layouts/_default/fullpage.html b/layouts/_default/fullpage.html
deleted file mode 100644
index 76fe6330..00000000
--- a/layouts/_default/fullpage.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ define "main" }}
-
-
{{ .Title }}
-
-
- {{ .Content }}
-
-
-
-
-
-{{ end }}
\ No newline at end of file
diff --git a/layouts/_default/single.html b/layouts/_default/single.html
deleted file mode 100644
index 372835e3..00000000
--- a/layouts/_default/single.html
+++ /dev/null
@@ -1,63 +0,0 @@
-{{ define "main" }}
-
- {{ if (in site.Params.doks.sectionNav .Section) -}}
-
-
-
- {{ end -}}
- {{ if and (eq site.Params.doks.containerBreakpoint "fluid") (in .Site.Params.mainSections .Type) }}
-
- {{ end }}
- {{ if ne .Params.toc false -}}
-
- {{ end -}}
- {{ if .Params.toc -}}
-
- {{ else -}}
-
- {{ end -}}
- {{ if site.Params.doks.breadcrumbTrail -}}
-
-
- {{ end }}
-
{{ .Title }}
-
{{ .Params.lead | safeHTML }}
- {{ if ne .Params.toc false -}}
-
- {{ end -}}
-
- {{ if site.Params.doks.headlineHash -}}
- {{ partial "main/headline-hash" .Content }}
- {{ else -}}
- {{ .Content }}
- {{ end -}}
-
- {{ partial "main/docs-navigation.html" . }}
-
-
- {{ if and (eq site.Params.doks.containerBreakpoint "fluid") (in .Site.Params.mainSections .Type) }}
-
- {{ end }}
-
-{{ end }}
\ No newline at end of file
diff --git a/layouts/about/about.html b/layouts/about/about.html
deleted file mode 100644
index 6072fefb..00000000
--- a/layouts/about/about.html
+++ /dev/null
@@ -1,22 +0,0 @@
-{{ define "main" }}
-
-
{{ .Title }}
-
-
- {{ .Content }}
-
-
-
-
-
-{{ end }}
\ No newline at end of file
diff --git a/layouts/about/single.html b/layouts/about/single.html
deleted file mode 100644
index 5ed296ee..00000000
--- a/layouts/about/single.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ define "main" }}
-
-
{{ .Title }}
-
-
- {{ .Content }}
-
-
-
-
-
-{{ end }}
\ No newline at end of file
diff --git a/layouts/device-support/single.html b/layouts/device-support/single.html
deleted file mode 100644
index 76fe6330..00000000
--- a/layouts/device-support/single.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ define "main" }}
-
-
{{ .Title }}
-
-
- {{ .Content }}
-
-
-
-
-
-{{ end }}
\ No newline at end of file
diff --git a/layouts/docs/matrix.html b/layouts/docs/matrix.html
deleted file mode 100644
index be0acc60..00000000
--- a/layouts/docs/matrix.html
+++ /dev/null
@@ -1,48 +0,0 @@
-{{ define "main" }}
-
-
-
-
-
-
- {{ if .Site.Params.options.breadCrumb -}}
-
-
- {{ end }}
-
{{ .Title }}
-
{{ .Params.lead | safeHTML }}
- {{ if ne .Params.toc false -}}
-
- {{ end -}}
- {{ .Content }}
-
-
-
Last Updated: {{ .Lastmod.Format "Jan 02, 2006" }}