Move Conformance to after Terminology

Introduce all of the specialized vocabulary first, before using it more liberally.

index.bs

@@ -501,58 +501,6 @@ A variety of additional use cases and configurations are also possible, includin
     or other financial transaction.
 
 
-# Conformance # {#sctn-conformance}
-
-This specification defines three conformance classes. Each of these classes is specified so that conforming members of the class
-are secure against non-conforming or hostile members of the other classes.
-
-## User Agents ## {#sctn-conforming-user-agents}
-
-A User Agent MUST behave as described by [[#sctn-api]] in order to be considered conformant. [=Conforming User Agents=] 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]]
-
-### Enumerations as DOMString types ### {#sct-domstring-backwards-compatibility}
-
-Enumeration types are not referenced by other parts of the Web IDL because that
-would preclude other values from being used without updating this specification
-and its implementations. It is important for backwards compatibility that
-[=client platforms=] and [=[RPS]=] handle unknown values. Enumerations for this
-specification exist here for documentation and as a registry. Where the
-enumerations are represented elsewhere, they are typed as {{DOMString}}s, for
-example in {{PublicKeyCredentialDescriptor/transports}}.
-
-## Authenticators ## {#sctn-conforming-authenticators}
-
-A [=[WAA]=] MUST provide the operations defined by [[#sctn-authenticator-model]], and those operations MUST behave as
-described there. This is a set of functional and security requirements for an authenticator to be usable by a [=Conforming User
-Agent=].
-
-As described in [[#sctn-use-cases]], an authenticator may be implemented in the operating system underlying the User Agent, or in
-external hardware, or a combination of both.
-
-### Backwards Compatibility with FIDO U2F ### {#sctn-conforming-authenticators-u2f}
-
-[=Authenticators=] that only support the [[#sctn-fido-u2f-attestation]] have no mechanism to store a
-[=user handle=], so the returned {{AuthenticatorAssertionResponse/userHandle}} will always be null.
-
-## [WRPS] ## {#sctn-conforming-relying-parties}
-
-A [=[WRP]=] MUST behave as described in [[#sctn-rp-operations]] to obtain all the security benefits offered by this specification. See
-[[#sctn-rp-benefits]] for further discussion of this.
-
-
-## All Conformance Classes ## {#sctn-conforming-all-classes}
-
-All [=CBOR=] encoding performed by the members of the above conformance classes MUST be done using the
-[=CTAP2 canonical CBOR encoding form=].
-All decoders of the above conformance classes SHOULD reject CBOR that is not validly encoded
-in the [=CTAP2 canonical CBOR encoding form=] and SHOULD reject messages with duplicate map keys.
-
-
 # Dependencies # {#sctn-dependencies}
 
 This specification relies on several other underlying specifications, listed
@@ -1000,6 +948,58 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
         a WebAuthn context may be embedded in a broader overall context, e.g., one based on OAuth.
 
 
+# Conformance # {#sctn-conformance}
+
+This specification defines three conformance classes. Each of these classes is specified so that conforming members of the class
+are secure against non-conforming or hostile members of the other classes.
+
+## User Agents ## {#sctn-conforming-user-agents}
+
+A User Agent MUST behave as described by [[#sctn-api]] in order to be considered conformant. [=Conforming User Agents=] 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]]
+
+### Enumerations as DOMString types ### {#sct-domstring-backwards-compatibility}
+
+Enumeration types are not referenced by other parts of the Web IDL because that
+would preclude other values from being used without updating this specification
+and its implementations. It is important for backwards compatibility that
+[=client platforms=] and [=[RPS]=] handle unknown values. Enumerations for this
+specification exist here for documentation and as a registry. Where the
+enumerations are represented elsewhere, they are typed as {{DOMString}}s, for
+example in {{PublicKeyCredentialDescriptor/transports}}.
+
+## Authenticators ## {#sctn-conforming-authenticators}
+
+A [=[WAA]=] MUST provide the operations defined by [[#sctn-authenticator-model]], and those operations MUST behave as
+described there. This is a set of functional and security requirements for an authenticator to be usable by a [=Conforming User
+Agent=].
+
+As described in [[#sctn-use-cases]], an authenticator may be implemented in the operating system underlying the User Agent, or in
+external hardware, or a combination of both.
+
+### Backwards Compatibility with FIDO U2F ### {#sctn-conforming-authenticators-u2f}
+
+[=Authenticators=] that only support the [[#sctn-fido-u2f-attestation]] have no mechanism to store a
+[=user handle=], so the returned {{AuthenticatorAssertionResponse/userHandle}} will always be null.
+
+## [WRPS] ## {#sctn-conforming-relying-parties}
+
+A [=[WRP]=] MUST behave as described in [[#sctn-rp-operations]] to obtain all the security benefits offered by this specification. See
+[[#sctn-rp-benefits]] for further discussion of this.
+
+
+## All Conformance Classes ## {#sctn-conforming-all-classes}
+
+All [=CBOR=] encoding performed by the members of the above conformance classes MUST be done using the
+[=CTAP2 canonical CBOR encoding form=].
+All decoders of the above conformance classes SHOULD reject CBOR that is not validly encoded
+in the [=CTAP2 canonical CBOR encoding form=] and SHOULD reject messages with duplicate map keys.
+
+
 # <dfn>Web Authentication API</dfn> # {#sctn-api}
 
 This section normatively specifies the API for creating and using [=public key credentials=]. The basic