From 200d14abeeee5a7257681913355e3d1008883d09 Mon Sep 17 00:00:00 2001 From: Rolf Lindemann Date: Wed, 14 Sep 2016 13:48:12 +0200 Subject: [PATCH] more corrections --- index.bs | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index fac73a83e..b2e3f17ab 100644 --- a/index.bs +++ b/index.bs @@ -493,7 +493,7 @@ authorizing an authenticator with which to complete the operation. The publicKey attribute contains the public key associated with the credential, represented as a CryptoKey object as defined in [[WebCryptoAPI#cryptokey-interface]]. - The attestation attribute contains a key attestation statement returned by the authenticator. This provides + The attestation attribute contains an attestation statement returned by the authenticator. This provides information about the credential and the authenticator it is held in, such as the level of security assurance provided by the authenticator. @@ -582,7 +582,7 @@ authorizing an authenticator with which to complete the operation. -## WebAuthn Assertion (interface WebAuthnAssertion) ## {#iface-assertion} +## WebAuthnAssertion Interface ## {#iface-assertion} 
     interface WebAuthnAssertion {
@@ -650,14 +650,14 @@ If the caller wants to pass extensions to the platform, it SHOULD do so by addin
 with the extension identifier as the key, and the extension's value as the value (see [[#signature-format]] for details).
 
 
-## Credential Attestation Statement (interface WebAuthnAttestation) ## {#iface-attestation}
+## WebAuthnAttestation Interface ## {#iface-attestation}
 
 
     interface WebAuthnAttestation {
         readonly    attribute USVString     format;
         readonly    attribute ArrayBuffer   clientData;
         readonly    attribute ArrayBuffer   level2Data; // was authenticatorData
-        readonly    attribute any           level1Data;  // was statement
+        readonly    attribute any           level1Data; // was statement
     };
 

 
@@ -683,7 +683,7 @@ providing provenance information for the attesting key, enabling a trust decisio
 
 This attestation statement is delivered to the [RP] by the [RP]'s script running on the client, using methods outside
 the scope of this specification. It contains all the information that the [RP]'s server requires to validate the level1Data, as
-well as to decode and validate the bindings of both the client and authenticator data.
+well as to decode and validate the bindings of both the client and level2Data.
 
 
 ## Supporting Data Structures ## {#supporting-data-structures}
@@ -936,20 +936,22 @@ The goals of this design can be summarized as follows.
 - The design aims to reuse as much as possible of existing encoding formats in order to aid adoption and implementation.
 
 The contextual bindings are divided in two: Those added by the RP or the client platform, referred to as client data; and those
-added by the authenticator, referred to as the authenticator data. The client data must be signed over, but an authenticator is
+added by the authenticator, referred to as the level2Data. The client data must be signed over, but an authenticator is
 otherwise not interested in its contents. To save bandwidth and processing requirements on the authenticator, the client
 platform hashes the {{ClientData}} and sends only the result to the authenticator. The authenticator signs over the combination
 of this clientDataHash, and its own authenticator data.
 
 
-### Authenticator data ### {#sec-authenticator-data}
+### Level2Data ### {#sec-authenticator-data}
 
-The authenticator data encodes contextual bindings made by the authenticator itself. These bindings are controlled
+The level2Data encodes contextual bindings made by the authenticator itself. These bindings are typically controlled
 (generated or at least verified) by the authenticator itself, and derive their trust from the [RP]'s assessment of the security
 of the authenticator. The authenticator data has a compact but extensible encoding. This is desired since authenticators can be
 devices with limited capabilities and low power requirements, with much simpler software stacks than the client platform
 components.
 
+Note: It depends on the auhenticator metadata whether level2Data is controlled by the authenticator or by the Client.
+
 The encoding of authenticator data is a byte array of 37 bytes or more, as follows.
 
 
@@ -987,7 +989,7 @@ The encoding of authenticator data is a byte array of 37 bytes or more, as follo
     
@@ -1088,7 +1090,7 @@ MUST return clientDataJSON, level2Data and the signature to the RP
 `clientData` and `level2Data` members respectively of the {{WebAuthnAssertion}} and {{WebAuthnAttestation}} structures.
 
 
-## Credential Attestation Statements ## {#cred-attestation-stmts}
+## Attestation Statements ## {#cred-attestation-stmts}
 
 An attestation statement is a specific type of signed data object, containing statements about a credential itself and the
 authenticator that created it. It is created using the process described in [[#signature-format]], with the important difference


         variable (if present)
         
-            Extension-defined authenticator data. This is a CBOR [[RFC7049]] map with extension identifiers as keys, and
+            Extension-defined level2Data. This is a CBOR [[RFC7049]] map with extension identifiers as keys, and
             extension authenticator data values as values. See [[#extensions]] for details.