fixed 1 warning and 2 linking errors

index.bs

@@ -161,7 +161,7 @@ A variety of additional use cases and configurations are also possible, includin
     example.com in their browser on a laptop or phone, and is guided though a flow to create and register a credential on the
     fob.
 
-- A [RP] prompts the user for their [=authorization gesture=] in order to authorize a single transaction, such as a payment
+- A [=[RP]=] prompts the user for their [=authorization gesture=] in order to authorize a single transaction, such as a payment
     or other financial transaction.
 
 # Conformance # {#conformance}
@@ -283,7 +283,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 : <dfn>Credential Public Key</dfn>
 :: The public key portion of an [=[RP]=]-specific <dfn>credential key pair</dfn>, generated by an [=authenticator=] and
-    returned to an [RP] at [=registration=] time (see also [=public key credential=]). The private key portion of the
+    returned to an [=[RP]=] at [=registration=] time (see also [=public key credential=]). The private key portion of the
     [=credential key pair=] is known as the <dfn>credential private key</dfn>. Note that in the case of [=self
     attestation=], the [=credential key pair=] is also used as the [=attestation key pair=], see [=self attestation=]
     for details.
@@ -297,12 +297,12 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 :: The entity whose web application utilizes the [=Web Authentication API=] to register and authenticate users. See
     [=Registration=] and [=Authentication=], respectively.
 
-    Note: While the term [RP] is used in other contexts (e.g., X.509 and OAuth), an entity acting as a [RP] in one context is
-        not necessarily a [RP] in other contexts.
+    Note: While the term [=[RP]=] is used in other contexts (e.g., X.509 and OAuth), an entity acting as a [=[RP]=] in one context is
+        not necessarily a [=[RP]=] in other contexts.
 
 : <dfn>Relying Party Identifier</dfn>
 : <dfn>RP ID</dfn>
-:: An identifier for the [RP] on whose behalf a given registration or authentication ceremony is being performed. Public Key
+:: An identifier for the [=[RP]=] on whose behalf a given registration or authentication ceremony is being performed. Public Key
     credentials can only be used for authentication by the same entity (as identified by RP ID) that created and registered
     them. By default, the RP ID for a WebAuthn operation is set to the [=environment settings object/origin=] specified by the
     [=relevant settings object=] of the {{CredentialsContainer}} object. This default can be overridden by the caller subject
@@ -315,7 +315,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     information consists of an asymmetric key pair, where the public key portion is returned to the [RP], which stores it in
     conjunction with the present user's account. The authenticator maps the private key to the [RP]'s [=RP ID=] and stores
     it. Subsequently, only that [RP], as identified by its [=RP ID=], is able to employ the [=public key credential=] in
-    [=authentication=] ceremonies, via the {{CredentialsContainer/get()}} method. The [RP] uses its copy of the stored public
+    [=authentication=] ceremonies, via the {{CredentialsContainer/get()}} method. The [=[RP]=] uses its copy of the stored public
     key to verify the resultant [=Authentication Assertion=].
 
 : <dfn>Test of User Presence</dfn>
@@ -362,7 +362,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 # <dfn>Web Authentication API</dfn> # {#api}
 
 This section normatively specifies the API for creating and using [=public key credentials=]. The basic
