Add dfn links to occurences of "user consent"

index.bs

@@ -136,9 +136,9 @@ the existence, of credentials scoped to other [RPS].
 is [=Registration=], where a [=public key credential=] is created on an [=authenticator=], and associated by a [=[RP]=]
 with the present user's account (the account may already exist or may be created at this time). The second is
 [=Authentication=], where the [=[RP]=] is presented with an <em>[=Authentication Assertion=]</em> proving the presence
-and consent of the user who registered the [=public key credential=]. Functionally, the [=Web Authentication API=] comprises
-a {{PublicKeyCredential}} which extends the Credential Management API [[!CREDENTIAL-MANAGEMENT-1]], and infrastructure which
-allows those credentials to be used with {{CredentialsContainer/create()|navigator.credentials.create()}} and
+and [=user consent|consent=] of the user who registered the [=public key credential=]. Functionally, the [=Web Authentication
+API=] comprises a {{PublicKeyCredential}} which extends the Credential Management API [[!CREDENTIAL-MANAGEMENT-1]], and
+infrastructure which allows those credentials to be used with {{CredentialsContainer/create()|navigator.credentials.create()}} and
 {{CredentialsContainer/get()|navigator.credentials.get()}}. The former is used during [=Registration=], and the
 latter during [=Authentication=].
 
@@ -492,11 +492,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 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
-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
-and/or platform on the user's behalf. At no point does the script get access to the credentials themselves; it only gets
-information about the credentials in the form of objects.
+client (consisting of the browser and underlying OS platform). Scripts can (with the [=user consent|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 and/or platform on the user's behalf. At no point does the script get access to the credentials themselves; it only
+gets information about the credentials in the form of objects.
 
 In addition to the above script interface, the authenticator may implement (or come with client software that implements) a user
 interface for management. Such an interface may be used, for example, to reset the authenticator to a clean state or to inspect
@@ -867,13 +867,12 @@ authorizing an authenticator.
 ### Use an existing credential to make an assertion ### {#getAssertion}
 
 [=[RPS]=] call <code><a idl for="CredentialsContainer" lt="get()">navigator.credentials.get({publicKey:..., ...})</a></code> to
-discover and use an existing [=public key credential=], with the user's consent. The script optionally specifies some criteria
-to indicate what [=credential sources=] are acceptable to it. The user agent and/or platform locates [=credential sources=]
-matching the specified criteria, and guides the user to pick one that the script will be allowed to use. The user may choose to
-decline the entire interaction even if a [=credential source=] is present, for example to maintain privacy. If the user picks a
-[=credential source=], the user agent then uses
-[[#op-get-assertion]] to sign a [RP]-provided challenge and other collected data into an assertion, which is used as a
-[=credential=].
+discover and use an existing [=public key credential=], with the [=user consent|user's consent=]. The script optionally specifies
+some criteria to indicate what [=credential sources=] are acceptable to it. The user agent and/or platform locates [=credential
+sources=] matching the specified criteria, and guides the user to pick one that the script will be allowed to use. The user may
+choose to decline the entire interaction even if a [=credential source=] is present, for example to maintain privacy. If the user
+picks a [=credential source=], the user agent then uses [[#op-get-assertion]] to sign a [RP]-provided challenge and other
+collected data into an assertion, which is used as a [=credential=].
 
 The {{CredentialsContainer/get()}} implementation [[CREDENTIAL-MANAGEMENT-1]] calls
 <code>PublicKeyCredential.{{PublicKeyCredential/[[CollectFromCredentialStore]]()}}</code> to collect any [=credentials=] that
@@ -3625,7 +3624,7 @@ IANA "WebAuthn Extension Identifier" registry established by [[!WebAuthn-Registr
     <br/><br/>
 - WebAuthn Extension Identifier: loc
 - Description: The location [=registration extension=] and [=authentication extension=] provides the client device's current
-    location to the WebAuthn relying party, if supported by the client device and subject to user consent.
+    location to the WebAuthn relying party, if supported by the client device and subject to [=user consent=].
 - Specification Document: Section [[#sctn-location-extension]] of this specification
     <br/><br/>
 - WebAuthn Extension Identifier: uvm