fix 864: Note regarding CTAP2 integer keys vs webauthn string keys (#986

)

* fix 864: added Note

* polish

* 'client' rather than 'client platform'

index.bs

@@ -137,6 +137,7 @@ spec: WHATWG HTML; urlPrefix: https://html.spec.whatwg.org/
 spec: FIDO-CTAP; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html
     type: dfn
         text: CTAP2 canonical CBOR encoding form; url: ctap2-canonical-cbor-encoding-form
+        text: §6.2. Responses; url: responses
 
 spec: FIDO-APPID; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-appid-and-facets-v2.0-id-20180227.html
     type: dfn
@@ -2217,6 +2218,8 @@ Client platforms MAY implement and expose this abstract model in any way desired
 Authentication API implementation, when operating on the authenticators supported by that platform, MUST be indistinguishable
 from the behavior specified in [[#api]].
 
+Note: [[FIDO-CTAP]] is an example of a concrete instantiation of this model, but it is one in which there are differences in the data it returns and those expected by the [[#api|WebAuthn API]]'s algorithms. The CTAP2 response messages are CBOR maps constructed using integer keys rather than the string keys defined in this specification for the same objects. The [=client=] is expected to perform any needed transformations on such data. The [[FIDO-CTAP]] specification details the mapping between CTAP2 integer keys and WebAuthn string keys, in section [=§6.2. Responses=].
+
 For authenticators, this model defines the logical operations that they MUST support, and the data formats that they expose to
 the client and the [=[WRP]=]. However, it does not define the details of how authenticators communicate with the client platform,
 unless they are necessary for interoperability with [=[RPS]=]. For instance, this abstract model does not define protocols for