-idea is that the credentials belong to the user and are managed by an authenticator, with which the [RP] interacts through the
+idea is that the credentials belong to the user and are managed by an authenticator, with which the [=[RP]=] interacts through the
 client (consisting of the browser and underlying OS platform). Scripts can (with the user's consent) request the browser to
 create a new credential for future use by the [RP]. Scripts can also request the user’s permission to perform authentication
 operations with an existing credential. All such operations are performed in the authenticator and are mediated by the browser
@@ -434,7 +434,7 @@ that are returned to the caller when a new credential is created, or a new asser
 
         Note: This is reflected via the {{Credential/type}} attribute getter inherited from {{Credential}}.
 
-    :   {{Credential/[[discovery]]}}
+    :   <dfn>\[[discovery]]</dfn>
     ::  The {{PublicKeyCredential}} [=interface object=]'s {{Credential/[[discovery]]}} [=internal slot=]'s value is
         "{{Credential/[[discovery]]/remote}}".
 
@@ -592,11 +592,11 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
 1. If |options|.{{MakeCredentialOptions/authenticatorSelection}} is [=present|present=], iterate through 
         |currentlyAvailableAuthenticators| and do the following [=set/for each=] |authenticator|:
-    1. If |attachment| is [=present|present=] and its value is not equal to |authenticator|'s attachment modality, 
-        [=iteration/continue=].
-    1. If |requireResidentKey| is set to |true| and the |authenticator| is not capable of storing 
-        a [=Client-Side-Resident Credential Private Key=], append a new {{DOMException}} whose name is 
-        "{{QuotaExceededError}}" to |selectionReasons| and [=iteration/continue=].
+    1. If {{AuthenticatorSelectionCriteria/attachment}} is [=present|present=] and its value is not equal 
+        to |authenticator|'s attachment modality, [=iteration/continue=].
+    1. If {{AuthenticatorSelectionCriteria/requireResidentKey}} is set to |true| and the |authenticator| 
+        is not capable of storing a [=Client-Side-Resident Credential Private Key=], append a new {{DOMException}}
+        whose name is "{{QuotaExceededError}}" to |selectionReasons| and [=iteration/continue=].
     1. [=set/Append=] |authenticator| to |selectedAuthenticators|. 
 
 1. If |selectedAuthenticators| [=list/is empty=], then if |selectionReasons| is: 
@@ -1067,9 +1067,8 @@ associated.
 
     :   <dfn>requireResidentKey</dfn>
     ::  This member describes the [=[RPS]=]' requirements regarding availability of the [=Client-side-resident Credential 
-        Private Key=]. If the parameter is set to <a>true</a>, the authenticator MUST create a 
-        [=Client-side-resident Credential Private Key=] when creating a [=scoped credential=].
-
+        Private Key=]. If the parameter is set to true, the authenticator MUST create a 
+        [=Client-side-resident Credential Private Key=] when creating a [=public key credential=].
 </div>
 
 
@@ -1194,8 +1193,8 @@ following Web IDL.
     discretion.
 
     The <dfn>tokenBinding</dfn> member contains the base64url encoding of the [=Token Binding ID=] that this client uses for the
-    [=Token Binding=] protocol when communicating with the [RP]. This can be omitted if no [=Token Binding=] has been negotiated
-    between the client and the [RP].
+    [=Token Binding=] protocol when communicating with the [=RP=]. This can be omitted if no [=Token Binding=] has been negotiated
+    between the client and the [=RP=].
 
     The optional <dfn>clientExtensions</dfn> and <dfn>authenticatorExtensions</dfn> members contain additional parameters
     generated by processing the extensions passed in
@@ -1593,7 +1592,7 @@ The privacy, security and operational characteristics of attestation depend on:
     operating environment, and so on.
 
 It is expected that most authenticators will support a small number of attestation types and attestation statement formats,
-while [RPS] will decide what attestation types are acceptable to them by policy. [RPS] will also need to understand the
+while [RPS] will decide what attestation types are acceptable to them by policy. [=[RP]=]  will also need to understand the
 characteristics of the authenticators that they trust, based on information they have about these authenticators. For example,
 the FIDO Metadata Service [[FIDOMetadataService]] provides one way to access such information.
 
@@ -1772,7 +1771,7 @@ in several ways, including:
     [=origin=] attestation keys and attestation certificates.
 
 - A WebAuthn Authenticator can implement [=Elliptic Curve based direct anonymous attestation=] (see [[FIDOEcdaaAlgorithm]]).
-    Using this scheme, the authenticator generates a blinded attestation signature. This allows the [RP] to verify the signature
+    Using this scheme, the authenticator generates a blinded attestation signature. This allows the [=[RP]=] to verify the signature
     using the [=ECDAA-Issuer public key=], but the attestation signature doesn't serve as a global correlation handle.
 
 
@@ -1781,14 +1780,14 @@ in several ways, including:
 When an intermediate CA or a root CA used for issuing attestation certificates is compromised, WebAuthn [=authenticator=]
 attestation keys are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
 has recorded the public attestation keys for their devices can issue new attestation certificates for these keys from a new
-intermediate CA or from a new root CA. If the root CA changes, the [RPS] must update their trusted root certificates
+intermediate CA or from a new root CA. If the root CA changes, the [=[RPS]=]  must update their trusted root certificates
 accordingly.
 
 A WebAuthn Authenticator attestation certificate must be revoked by the issuing CA if its key has been compromised. A WebAuthn
 Authenticator manufacturer may need to ship a firmware update and inject new attestation keys and certificates into already
 manufactured WebAuthn Authenticators, if the exposure was due to a firmware flaw. (The process by which this happens is out of
 scope for this specification.) If the WebAuthn Authenticator manufacturer does not have this capability, then it may not be
-possible for [RPS] to trust any further attestation statements from the affected WebAuthn Authenticators.
+possible for [=[RPS]=] to trust any further attestation statements from the affected WebAuthn Authenticators.
 
 If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [RP]'s policy
 requires rejecting the registration/authentication request in these situations, then it is recommended that the [RP] also