Merge pull request #607 from csalas-yubico/main

Updates to EA content

content/WebAuthn/Concepts/Enterprise_Attestation/Considerations.adoc

@@ -19,7 +19,7 @@ Just because an application supports attestation, does not mean that it will sup
 Until EA is widely adopted, there may be cases where your chosen operating system, or browser may not allow for the ability for an application to request EA. Some ecosystems, like Google Chrome, require that the feature be enabled but also provides the ability to set a list of domains that are allowed to request EA.  
 
 == Multi device credentials and enterprise attestation
-As it currently stands, there are no known plans for passkeys created through multi-device credentials to include the ability to support enterprise attestation. The feature will be supported by passkeys created on YubiKeys in a future firmware version.
+As it currently stands, there are no known plans for passkeys created through multi-device credentials to include the ability to support enterprise attestation. The feature is supported by passkeys created on YubiKeys in the future firmware version.
 
 == Getting Started
 Click the link below to continue to our next section where we will outline what is needed to get started deploying enterprise attestation. 

content/WebAuthn/Concepts/Enterprise_Attestation/Use_cases.adoc

@@ -7,9 +7,7 @@ Learn about different use cases for enterprise attestation
 In this section we will discuss some possible use cases for enterprise attestation **(EA)**. We are primarily focused on **high assurance** use cases, where there is a regulatory or business requirement that requires the highest degree of certainty that the device being used is owned and controlled by the real user.
 
 == Registration of new device
-When a user receives a new authenticator with FIDO2 Enterprise Attestation enabled, the EA feature needs to be activated by the user, or it can be activated by an enterprise managed platform such as an enterprise managed browser. Once the feature is activated, the user will register the device just as any other FIDO2 security key. 
-
-During the registration process the Relying Party will register normal data from the authenticator such as the public key and the AAGUID as well as the extra information associated with the EA certificate, e.g. the serial number. The Relying Party can then use the serial number of the authenticator to track the use of that individual authenticator in their IdP, or make decisions based on the information in the EA certificate.
+When using a FIDO2 authenticator with enterprise attestation the user will register the device just as they would for any FIDO2 credential (there are no additional steps for the end user). During the registration process the Relying Party will register standard attestation data from the authenticator such as the public key and the AAGUID as well as the extra information associated with the EA certificate, e.g. the serial number. The Relying Party can then use the serial number of the authenticator to track the use of that individual authenticator in their IdP, or make decisions based on the information in the EA certificate.
 
 == Subdomain separation
 There may be cases where an enterprise has an instance of an application that is only available to a specific subdomain. This could be due to data residency, regulatory, or business requirements that prevent users from one region accessing an instance of the application from another region. In this case it’s not enough to allow all of the YubiKeys that you have deployed in your ecosystem to access an application; you want to ensure that only the YubiKeys that you deployed in a specific region can access their corresponding resources.

content/WebAuthn/Concepts/Enterprise_Attestation/index.adoc

@@ -25,7 +25,7 @@ Now that we have some understanding of what attestation is, let’s dive into ho
 
 == Enterprise attestation
 Let’s envision a scenario where an enterprise, Acme Inc, has worked with a trusted authenticator manufacturer, Yubico, to purchase and deploy YubiKey 5 NFCs to their workforce. 
-With “regular” YubiKey attestation, Acme will be able to limit registrations in their application to ONLY accept YubiKey 5 NFCs. This means that any attempt to register any other form of authenticator will be rejected. What if the RP could identify the make/model of the device, **AND** also uniquely identify each device, and determine whether it is to be allowed for use in the environment. One problem is that this notion goes against the privacy features of WebAuthn that prevent a backend service from uniquely identifying devices. 
+With “regular” YubiKey attestation, Acme will be able to limit registrations in their application to ONLY accept YubiKey 5 NFCs. This means that any attempt to register any other form of authenticator will be rejected. What if the RP could identify the make/model of the device, **AND** also uniquely identify each device to determine whether it is to be allowed for use in the environment? One problem is that this notion goes against the privacy features of WebAuthn that prevent a backend service from uniquely identifying devices. 
 
 Enterprise Attestation **(EA)** looks to close this gap by providing the ability to configure authenticators with an attestation statement that could offer uniquely identifiable information. This could mean that if a backend service specifically requests EA, the authenticator could provide an identifier like the device's serial number. 
 
@@ -58,7 +58,7 @@ Platform managed EA allows for more flexibility in the domains/origins that are
 
 This form of EA works well in scenarios when an enterprise has a device management process in place where a set of policies can be given directly to an end user. In the case of platform managed EA, a user has the ability to disable the feature on their authenticator through a hard reset. EA should be allowed to be re-enabled through enterprise managed tools.
 
-Note, that platform managed EA is independent of vendor facilitated. In both cases, the security key will need to support EA - but with platform managed, the platform can still allow EA requests from a list of domains, even if they are not part of a vendor configured list. 
+Note, that platform managed EA is independent of vendor facilitated. In both cases, the security key will need to support EA - but with platform managed, the platform can still allow EA requests from a list of domains, even if they are not part of a vendor configured list.
 
 == Use cases
 Click the link below to continue to our next section where we will explore use cases for enterprise attestation.