addresses Vijay's comments other than wrt credential definition

index.src.html

@@ -40,16 +40,18 @@
 created and stored by an <em><a>authenticator</a></em> at the behest of a <em><a>[RP]</a></em>, subject to <em><a>user
 consent</a></em>. Subsequently, the scoped credential can only be accessed by web origins belonging to that [RP].
 This scoping is enforced jointly by <em><a>conforming User Agents</a></em> and <em><a>authenticators</a></em>. 
-Additionally, privacy across <a>[RPS]</a> is maintained; [RPS]' browser scripts are not able to detect any properties, or even
+Additionally, privacy across <a>[RPS]</a> is maintained; [RPS] are not able to detect any properties, or even
 the existence, of credentials scoped to other [RPS].
 
 [RPS] employ the <a>Web Authentication API</a> during two distinct, but related, <a>ceremonies</a> involving a user. The first
 is <a>Registration</a>, where a <a>scoped credential</a> is created on an <a>authenticator</a>, and associated by a <a>[RP]</a>
 with the present user's account (the account may already exist or may be created at this time). The second is
-<a>Authentication</a>, where the <a>[RP]</a> is presented with a <em><a>WebAuthn Assertion</a></em> proving the present user is
-the the one who registered the <a>scoped credential</a>. Functionally, the <a>Web Authentication API</a> comprises two methods
-(along with associated data structures): <a>makeCredential()</a> and <a>getAssertion()</a>. The former is used during
+<a>Authentication</a>, where the <a>[RP]</a> is presented with a <em><a>WebAuthn Assertion</a></em> proving the presence and
+consent of the user who registered the <a>scoped credential</a>. Functionally, the <a>Web Authentication API</a> comprises two
+methods (along with associated data structures): <a>makeCredential()</a> and <a>getAssertion()</a>. The former is used during
 <a>Registration</a> and the latter during <a>Authentication</a>.
