AWS cognito: Cognito passkey auth flow doc: grammar and typo fixes
Summary
Editorial corrections throughout the passkey/authentication flow methods page: fixed typos ('displated'→'displayed', 'reliying'→'relying', 'FQDN'→'fully qualified domain name'), added missing commas, and corrected grammar ('when the register'→'when they register', 'will return'→'returns'). No substantive technical or security content changed.
Security assessment
The only changes are spelling, punctuation, and grammar corrections (e.g., 'displated'→'displayed', 'reliying'→'relying', 'will return'→'returns'). The surrounding text already discusses passkey security benefits, but this diff does not add or alter any security guidance, feature, or configuration.
Evidence
+Passkeys are secure and impose a relatively low effort level on users. Passkey sign-in makes use of _authenticators_ , external devices that users can authenticate with. Regular passwords expose users to vulnerabilities like phishing, password guessing, and credential theft. With passkeys, your application can benefit from advanced security measures on mobile phones and other devices attached to or built in to information systems. A common passkey sign-in workflow starts with a call to your device that invokes your password or _credentials_ manager, for example the iOS keychain or the Google Chrome password manager. The on-device credentials manager prompts them to select a passkey and authorize it with an existing credential or device-unlock mechanism. Modern phones have face scanners, fingerprint scanners, unlock patterns, and other mechanisms, some that simultaneously satisfy the _something you know_ and _something you have_ principles of strong authentication. In the case of passkey authentication with biometrics, passkeys represent a _something you are_.
Diff
diff --git a/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow-methods.md b/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow-methods.md index 4d5453c..cb33a63 100644 --- a//cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow-methods.md +++ b//cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow-methods.md @@ -201 +201 @@ To verify that SRP authentication is available in your choice-based authenticati - + @@ -444 +444 @@ This would also be the next challenge response if you requested `EMAIL_OTP` as a -Passkeys are secure and impose a relatively low effort level on users. Passkey sign-in makes use of _authenticators_ , external devices that users can authenticate with. Regular passwords expose users to vulnerabilities like phishing, password guessing, and credential theft. With passkeys, your application can benefit from advanced security measures on mobile phones and other devices attached to or built in to information systems. A common passkey sign-in workflow starts with a call to your device that invokes your password or _credentials_ manager, for example the iOS keychain or the Google Chrome password manager. The on-device credentials manager prompts them to select a passkey and authorize it with an existing credential or device-unlock mechanism. Modern phones have face scanners, fingerprint scanners, unlock patterns and other mechanisms, some that simultaneously satisfy the _something you know_ and _something you have_ principles of strong authentication. In the case of passkey authentication with biometrics, passkeys represent a _something you are_. +Passkeys are secure and impose a relatively low effort level on users. Passkey sign-in makes use of _authenticators_ , external devices that users can authenticate with. Regular passwords expose users to vulnerabilities like phishing, password guessing, and credential theft. With passkeys, your application can benefit from advanced security measures on mobile phones and other devices attached to or built in to information systems. A common passkey sign-in workflow starts with a call to your device that invokes your password or _credentials_ manager, for example the iOS keychain or the Google Chrome password manager. The on-device credentials manager prompts them to select a passkey and authorize it with an existing credential or device-unlock mechanism. Modern phones have face scanners, fingerprint scanners, unlock patterns, and other mechanisms, some that simultaneously satisfy the _something you know_ and _something you have_ principles of strong authentication. In the case of passkey authentication with biometrics, passkeys represent a _something you are_. @@ -464 +464 @@ The following are some examples and capabilities of authenticators currently on - * Some authenticators, for example YubiKey hardware tokens, are portable. They communicate with devices through USB, Bluetooth or NFC connections. Some authenticators are local and bound to a platform, for example Windows Hello on a PC or Face ID on an iPhone. A device-bound authenticator can be carried by user if small enough, like a mobile device. Sometimes users can connect their hardware authenticator with many different platforms with wireless communication. For example, users in desktop browsers can use their smart phone as a passkey authenticator when they scan a QR code. + * Some authenticators, for example YubiKey hardware tokens, are portable. They communicate with devices through USB, Bluetooth, or NFC connections. Some authenticators are local and bound to a platform, for example Windows Hello on a PC or Face ID on an iPhone. A device-bound authenticator can be carried by user if small enough, like a mobile device. Sometimes users can connect their hardware authenticator with many different platforms with wireless communication. For example, users in desktop browsers can use their smart phone as a passkey authenticator when they scan a QR code. @@ -471 +471 @@ The following are some examples and capabilities of authenticators currently on -In WebAuthn terminology, websites and apps are _relying parties_. Each passkey is associated with a specific relying party ID, a unified identifier that represents the websites or apps that accept passkey authentication.. Developers must carefully select their relying party ID to have the right scope of authentication. A typical reliying party ID is the root domain name of a webserver. A passkey with this relying party ID specification can authenticate for that domain and subdomains. Browsers and platforms deny passkey authentication when the URL of the website a user want to access doesn't match the relying party ID. Similarly, for mobile apps, a passkey can only be used if the app path is present in the `.well-known` association files that the application makes available at the path indicated by the relying party ID. +In WebAuthn terminology, websites and apps are _relying parties_. Each passkey is associated with a specific relying party ID, a unified identifier that represents the websites or apps that accept passkey authentication.. Developers must carefully select their relying party ID to have the right scope of authentication. A typical relying party ID is the root domain name of a webserver. A passkey with this relying party ID specification can authenticate for that domain and subdomains. Browsers and platforms deny passkey authentication when the URL of the website a user wants to access doesn't match the relying party ID. Similarly, for mobile apps, a passkey can only be used if the app path is present in the `.well-known` association files that the application makes available at the path indicated by the relying party ID. @@ -483 +483 @@ In your user pool, you can configure user verification to be preferred or requir -The relying party (RP) ID that you set in your passkey configuration is an important decision. When you don't specify otherwise and your [domain branding version](./managed-login-branding.html) is managed login, your user pool defaults to expecting the name of your [custom domain](./cognito-user-pools-add-custom-domain.html) as the RP ID. If you don't have a custom domain and don't specify otherwise, your user pool defaults to an RP ID of your [prefix domain](./cognito-user-pools-assign-domain-prefix.html). You can also configure your RP ID to be any domain name not in the public suffix list (PSL). Your RP ID entry applies to passkey registration and authentication in managed login and in SDK authentication. Passkey is only functional in mobile applications with Amazon Cognito can locate a `.well-known` association file with your RP ID as the domain. As a best practice, determine and set the value of your relying party ID before your website or app is publicly available. If you change your RP ID, your users must register again with the new RP ID. +The relying party (RP) ID that you set in your passkey configuration is an important decision. When you don't specify otherwise and your [domain branding version](./managed-login-branding.html) is managed login, your user pool defaults to expecting the name of your [custom domain](./cognito-user-pools-add-custom-domain.html) as the RP ID. If you don't have a custom domain and don't specify otherwise, your user pool defaults to an RP ID of your [prefix domain](./cognito-user-pools-assign-domain-prefix.html). You can also configure your RP ID to be any domain name not in the public suffix list (PSL). Your RP ID entry applies to passkey registration and authentication in managed login and in SDK authentication. Passkey is only functional in mobile applications when Amazon Cognito can locate a `.well-known` association file with your RP ID as the domain. As a best practice, determine and set the value of your relying party ID before your website or app is publicly available. If you change your RP ID, your users must register again with the new RP ID. @@ -487 +487 @@ Each user can register up to 20 passkeys. They can only register a passkey after -When you set up user pool authentication with passkeys and you have a custom domain and a prefix domain, the RP ID defaults to the fully-qualified domain name (FQDN) of your custom domain. To set a prefix domain as the RP ID in the Amazon Cognito console, delete your custom domain or enter the FQDN of the prefix domain as a **Third-party domain**. +When you set up user pool authentication with passkeys and you have a custom domain and a prefix domain, the RP ID defaults to the fully qualified domain name (FQDN) of your custom domain. To set a prefix domain as the RP ID in the Amazon Cognito console, delete your custom domain or enter the FQDN of the prefix domain as a **Third-party domain**. @@ -500 +500 @@ Navigate to the **Authentication methods** menu and edit **Passkey**. - * The **Domain for relying party ID** is the identifier that your application will pass in users' passkey registration requests. It sets the target of the trust relationship with the issuer of users' passkeys. Your relying party ID can be: the domain of your user pool if + * The **Domain for relying party ID** is the identifier that your application passes in users' passkey registration requests. It sets the target of the trust relationship with the issuer of users' passkeys. Your relying party ID can be one of the following: @@ -553 +553 @@ Register a passkey (managed login) -Managed login handles user registration of passkeys. When passkey authentication is active in your user pool, Amazon Cognito prompts users to set up a passkey when the register for a new user account. +Managed login handles user registration of passkeys. When passkey authentication is active in your user pool, Amazon Cognito prompts users to set up a passkey when they register for a new user account. @@ -577 +577 @@ Register a passkey (SDK) -You register passkey credentials with metadata in a [PublicKeyCreationOptions](https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialcreationoptions) object. You can generate this object with the credentials of a signed-in user and present them in an API request to their passkey issuer. The issuer will return a [RegistrationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-registrationresponsejson) object that confirms passkey registration. +You register passkey credentials with metadata in a [PublicKeyCreationOptions](https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialcreationoptions) object. You can generate this object with the credentials of a signed-in user and present them in an API request to their passkey issuer. The issuer returns a [RegistrationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-registrationresponsejson) object that confirms passkey registration. @@ -586 +586 @@ To start the process of passkey registration, sign in a user with an existing si -The response from your user pool contains the `PublicKeyCreationOptions` object. Present this object in an API request to the user's issuer. It provides information like the public key and relying party ID. The issuer will respond with a `RegistrationResponseJSON` object. +The response from your user pool contains the `PublicKeyCreationOptions` object. Present this object in an API request to the user's issuer. It provides information like the public key and relying party ID. The issuer responds with a `RegistrationResponseJSON` object. @@ -607 +607 @@ In this example, we know that the user wants to sign in with a passkey, and we a -Amazon Cognito responds with a `WEB_AUTHN` challenge. Your application must respond to this challenge. Initiate a sign-in request with the user's passkey provider. It will return an [AuthenticationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-authenticationresponsejson) object. +Amazon Cognito responds with a `WEB_AUTHN` challenge. Your application must respond to this challenge. Initiate a sign-in request with the user's passkey provider. It returns an [AuthenticationResponseJSON](https://www.w3.org/TR/webauthn-3/#dictdef-authenticationresponsejson) object.