+
+
 Broadly, <a>authenticators</a> are of two types:
 
 1. <dfn>Embedded authenticators</dfn> have their operation managed by the same computing device (e.g., smart phone, tablet,
@@ -72,7 +74,7 @@
 ## Use Cases ## {#use-cases}
 
 The below use case scenarios illustrate both <a>embedded authenticator</a> and <a>external authenticator</a> modes, as well as
-outline further scenarios.
+outline further scenarios. Additional scenarios, including sample code, are given later in [[#sample-scenarios]].
 
 ### Registration (<a>embedded authenticator</a> mode) ### {#registration-embedded}
 
@@ -108,21 +110,21 @@
 
 - User navigates to example.com on their laptop, is guided through a flow to create and register a credential on their phone.
 
-- A [RP] prompts the user for their <a>authorization gesture</a> in order to authorize a single transaction, such as a payment or other financial transaction.
-
+- A [RP] prompts the user for their <a>authorization gesture</a> in order to authorize a single transaction, such as a payment
+or other financial transaction.
 
 # Conformance # {#conformance}
 
 This specification defines criteria for a <a>Conforming User Agent</a>: a User Agent MUST behave as described in this
-specification in order to be considered conformant. <a>Conforming User Agents</a> MAY implement algorithms given in this specification in any way
-desired, so long as the end result is indistinguishable from the result that would be obtained by the specification's
-algorithms. A conforming User Agent MUST also be a conforming implementation of the IDL fragments of this
+specification in order to be considered conformant. <a>Conforming User Agents</a> MAY implement algorithms given in this
+specification in any way desired, so long as the end result is indistinguishable from the result that would be obtained by the
+specification's algorithms. A conforming User Agent MUST also be a conforming implementation of the IDL fragments of this
 specification, as described in the “Web IDL” specification. [[!WebIDL-1]]
 
-This specification also defines a model of a conformant <a>authenticator</a> (see [[#authenticator-model]]). This is a set of functional and
-security requirements for an authenticator to be usable by a <a>Conforming User Agent</a>. As described
-in [[#use-cases]], an authenticator may be implemented in the operating system underlying the User Agent, or in external
-hardware, or a combination of both.
+This specification also defines a model of a conformant <a>authenticator</a> (see [[#authenticator-model]]). This is a set of
+functional and security requirements for an authenticator to be usable by a <a>Conforming User Agent</a>. As described in
+[[#use-cases]], an authenticator may be implemented in the operating system underlying the User Agent, or in external hardware,
+or a combination of both.
 
 
 ## Dependencies ## {#dependencies}
@@ -164,39 +166,57 @@
 :: See <a>WebAuthn Assertion</a>.
 
 : <dfn>Attestation Certificate</dfn>
-:: A X.509 Certificate for a key pair used by an <a>Authenticator</a> to attest to its manufacture and capabilities. The <a>Authenticator</a> uses the attestation private key to sign the <a>[RP]</a>-specific public key (and additional data) it generates and returns upon invocation via the <a>authenticatorMakeCredential</a> operation. 
+:: A X.509 Certificate for a key pair used by an <a>Authenticator</a> to attest to its manufacture and capabilities. The
+<a>Authenticator</a> uses the attestation private key to sign the <a>[RP]</a>-specific public key (and additional data) it
+generates and returns upon invocation via the <a>authenticatorMakeCredential</a> operation.
 
 : <dfn>Authentication</dfn>
-:: The <a>ceremony</a> where a user, and the user's computing device(s) (containing at least one <a>authenticator</a>) work in concert to cryptographically prove to an <a>[RP]</a> that the user controls the private key associated with a previously-registered <a>scoped credential</a> (see <a>Registration</a>). Note that this includes employing <a>user verification</a>.
+:: The <a>ceremony</a> where a user, and the user's computing device(s) (containing at least one <a>authenticator</a>) work in
+concert to cryptographically prove to an <a>[RP]</a> that the user controls the private key associated with a
+previously-registered <a>scoped credential</a> (see <a>Registration</a>). Note that this includes employing <a>user
+verification</a>.
 
 : <dfn>Authenticator</dfn>
-:: A cryptographic device used by a <a>[WAC]</a> to (i) generate a <a>scoped credential</a> and register it with a <a>[RP]</a>, and (ii) subsequently used to cryptographically sign and return, in the form of an <a>WebAuthn Assertion</a>, a challenge and other data presented by a <a>[RP]</a> (in concert with the <a>[WAC]</a>) in order to effect authentication. Broadly, authenticators are of two types: <a>Embedded Authenticators</a> or <a>External Authenticators</a>.
+:: A cryptographic device used by a <a>[WAC]</a> to (i) generate a <a>scoped credential</a> and register it with a <a>[RP]</a>,
+and (ii) subsequently used to cryptographically sign and return, in the form of an <a>WebAuthn Assertion</a>, a challenge and
+other data presented by a <a>[RP]</a> (in concert with the <a>[WAC]</a>) in order to effect authentication. Broadly,
+authenticators are of two types: <a>Embedded Authenticators</a> or <a>External Authenticators</a>.
 
 : <dfn>Authorization Gesture</dfn>
 :: Essentially the same as <a>user verification</a>.
 
 : <dfn>Ceremony</dfn>
-:: The concept of a ceremony [[Ceremony]] is an extension of the concept of a network protocol, with human nodes alongside computer nodes and with communication links that include UI, human-to-human communication and transfers of physical objects that carry data. What is out-of-band to a  protocol is in-band to a ceremony. In this specification, <a>Registration</a>, <a>Authentication</a>, and <a>user verification</a> are ceremonies. 
+:: The concept of a ceremony [[Ceremony]] is an extension of the concept of a network protocol, with human nodes alongside
+computer nodes and with communication links that include UI, human-to-human communication and transfers of physical objects that
+carry data. What is out-of-band to a protocol is in-band to a ceremony. In this specification, <a>Registration</a>,
+<a>Authentication</a>, and <a>user verification</a> are ceremonies.
 
 : <dfn>Client</dfn>
 :: See <a>Conforming User Agent</a>.
 
 : <dfn>Conforming User Agent</dfn>
-:: A user agent implementing, in conjunction with the underlying platform, the <a>Web Authentication API</a> and algorithms given in this specification, and handling communication between 
-    <a>Authenticators</a> and <a>[RPS]</a>.
+:: A user agent implementing, in conjunction with the underlying platform, the <a>Web Authentication API</a> and algorithms
+given in this specification, and handling communication between <a>Authenticators</a> and <a>[RPS]</a>.
 
 : <dfn>eTLD+1</dfn>
-:: Also known as a <em>Registered Domain</em> [[PSL]], an eTLD+1 is an <em>effective Top-Level Domain Name</em> (eTLD), plus the next domain name label, proceding from right to left. An eTLD is also known as a <em>public suffix</em> [[RFC7719]].
+:: Also known as a <em>Registered Domain</em> [[PSL]], an eTLD+1 is an <em>effective Top-Level Domain Name</em> (eTLD), plus the
+next domain name label, proceding from right to left. An eTLD is also known as a <em>public suffix</em> [[RFC7719]].
 
 : <dfn>Registration</dfn>
-:: The <a>ceremony</a> where a user, a <a>[RP]</a>, and the user's computing device(s) (containing at least one <a>authenticator</a>) work in concert to create a <a>scoped credential</a> and associate it with the user's <a>[RP]</a> account.  Note that this includes employing <a>user verification</a>.
+:: The <a>ceremony</a> where a user, a <a>[RP]</a>, and the user's computing device(s) (containing at least one
+<a>authenticator</a>) work in concert to create a <a>scoped credential</a> and associate it with the user's <a>[RP]</a> account.
+Note that this includes employing <a>user verification</a>.
 
 : <dfn>Relying Party Identifier</dfn>
 : <dfn>RP ID</dfn>
 :: A Relying Party Identifier is derived from a <a>[RP]</a>'s web origin's hostname by computing the hostname's <a>eTLD+1</a>. 
 
 : <dfn>Scoped Credential</dfn>
-:: Generically, a credential is data one entity presents to another in order to authenticate the former's identity [[RFC4949]]. A <em><a>scoped credential</a></em>, as defined here, is one that is cryptographically bound to a <a>[RP]</a>'s <a>RP ID</a>. Per specification, it is conveyed--i.e., registered--to only the <a>[RP]</a> instigating the credential's creation (see: <a>Registration</a>). Subsequently, only that <a>[RP]</a>, as identified by it's <a>RP ID</a> is able to employ the <a>scoped credential</a> in <a>authentication</a> ceremonies. 
+:: Generically, a credential is data one entity presents to another in order to authenticate the former's identity [[RFC4949]].
+A <em><a>scoped credential</a></em>, as defined here, is one that is cryptographically bound to a <a>[RP]</a>'s <a>RP ID</a>.
+Per specification, it is conveyed--i.e., registered--to only the <a>[RP]</a> instigating the credential's creation (see:
+<a>Registration</a>). Subsequently, only that <a>[RP]</a>, as identified by it's <a>RP ID</a> is able to employ the <a>scoped
+credential</a> in <a>authentication</a> ceremonies.
 
 : <dfn>User Consent</dfn>
 :: User consent means the user agrees with what they are being asked, i.e., it encompasses reading and understanding prompts.
@@ -209,14 +229,15 @@
 of key material managed by the authenticator. 
 
 : <dfn>WebAuthn Assertion</dfn>
-:: The cryptographically signed {{WebAuthnAssertion}} object returned by an <a>authenticator</a> as the result of a <a>authenticatorGetAssertion</a> operation.
+:: The cryptographically signed {{WebAuthnAssertion}} object returned by an <a>authenticator</a> as the result of a
+<a>authenticatorGetAssertion</a> operation.
 
 : <dfn>[WAC]</dfn>
 :: See <a>Conforming User Agent</a>.
 
 : <dfn>[RP]</dfn>
-:: The entity whose web application utilizes the <a>Web Authentication API</a> to register and authenticate users. See <a>Registration</a> and <a>Authentication</a>, respectively. 
-
+:: The entity whose web application utilizes the <a>Web Authentication API</a> to register and authenticate users. See
+<a>Registration</a> and <a>Authentication</a>, respectively.
 
 
 
@@ -1055,7 +1076,7 @@
         <td>
             Extension-defined authenticator data. This is a CBOR [[RFC7049]] map with extension identifiers as keys, and
             extension authenticator data values as values. See [[#extensions]] for a description of the extension mechanism.
-            See [[#extension-standard]] for pre-defined extensions.
+            See [[#extension-predef]] for pre-defined extensions.
         </td>
     </tr>
 </table>
@@ -1161,7 +1182,8 @@
 - The Basic Constraints extension MUST have the CA component set to false
 
 - An Authority Information Access (AIA) extension with entry `id-ad-ocsp` and a CRL Distribution Point extension [[RFC5280]] are
-    both optional as the status of attestation certificates is available through the FIDO Metadata Service [[FIDOMetadataService]].
+    both optional as the status of attestation certificates is available through the FIDO Metadata Service
+    [[FIDOMetadataService]].
 
 
 #### Android Attestation (type="android") #### {#android-attestation}
@@ -1531,7 +1553,7 @@
 </pre>
 
 
-# Pre-defined extensions # {#extension-standard}
+# Pre-defined extensions # {#extension-predef}
 
 This section defines an initial set of extensions.
 
@@ -1989,7 +2011,8 @@
 
 
 # Acknowledgements # {#acknowledgements}
-We thank the following for their contributions to, and thorough review of, this specification: Jing Jin, J.C. Jones, Giridhar Mandyam.
+We thank the following for their contributions to, and thorough review of, this specification: Jing Jin, J.C. Jones, Giridhar
+Mandyam.
 
 <pre class=biblio>
 {