From 62b67c02a37ab54ca8b3c1f7606bb7351298ddec Mon Sep 17 00:00:00 2001 From: Vijay Bharadwaj Date: Wed, 31 Aug 2016 10:10:01 -0700 Subject: [PATCH 1/7] Cleaned up exposition of processing rules (#154) * Replace facet with origin Facet was a holdover from the old FIDO specs and origin is the term used everywhere in this spec (as well as in recent FIDO specs) * Clean up explanation of computing clientDataHash and passing to authenticator Fixes #153 * Remove text from authnsel extension to avoid chicken-and-egg problem Fixes #152 * Address comments from @equalsJeffH --- index.bs | 259 +++++++++++++++++++++++++++---------------------------- 1 file changed, 128 insertions(+), 131 deletions(-) diff --git a/index.bs b/index.bs index e5f030649..05cc15006 100644 --- a/index.bs +++ b/index.bs @@ -127,7 +127,7 @@ or a combination of both. This specification relies on several other underlying specifications. : HTML5 -:: The concept of origin and the Navigator/dfn> interface are defined in [[!HTML5]]. +:: The concept of origin and the Navigator/dfn> interface are defined in [[!HTML5]]. : Web IDL :: Many of the interface definitions and all of the IDL in this specification depend on [[!WebIDL-1]]. This updated version of @@ -386,22 +386,19 @@ This method takes the following parameters: When this method is invoked, the user agent MUST execute the following algorithm: -1. If timeoutSeconds was specified, check if its value lies within a reasonable range as defined - by the platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted - value. If timeoutSeconds was not specified then set |adjustedTimeout| to a platform-specific - default. +1. If {{CredentialOptions/timeoutSeconds}} was specified, check if its value lies within a reasonable range as defined by the + platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted value. + If {{CredentialOptions/timeoutSeconds}} was not specified then set |adjustedTimeout| to a platform-specific default. 2. Let |promise| be a new Promise. Return |promise| and start a timer for |adjustedTimeout| seconds. Then asynchronously continue executing the following steps. -3. Set |callerOrigin| to the origin of the caller. Derive the RP ID from |callerOrigin| by computing the +3. Set |callerOrigin| to the origin of the caller. Derive the RP ID from |callerOrigin| by computing the "public suffix + 1" or "PS+1" (which is also referred to as the "Effective Top-Level Domain plus One" or "eTLD+1") - part of |callerOrigin| [[PSL]]. Set |rpIdHash| to the SHA-256 hash of the UTF-8 encoding of the lowercase form of this RP - ID. + part of |callerOrigin| [[PSL]]. Let |rpId| be the lowercase form of this RP ID. Set |rpIdHash| to the SHA-256 hash of the + UTF-8 encoding of |rpId|. -4. Initialize |issuedRequests| to an empty list. - -5. Process each element of cryptoParameters using the following steps, to produce a new sequence `normalizedParameters`: +4. Process each element of cryptoParameters using the following steps, to produce a new sequence `normalizedParameters`: - Let |current| be the currently selected element of cryptoParameters. - If `current.type` does not contain a {{CredentialType}} supported by this implementation, then stop processing |current| and move on to the next element in cryptoParameters. @@ -411,17 +408,22 @@ When this method is invoked, the user agent MUST execute the following algorithm - Add a new object of type {{ScopedCredentialParameters}} to `normalizedParameters`, with |type| set to `current.type` and |algorithm| set to `normalizedAlgorithm`. -6. If excludeList is undefined, set it to the empty list. +5. If excludeList is undefined, set it to the empty list. + +6. If {{CredentialOptions/extensions}} was specified, process any extensions supported by this client platform, to produce the + extension data that needs to be sent to the authenticator. Call this data |clientExtensions|. -7. If extensions was specified, process any extensions supported by this client platform, to - produce the extension data that needs to be sent to the authenticator. Call this data |clientExtensions|. +7. Use {{attestationChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin| (if + any), to create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and + compute the clientDataJSON and clientDataHash. + +8. Initialize |issuedRequests| to an empty list. -8. For each authenticator currently available on this platform: asynchronously invoke the - authenticatorMakeCredential operation on that authenticator with |callerOrigin|, |rpIdHash|, - accountInformation, `normalizedParameters`, excludeList, attestationChallenge and |clientExtensions| as - parameters. Add a corresponding entry to |issuedRequests|. +9. For each authenticator currently available on this platform: asynchronously invoke the authenticatorMakeCredential + operation on that authenticator with |rpIdHash|, clientDataHash, accountInformation, `normalizedParameters`, + excludeList and |clientExtensions| as parameters. Add a corresponding entry to |issuedRequests|. -9. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses +10. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses from the authenticators: - If the |adjustedTimeout| timer expires, then for each entry in |issuedRequests| invoke the authenticatorCancel operation on that authenticator and remove its entry from the list. @@ -432,7 +434,7 @@ When this method is invoked, the user agent MUST execute the following algorithm - If any authenticator indicates success: - Remove this authenticator's entry from |issuedRequests|. - Create a new {{ScopedCredentialInfo}} object named |value| and populate its fields with the values returned from the - authenticator. + authenticator as well as the clientDataJSON computed earlier. - For each remaining entry in |issuedRequests| invoke the authenticatorCancel operation on that authenticator and remove its entry from the list. - Resolve |promise| with |value| and terminate this algorithm. @@ -460,35 +462,39 @@ This method takes the following parameters: When this method is invoked, the user agent MUST execute the following algorithm: -1. If timeoutSeconds was specified, check if its value lies within a reasonable range as defined - by the platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted - value. If timeoutSeconds was not specified then set |adjustedTimeout| to a platform-specific - default. +1. If {{AssertionOptions/timeoutSeconds}} was specified, check if its value lies within a reasonable range as defined by the + platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted value. + If {{AssertionOptions/timeoutSeconds}} was not specified then set |adjustedTimeout| to a platform-specific default. 2. Let |promise| be a new Promise. Return |promise| and start a timer for |adjustedTimeout| seconds. Then asynchronously continue executing the following steps. -3. Set |callerOrigin| to the origin of the caller. Derive the RP ID from |callerOrigin| by computing the +3. Set |callerOrigin| to the origin of the caller. Derive the RP ID from |callerOrigin| by computing the "public suffix + 1" or "PS+1" (which is also referred to as the "Effective Top-Level Domain plus One" or "eTLD+1") - part of |callerOrigin| [[PSL]]. Set |rpIdHash| to the SHA-256 hash of the UTF-8 encoding of the lowercase form of this RP - ID. - -4. Initialize |issuedRequests| to an empty list. - -5. If extensions was specified, process any extensions supported by this client platform, to - produce the extension data that needs to be sent to the authenticator. Call this data |clientExtensions|. - -6. For each authenticator currently available on this platform, perform the following steps: - - If allowList is undefined or empty, let |credentialList| be a list containing a single wildcard entry. Otherwise, - execute a platform-specific procedure to determine which of these credentials might be present on this authenticator, - and set |credentialList| to this filtered list. - - - If |credentialList| is empty, ignore this authenticator and do not perform any of the following per-authenticator steps. - - Asynchronously invoke the authenticatorGetAssertion operation on this authenticator with |callerOrigin|, - |rpIdHash|, assertionChallenge, |credentialList|, and |clientExtensions| as parameters. + part of |callerOrigin| [[PSL]]. Let |rpId| be the lowercase form of this RP ID. Set |rpIdHash| to the SHA-256 hash of the + UTF-8 encoding of |rpId|. + +4. If {{AssertionOptions/extensions}} was specified, process any extensions supported by this client platform, to produce the + extension data that needs to be sent to the authenticator. Call this data |clientExtensions|. + +5. Use {{assertionChallenge}}, |callerOrigin| and |rpId|, along with the token binding key associated with |callerOrigin| (if + any), to create a {{ClientData}} structure representing this request. Choose a hash algorithm for {{ClientData/hashAlg}} and + compute the clientDataJSON and clientDataHash. + +6. Initialize |issuedRequests| to an empty list. + +7. For each authenticator currently available on this platform, perform the following steps: + - If allowList is undefined or empty, let |credentialList| be an empty list. Otherwise, execute a platform-specific + procedure to determine which, if any, credentials listed in allowList might be present on this authenticator, and + set |credentialList| to this filtered list. If no such filtering is possible, set |credentialList| to an empty list. + - If the above filtering process concludes that none of the credentials on allowList can possibly be on this + authenticator, do not perform any of the following steps for this authenticator, and proceed to the next authenticator + (if any). + - Asynchronously invoke the authenticatorGetAssertion operation on this authenticator with |rpIdHash|, + clientDataHash, |credentialList|, and |clientExtensions| as parameters. - Add an entry to |issuedRequests|, corresponding to this request. -7. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses +8. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses from the authenticators: - If the timer for |adjustedTimeout| expires, then for each entry in |issuedRequests| invoke the authenticatorCancel operation on that authenticator and remove its entry from the list. @@ -499,12 +505,12 @@ When this method is invoked, the user agent MUST execute the following algorithm - If any authenticator returns success: - Remove this authenticator's entry from |issuedRequests|. - Create a new {{WebAuthnAssertion}} object named |value| and populate its fields with the values returned from the - authenticator. + authenticator as well as the clientDataJSON computed earlier. - For each remaining entry in |issuedRequests| invoke the authenticatorCancel operation on that authenticator and remove its entry from the list. - Resolve |promise| with |value| and terminate this algorithm. -8. Resolve |promise| with a DOMException whose name is "NotFoundError", and terminate this algorithm. +9. Resolve |promise| with a DOMException whose name is "NotFoundError", and terminate this algorithm. During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and authorizing an authenticator with which to complete the operation. @@ -642,7 +648,7 @@ providing provenance information for the attesting key, enabling a trust decisio later versions of this specification. The clientData member contains the clientDataJSON (see [[#signature-format]]). The exact JSON encoding - must be preserved as the hash (clientDataHash) has been computed over it. + must be preserved as the hash (clientDataHash) has been computed over it. The statement element contains the actual attestation statement. The structure of this object depends on the attestation format. For more details, see [[#attestation]]. @@ -658,6 +664,51 @@ well as to decode and validate the bindings of both the client and authenticator The scoped credential type uses certain data structures that are specified in supporting specifications. These are as follows. +### Client data used in WebAuthn signatures (dictionary ClientData) ### {#sec-client-data} + +The client data represents the contextual bindings of both the [RP] and the client platform. It is a key-value mapping with +string-valued keys. Values may be any type that has a valid encoding in JSON. Its structure is defined by the following Web IDL. + +
+    dictionary ClientData {
+        required DOMString           challenge;
+        required DOMString           origin;
+        required DOMString           rpId;
+        required AlgorithmIdentifier hashAlg;
+        JsonWebKey                   tokenBinding;
+        WebAuthnExtensions           extensions;
+    };
+
+ +
+ The challenge member contains the base64url encoding of the challenge provided by the RP. + + The origin member contains the fully qualified web origin of the requester, as provided to the authenticator by + the client, in the syntax defined by [[RFC6454]]. + + The rpId member contains the RP ID of the requester, as computed by the client. + + The hashAlg member specifies the hash algorithm used to compute clientDataHash (see + [[#authenticator-signature]]). Use "S256" for SHA-256, "S384" for SHA384, "S512" for SHA512, and "SM3" for SM3 (see + [[#iana-considerations]]). This algorithm is chosen by the client at its sole discretion. + + The tokenBinding member contains a JsonWebKey object as defined by [[WebCryptoAPI#JsonWebKey-dictionary]] + describing the public key that this client uses for the Token Binding protocol when communicating with the [RP]. This can be + omitted if no Token Binding has been negotiated between the client and the [RP]. + + The optional extensions member contains additional parameters generated by processing the extensions passed in + by the [RP]. WebAuthn extensions are detailed in Section [[#extensions]]. +
+ +This structure is used by the client to compute the following quantities: + +: clientDataJSON +:: This is the UTF-8 encoded JSON serialization [[RFC7159]] of a {{ClientData}} dictionary. + +: clientDataHash +:: This is the hash (computed using hashAlg) of clientDataJSON. + + ### Credential Type enumeration (enum CredentialType) ### {#credentialType}
@@ -731,15 +782,13 @@ The following operations can be invoked by the client in an authenticator sessio This operation must be invoked in an authenticator session which has no other operations in progress. It takes the following input parameters: -- The web origin of the script on whose behalf the operation is being initiated, as determined by the user agent and the client. -- The SHA-256 hash of the RP ID corresponding to the above web origin, as determined by the user agent and the client. +- The SHA-256 hash of the caller's RP ID, as determined by the user agent and the client. +- The clientDataHash, which is the hash of the serialized {{ClientData}} and is provided by the client. - The {{Account}} information provided by the [RP]. -- The {{CredentialType}} requested by the [RP]. -- The cryptographic parameters requested by the [RP], with the cryptographic algorithms normalized as per the procedure in - [[WebCryptoAPI#algorithm-normalization-normalize-an-algorithm]]. +- The {{CredentialType}} and cryptographic parameters requested by the [RP], with the cryptographic algorithms normalized as per + the procedure in [[WebCryptoAPI#algorithm-normalization-normalize-an-algorithm]]. - A list of {{Credential}} objects provided by the [RP] with the intention that, if any of these are known to the authenticator, it should not create a new credential. -- A challenge provided by the [RP] to assure freshness of the attestation statement of the new credential. - Extension data created by the client based on the extensions requested by the [RP]. When this operation is invoked, the authenticator obtains user consent for creating a new credential. The prompt for obtaining @@ -765,9 +814,8 @@ If the user refuses consent, the authenticator returns an appropriate error stat This operation must be invoked in an authenticator session which has no other operations in progress. It takes the following input parameters: -- The web origin of the script on whose behalf the operation is being initiated, as determined by the user agent and the client. -- The RP ID hash corresponding to the above web origin, as determined by the user agent and the client. -- A challenge provided by the [RP] to assure freshness of the assertion produced. +- The SHA-256 hash of the caller's RP ID, as determined by the user agent and the client. +- The clientDataHash, which is the hash of the serialized {{ClientData}} and is provided by the client. - A list of credentials acceptable to the [RP] (possibly filtered by the client). - Extension data created by the client based on the extensions requested by the [RP]. @@ -837,45 +885,8 @@ The goals of this design can be summarized as follows. 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 otherwise not interested in its contents. To save bandwidth and processing requirements on the authenticator, the client -platform hashes the client data and sends only the result to the authenticator. The authenticator signs over the combination of -this hash, and its own authenticator data. - - -### Client data used in WebAuthn signatures (dictionary ClientData) ### {#sec-client-data} - -The client data represents the contextual bindings of both the [RP] and the client platform. It is a key-value mapping with -string-valued keys. Values may be any type that has a valid encoding in JSON. Its structure is defined by the following Web IDL. - -
-    dictionary ClientData {
-        required DOMString           challenge;
-        required DOMString           facet;
-        required DOMString           rpId;
-        required AlgorithmIdentifier hashAlg;
-        JsonWebKey                   tokenBinding;
-        WebAuthnExtensions           extensions;
-    };
-
- -
- The challenge member contains the base64url encoding of the challenge provided by the RP. - - The facet member contains the fully qualified web origin of the requester, as provided to the authenticator by - the client, in the syntax defined by [[RFC6454]]. - - The rpId member contains the RP ID of the requester, as computed by the client. - - The hashAlg member specifies the hash algorithm used to compute clientDataHash (see - [[#authenticator-signature]]). Use "S256" for SHA-256, "S384" for SHA384, "S512" for SHA512, and "SM3" for SM3 (see - [[#iana-considerations]]). - - The tokenBinding member contains a JsonWebKey object as defined by [[WebCryptoAPI#JsonWebKey-dictionary]] - describing the public key that this client uses for the Token Binding protocol when communicating with the [RP]. This can be - omitted if no Token Binding has been negotiated between the client and the [RP]. - - The optional extensions member contains additional parameters generated by processing the extensions passed in - by the [RP]. WebAuthn extensions are detailed in Section [[#extensions]]. -
+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} @@ -924,9 +935,9 @@ generated. However, it differs from other client data in some important ways. Fi credential does not change between operations but instead remains the same for the lifetime of that credential. Secondly, it is validated by the authenticator during the authenticatorGetAssertion operation, by making sure that the RP ID hash associated with the requested credential exactly matches the RP ID hash supplied by the client. These differences also explain -why the RP ID hash is always a SHA-256 hash instead of being crypto-agile like the |clientDataHash|; for a given RP ID, we need -the hash to be computed the same way by all clients for all operations so that authenticators can move between clients without -losing interoperability. +why the RP ID hash is always a SHA-256 hash instead of being crypto-agile like the clientDataHash; for a given RP ID, we +need the hash to be computed the same way by all clients for all operations so that authenticators can roam among clients +without losing interoperability. The `TUP` flag SHALL be set if and only if the authenticator detected a user through an authenticator specific gesture. The `RFU` bits in the flags byte SHALL be set to zero. @@ -947,22 +958,8 @@ it is 37 bytes plus the CBOR map that follows. ### Generating a signature ### {#authenticator-signature} -Before making a request to an authenticator, the client platform layer SHALL perform the following steps. - -1. Represent the parameters passed in by the RP in the form of a {{ClientData}} structure. - -2. Let clientDataJSON be the UTF-8 encoded JSON serialization [[RFC7159]] of this ClientData dictionary. - -3. Let clientDataHash be the hash (computed using hashAlg) of clientDataJSON, as an array. - -The |clientDataHash| value is delivered to the authenticator. - -The hash algorithm hashAlg used to compute clientDataHash is included in the {{ClientData}} object. This way it -is available to the [RP] and it is also hashed over when computing clientDataHash and hence anchored in the signature -itself. - A raw cryptographic signature must assert the integrity of both the client data and the authenticator data. Thus, an -authenticator SHALL compute a signature over the concatenation of the |authenticatorData| and the |clientDataHash|. +authenticator SHALL compute a signature over the concatenation of the |authenticatorData| and the clientDataHash.
@@ -970,7 +967,7 @@ A raw cryptographic signature must assert the integrity of both the client data
Note: A simple, undelimited concatenation is safe to use here because the |authenticatorData| describes its own length. The - |clientDataHash| (which potentially has a variable length) is always the last element. + clientDataHash (which potentially has a variable length) is always the last element. The authenticator MUST return both the authenticatorData and the raw signature back to the client. The client, in turn, MUST return clientDataJSON, authenticatorData and the signature to the RP. The clientDataJSON is returned @@ -1069,7 +1066,7 @@ Upon receiving an attestation statement, the [RP] shall: - Verify `rawData` syntax and that it doesn't contradict the signing algorithm specified in `alg`. - The DAA root key is dedicated to a single Authenticator model. -4. Verify the contextual bindings (e.g., channel binding) from the clientData (see [[#authenticator-signature]]). +4. Verify the contextual bindings (e.g., token binding) from the `clientData` (see [[#authenticator-signature]]). 5. Verify that user verification method and other authenticator characteristics related to this authenticator model, match the [RP] policy. The FIDO Metadata Service [[FIDOMetadataService]] provides an easy way to access the authenticator @@ -1189,8 +1186,8 @@ A Packed Attestation statement has the following format: The alg element contains the name of the algorithm used to generate the attestation signature according to [[!RFC7518]] section 3.1. - The rawData object contains the attested public key and the |clientDataHash|. See [[#sec-raw-data-packed]] for - details. + The rawData object contains the attested public key and the clientDataHash. See [[#sec-raw-data-packed]] + for details. The signature element contains the attestation signature. See [[#packed-attestation-signature]] for details.
@@ -1274,13 +1271,13 @@ arranged as given below: 2 - Byte length n of clientDataHash + Byte length n of clientDataHash n - clientDataHash (see [[#authenticator-signature]]). This is the hash of `clientDataJSON`. The hash algorithm itself - is stored in the `clientData` object [[#signature-format]]. + clientDataHash (see [[#authenticator-signature]]). This is the hash of clientDataJSON. The hash + algorithm itself is stored in the {{ClientData}} object [[#signature-format]]. @@ -1366,7 +1363,7 @@ if `version` equals 1. Else, if `version` equals 2, it MUST be a TPMS_ATTEST str 10.12.9. The field "extraData" (in the case of TPMS_ATTEST) or the field "data" (in the case of TPM_CERTIFY_INFO or TPM_CERTIFY_INFO2) -MUST contain the `clientDataHash` (see [[#signature-format]]). +MUST contain the clientDataHash (see [[#signature-format]]). ### Signature ### {#tpm-attestation-signature} @@ -1439,7 +1436,7 @@ This type of attestation statement is formatted as follows: ### Signature ### {#sec-android-attestation-signature} -For this attestation format, the ClientData dictionary is extended in the following way: +For this attestation format, the {{ClientData}} dictionary is extended in the following way: 
     dictionary AndroidAttestationClientData : ClientData {
@@ -1470,24 +1467,25 @@ For this attestation format, the ClientData dictionary is extended in the follow
         this key is authorized to be used after the user is successfully authenticated.
 
 
-In order to generate an attestation statement, the client MUST create clientDataJSON by UTF8-encoding a structure of type
-AndroidAttestationClientData, and compute clientDataHash as the hash of clientDataJSON. It must then provide clientDataHash as
-the Nonce value when requesting the SafetyNet attestation.
+In order to generate an attestation statement, the client MUST create clientDataJSON by UTF8-encoding a structure of type
+{{AndroidAttestationClientData}}, and compute clientDataHash as the hash of clientDataJSON. It must then provide
+clientDataHash as the Nonce value when requesting the SafetyNet attestation.
 
 
 ### Verifying AndroidClientData specific contextual bindings ### {#verifying-android-contextual-bindings}
 
-A [RP] shall verify the clientData contextual bindings (see step 4 in [[#verifying-an-attestation-statement]]) as follows:
+A [RP] shall verify the {{ClientData}} contextual bindings (see step 4 in [[#verifying-an-attestation-statement]]) as follows:
 
 - Check that `AndroidAttestationClientData.challenge` equals the attestationChallenge that was passed into the
     {{makeCredential()}} call.
 
-- Check that the `facet` and `tokenBinding` parameters in the `AndroidAttestationClientData` match the [RP] App.
+- Check that the {{ClientData/origin}} and {{ClientData/tokenBinding}} parameters in the `AndroidAttestationClientData` match
+    the [RP] App.
 
 - Check that `AndroidAttestationClientData.publicKey` is the same key as the one returned in the `ScopedCredentialInfo` by the
     `makeCredential` call.
 
-- Check that the hash of the clientDataJSON matches the `nonce` attribute in the payload of the `safetynetResponse` JWS.
+- Check that the hash of the clientDataJSON matches the `nonce` attribute in the payload of the `safetynetResponse` JWS.
 
 - Check that the `ctsProfileMatch` attribute in the payload of the `safetynetResponse` is true.
 
@@ -1571,8 +1569,8 @@ in the {{getAssertion()}} or {{makeCredential()}} call, while the authentic
 to the authenticator during the processing of these calls.
 
 A [RP] simultaneously requests the use of an extension and sets its client argument by including an entry in the
-extensions option to the {{makeCredential()}} or {{getAssertion()}} call. The entry key MUST be
-the extension identifier, and the value MUST be the client argument.
+{{CredentialOptions/extensions}} option to the {{makeCredential()}} or {{getAssertion()}} call. The entry key MUST be the
+extension identifier, and the value MUST be the client argument.
 
 
     var assertionPromise = credentials.getAssertion(..., /* extensions */ {
@@ -1601,7 +1599,7 @@ value that the [RP] needs to be aware of, the extension should specify a client
 structure.
 
 The client data value may be any value that can be encoded using JSON. If any extension processed by a client defines such a
-value, the client SHOULD include a dictionary in {{ClientData}} with the key extensions. For each such
+value, the client SHOULD include a dictionary in {{ClientData}} with the key {{ClientData/extensions}}. For each such
 extension, the client SHOULD add an entry to this dictionary with the extension identifier as the key, and the extension's
 client data value.
 
@@ -1758,8 +1756,7 @@ credential. It is intended primarily for [RPS] that wish to tightly control the
 :: This extension can only be used during {{makeCredential()}}. If the client supports the Authenticator Selection Extension, it
     MUST use the first available authenticator whose AAGUID is present in the AuthenticatorSelectionList. If none of
     the available authenticators match a provided AAGUID, the client MUST select an authenticator from among the available
-    authenticators to generate the credential. If an authenticator was selected from {{AuthenticatorSelectionList}}, its
-    AAGUID MUST be added by the client to the ClientData as the client data value for this extension.
+    authenticators to generate the credential.
 
 : Authenticator argument
 :: There is no authenticator argument.

From a7817009bf82bd1ef3bca7d7c05ab3c88a3f2738 Mon Sep 17 00:00:00 2001
From: gmandyam 
Date: Wed, 31 Aug 2016 10:14:35 -0700
Subject: [PATCH 2/7] Update index.bs with proposed location extension (#157)

* Update index.bs

* Update index.bs

* Update index.bs

* Update index.bs
---
 index.bs | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/index.bs b/index.bs
index 05cc15006..ca6694b3f 100644
--- a/index.bs
+++ b/index.bs
@@ -1837,7 +1837,53 @@ credential. It is intended primarily for [RPS] that wish to tightly control the
                 82
     

 
+## Location Extension ## {#uvi-location}
 
+: Extension identifier
+:: `webauthn_loc`
+
+: Client argument
+:: The Boolean value `true` to indicate that this extension is requested by the [RP].
+
+: Client processing
+:: None, except default forwarding of client argument to authenticator argument.
+
+: Authenticator argument
+:: The Boolean value `true`, encoded in CBOR (major type 7, value 21).
+
+: Authenticator processing
+:: If the authenticator does not support the extension, then the authenticator MUST ignore the extension request.  
+    If the authenticator accepts the extension, then the authenticator SHOULD only add this extension data to a packed 
+    attestation or assertion.
+
+: Authenticator data
+:: If the authenticator accepts the extension request, then authenticator data SHOULD provide location data in the form of a 
+    CBOR-encoded map, with the first value being the extension identifier and the second being an array of returned values.  The array 
+    elements SHOULD be derived from (key,value) pairings for each location attribute that the authenticator supports. The following is 
+    an example of authenticator data where the returned array is comprised of a {longitude, latitude, altitude} triplet, following the
+    coordinate representation defined in The W3C Geolocation API
+    Specification.
+
+    
+        F1 D0                                       -- This is a WebAuthn packed rawData object
+        81                                          -- TUP and ED set
+        00 00 00 01                                 -- (initial) signature counter
+        ...                                         -- all public key alg etc.
+        A1                                          -- extension: CBOR map of one element
+            6C                                      -- Value 1: CBOR text string of 11 bytes
+                77 65 62 61 75 74 68 6E 5F 6C 6F 63 -- "webauthn_loc" UTF-8 string
+            86                                      -- Value 2: array of 6 elements
+                68				    -- Element 1:  CBOR text string of 8 bytes
+                   6C 61 74 69 74 75 64 65          -- “latitude” UTF-8 string
+                FB ...				    -- Element 2:  Latitude as CBOR encoded double-precision float
+                69				    -- Element 3:  CBOR text string of 9 bytes
+                   6C 6F 6E 67 69 74 75 64 65       -- “longitude” UTF-8 string
+                FB ...				    -- Element 4:  Longitude as CBOR encoded double-precision float
+                68				    -- Element 5:  CBOR text string of 8 bytes
+                  61 6C 74 69 74 75 64 65           -- “altitude” UTF-8 string
+                FB ...				    -- Element 6:  Altitude as CBOR encoded double-precision float
+    

+    
 # IANA Considerations # {#iana-considerations}
 
 This specification registers the algorithm names "S256", "S384", "S512", and "SM3" with the IANA JSON Web Algorithms registry as

From b6a2790a029263f3b5763e8d76771e57c1dadde3 Mon Sep 17 00:00:00 2001
From: Rahul Ghosh 
Date: Thu, 1 Sep 2016 08:39:20 -0700
Subject: [PATCH 3/7] =?UTF-8?q?Adding=20the=20User=20Verification=20Mode?=
 =?UTF-8?q?=20extension=20as=20per=20discussions=20in=20the=E2=80=A6=20(#1?=
 =?UTF-8?q?69)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* Adding the User Verification Mode extension as per discussions in the WG weekly metings. After a lot of thought I retained the sub-array instead of converting the sub-items in the extension to a map. This was primarily to avoid having to define string based keys that increases the size of the extension. Given that the array is well defined I think it keeps it easier to process in software and extendable for future additions as well.

* Cleaned up exposition of processing rules (#154)

* Replace facet with origin

Facet was a holdover from the old FIDO specs and origin is the term used
everywhere in this spec (as well as in recent FIDO specs)

* Clean up explanation of computing clientDataHash and passing to authenticator

Fixes #153

* Remove text from authnsel extension to avoid chicken-and-egg problem

Fixes #152

* Address comments from @equalsJeffH

* Update index.bs with proposed location extension (#157)

* Update index.bs

* Update index.bs

* Update index.bs

* Update index.bs

* Adding the User Verification Mode extension as per discussions in the WG weekly metings. After a lot of thought I retained the sub-array instead of converting the sub-items in the extension to a map. This was primarily to avoid having to define string based keys that increases the size of the extension. Given that the array is well defined I think it keeps it easier to process in software and extendable for future additions as well.

* fixing another merge issue with uvm extension being repeated following upstream merge
---
 index.bs | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/index.bs b/index.bs
index ca6694b3f..9b1c194f1 100644
--- a/index.bs
+++ b/index.bs
@@ -1,4 +1,4 @@
-
+
  Title: Web Authentication: An API for accessing Scoped Credentials
 Status: ED
 TR: http://www.w3.org/TR/webauthn/
@@ -1884,6 +1884,71 @@ credential. It is intended primarily for [RPS] that wish to tightly control the
                 FB ...				    -- Element 6:  Altitude as CBOR encoded double-precision float
     

     
+
+## User Verification Mode (UVM) Extension ## {#uvm-extension}
+
+: Extension identifier
+:: `webauthn_uvm`
+
+: Client argument
+:: The Boolean value true to indicate that this extension is requested by the WebAuthn Relying Party.
+
+: Client processing
+:: None, except default forwarding of client argument to authenticator argument.
+
+: Authenticator argument
+:: The Boolean value `true`, encoded in CBOR (major type 7, value 21).
+
+: Authenticator processing
+:: The authenticator augments the authenticator data with a user verification index indicating the method used by the
+    user to authorize the operation, as defined below. This extension can be added to attestation statements and assertions.
+
+: Authenticator data
+:: Authenticators can report up to 3 different user verification methods (factors) used in a single authentication instance. 
+    To accommodate this possibility the UVM is encoded as CBOR array (major type 4) with a maximum allowed length of 3 -
+    * Type 0x81 – only 1 factor was used for authentication.
+    * Type 0x82 – 2 factors were used.
+    * Type 0x83 – 3 or more factors were used. 
+    
+    Each data item is in turn a CBOR array of length 3 (type 0x83) with the following data items:
+    - Data Item 1 – User Verification Method. This is the authentication method/factor used by the authenticator to verify 
+                    the user. Available values are defined in the FIDO Registry of Predefined Values, ‘User Verification 
+                    Methods’ section. It is encoded as a CBOR unsigned integer (Major type 0).
+    - Data Item 2 – Key Protection Type. This is the method used by the authenticator to protect the FIDO registration 
+                    private key material. Available values are defined in the FIDO Registry of Predefined Values, ‘Key 
+                    Protection Types’ section. It is encoded as a CBOR 2 byte unsigned short (Major type 0).
+    - Data Item 3 – Matcher Protection Type. This is the method used by the authenticator to protect the matcher that 
+		    performs user verification. Available values are defined in the FIDO Registry of Predefined Values, 
+		    ‘Matcher Protection Types’ section. It is encoded as a CBOR 2 byte unsigned short (Major type 0).
+
+    This is repeated for each factor used in the authentication instance.
+    
+    If >3 factors can be used in an authentication instance the authenticator vendor must select the 3 factors it believes 
+    will be most relevant to the Server to include in the UVM.
+
+    Servers supporting the UVM extension MUST support a length up to 36 bytes for a 3 factor maximum UVM value.  
+
+    Example for rawData containing one UVM extension for a multi-factor authentication instance where 2 factors were used:
+    
+        F1 D0                  -- This is a WebAuthn packed rawData object
+        81                     -- TUP and ED set
+        00 00 00 01            -- (initial) signature counter
+        ...                    -- all public key alg etc.
+        A1                     -- extension: CBOR map of one element
+            6C                 -- Key 1: CBOR text string of 12 bytes
+                77 65 62 61 75 74 68 6E 2E 75 76 6d -- "webauthn_uvm" UTF-8 string
+            82                 -- Value 1: CBOR array of length 2 indicating two factor usage
+                83              -- Item 1: CBOR array of length 3
+                    02           -- Subitem 1: CBOR integer for User Verification Method Fingerprint 
+                    04           -- Subitem 2: CBOR short for Key Protection Type TEE
+                    02           -- Subitem 3: CBOR short for Matcher Protection Type TEE
+                83              -- Item 2: CBOR array of length 3
+                    04           -- Subitem 1: CBOR integer for User Verification Method Passcode 
+                    01           -- Subitem 2: CBOR short for Key Protection Type Software
+                    01           -- Subitem 3: CBOR short for Matcher Protection Type Software
+    

+
+
 # IANA Considerations # {#iana-considerations}
 
 This specification registers the algorithm names "S256", "S384", "S512", and "SM3" with the IANA JSON Web Algorithms registry as

From e93a23faefb797d81ac850f8ab17c9e5396a3e56 Mon Sep 17 00:00:00 2001
From: =JeffH 
Date: Thu, 1 Sep 2016 09:35:21 -0700
Subject: [PATCH 4/7] breakup IDL (#186)

* move IDL frags to applicable sections. fixes #112 and #117.

* link to IDL index
---
 index.bs | 158 ++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 93 insertions(+), 65 deletions(-)

diff --git a/index.bs b/index.bs
index 9b1c194f1..f50cfbe11 100644
--- a/index.bs
+++ b/index.bs
@@ -273,13 +273,19 @@ The client facilitates these security measures by providing correct web origins
 operation. Since this is an integral part of the WebAuthn security model, user agents MUST only expose this API to callers in
 secure contexts, as defined in [[secure-contexts]].
 
-The API is defined by the following Web IDL fragment.
+The Web Authentication API is defined by the union of the Web IDL fragments presented in the following sections. A combined IDL listing is given in the [[#idl-index]]. The API is defined as a part of the Navigator interface:
+
 
 
     partial interface Navigator {
         readonly attribute WebAuthentication authentication;
     };
+

+
+
+## WebAuthentication Interface ## {#iface-credential}
 
+
     interface WebAuthentication {
         Promise < ScopedCredentialInfo > makeCredential (
             Account                                 accountInformation,
@@ -293,72 +299,8 @@ The API is defined by the following Web IDL fragment.
             optional AssertionOptions  options
         );
     };
-
-    interface ScopedCredentialInfo {
-        readonly attribute Credential           credential;
-        readonly attribute CryptoKey            publicKey;
-        readonly attribute WebAuthnAttestation  attestation;
-    };
-
-    dictionary Account {
-        required DOMString rpDisplayName;
-        required DOMString displayName;
-        DOMString          name;
-        DOMString          id;
-        DOMString          imageURL;
-    };
-
-    dictionary ScopedCredentialParameters {
-        required CredentialType        type;
-        required AlgorithmIdentifier   algorithm;
-    };
-
-    dictionary CredentialOptions {
-        unsigned long                       timeoutSeconds;
-        sequence < CredentialDescription >  excludeList;
-        WebAuthnExtensions                  extensions;
-    };
-
-    interface WebAuthnAssertion {
-        readonly attribute Credential  credential;
-        readonly attribute ArrayBuffer clientData;
-        readonly attribute ArrayBuffer authenticatorData;
-        readonly attribute ArrayBuffer signature;
-    };
-
-    dictionary AssertionOptions {
-        unsigned long                      timeoutSeconds;
-        sequence < CredentialDescription > allowList;
-        WebAuthnExtensions                 extensions;
-    };
-
-    dictionary WebAuthnExtensions {
-    };
-
-    interface WebAuthnAttestation {
-        readonly    attribute DOMString     type;
-        readonly    attribute ArrayBuffer   clientData;
-        readonly    attribute any           statement;
-    };
-
-    enum CredentialType {
-        "ScopedCred"
-    };
-
-    interface Credential {
-        readonly attribute CredentialType type;
-        readonly attribute ArrayBuffer    id;
-    };
-
-    dictionary CredentialDescription {
-        required CredentialType type;
-        required BufferSource   id;
-    };
 

 
-
-## WebAuthentication Interface ## {#iface-credential}
-
 This interface has two methods, which are described in the following subsections.
 
 
@@ -518,6 +460,14 @@ authorizing an authenticator with which to complete the operation.
 
 ## ScopedCredentialInfo Interface ## {#iface-credentialInfo}
 
+
+    interface ScopedCredentialInfo {
+        readonly attribute Credential           credential;
+        readonly attribute CryptoKey            publicKey;
+        readonly attribute WebAuthnAttestation  attestation;
+    };
+

+
 

     This interface represents a newly-created scoped credential. It contains information about the credential that can be used
     to locate it later for use, and also contains metadata that can be used by the [RP] to assess the strength of the
@@ -536,6 +486,18 @@ authorizing an authenticator with which to complete the operation.
 
 ## User Account Information (dictionary Account) ## {#iface-account}
 
+
+    dictionary Account {
+        required DOMString rpDisplayName;
+        required DOMString displayName;
+        DOMString          name;
+        DOMString          id;
+        DOMString          imageURL;
+    };
+

+
+
+
 

     This dictionary is used by the caller to specify information about the user account and [RP] with which a credential
     is to be associated. It is intended to help the authenticator in providing a friendly credential selection interface for the
@@ -559,6 +521,13 @@ authorizing an authenticator with which to complete the operation.
 
 ## Parameters for Credential Generation (dictionary ScopedCredentialParameters) ## {#credential-params}
 
+
+    dictionary ScopedCredentialParameters {
+        required CredentialType        type;
+        required AlgorithmIdentifier   algorithm;
+    };
+

+
 

     This dictionary is used to supply additional parameters when creating a new credential.
 
@@ -571,6 +540,15 @@ authorizing an authenticator with which to complete the operation.
 
 ## Additional options for Credential Generation (dictionary CredentialOptions) ## {#credential-options}
 
+
+    dictionary CredentialOptions {
+        unsigned long                       timeoutSeconds;
+        sequence < CredentialDescription >  excludeList;
+        WebAuthnExtensions                  extensions;
+    };
+

+
+
 

     This dictionary is used to supply additional options when creating a new credential. All these parameters are optional.
 
@@ -591,6 +569,15 @@ authorizing an authenticator with which to complete the operation.
 
 ## WebAuthn Assertion (interface WebAuthnAssertion) ## {#iface-assertion}
 
+
+    interface WebAuthnAssertion {
+        readonly attribute Credential  credential;
+        readonly attribute ArrayBuffer clientData;
+        readonly attribute ArrayBuffer authenticatorData;
+        readonly attribute ArrayBuffer signature;
+    };
+

+
 Scoped credentials produce a cryptographic signature that provides proof of possession of a private key as well as evidence of
 user consent to a specific transaction. The structure of these signatures is defined as follows.
 
@@ -610,6 +597,14 @@ user consent to a specific transaction. The structure of these signatures is def
 
 ## Additional options for Assertion Generation (dictionary AssertionOptions) ## {#assertion-options}
 
+
+    dictionary AssertionOptions {
+        unsigned long                      timeoutSeconds;
+        sequence < CredentialDescription > allowList;
+        WebAuthnExtensions                 extensions;
+    };
+

+
 

     This dictionary is used to supply additional options when generating an assertion. All these parameters are optional.
 
@@ -627,6 +622,11 @@ user consent to a specific transaction. The structure of these signatures is def
 
 ## WebAuthn Assertion Extensions (dictionary WebAuthnExtensions) ## {#iface-assertion-extensions}
 
+
+    dictionary WebAuthnExtensions {
+    };
+

+
 This is a dictionary containing zero or more extensions as defined in [[#extensions]]. An extension is an additional parameter
 that can be passed to the getAssertion() method and triggers some additional processing by the client platform and/or the
 authenticator.
@@ -637,6 +637,14 @@ with the extension identifier as the key, and the extension's value as the value
 
 ## Credential Attestation Statement (interface WebAuthnAttestation) ## {#iface-attestation}
 
+
+    interface WebAuthnAttestation {
+        readonly    attribute DOMString     type;
+        readonly    attribute ArrayBuffer   clientData;
+        readonly    attribute any           statement;
+    };
+

+
 Authenticators also provide some form of attestation. The basic requirement is that the authenticator can produce, for each
 credential public key, attestation information that can be verified by a [RP]. Typically, this information contains a
 signature by an attesting key over the attested public key and a challenge, as well as a certificate or similar information
@@ -711,6 +719,12 @@ This structure is used by the client to compute the following quantities:
 
 ### Credential Type enumeration (enum CredentialType) ### {#credentialType}
 
+
+    enum CredentialType {
+        "ScopedCred"
+    };
+

+
 

     This enumeration defines the valid credential types. It is an extension point; values may be added to it in the future, as
     more credential types are defined. The values of this enumeration are used for versioning the WebAuthn assertion and
@@ -722,6 +736,13 @@ This structure is used by the client to compute the following quantities:
 
 ### Unique Identifier for Credential (interface Credential) ### {#credential-identifier}
 
+
+    interface Credential {
+        readonly attribute CredentialType type;
+        readonly attribute ArrayBuffer    id;
+    };
+

+
 This interface contains the attributes that are returned to the caller when a new credential is created, and can be used later
 by the caller to select a credential for use.
 
@@ -740,6 +761,13 @@ by the caller to select a credential for use.
 
 ### Credential Descriptor (dictionary CredentialDescription) ### {#credential-dictionary}
 
+
+    dictionary CredentialDescription {
+        required CredentialType type;
+        required BufferSource   id;
+    };
+

+
 This dictionary contains the attributes that are specified by a caller when referring to a credential as an input parameter to
 the {{makeCredential()}} or {{getAssertion()}} method. It mirrors the fields of the {{Credential}} object returned by these methods.
 

From f536c622601494e884894ac8f18324b8e30670e5 Mon Sep 17 00:00:00 2001
From: Mike Jones 
Date: Thu, 1 Sep 2016 12:11:17 -0700
Subject: [PATCH 5/7] Fixed spelling, grammar, and document syntax issues
 (#187)

---
 index.bs | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/index.bs b/index.bs
index f50cfbe11..e37a4c662 100644
--- a/index.bs
+++ b/index.bs
@@ -110,7 +110,7 @@ A variety of additional use cases and configurations are also possible, includin
 
 # Conformance # {#conformance}
 
-This specification defines criteria for a Conforming User Agent: a User Agent MUST behave as described in this
+This specification defines criteria for a Conforming User Agent: A User Agent MUST behave as described in this
 specification 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
@@ -196,7 +196,7 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
 
 : eTLD+1
 :: Also known as a Registered Domain [[PSL]], an eTLD+1 is an effective Top-Level Domain Name (eTLD), plus the
-	next domain name label, proceding from right to left. An eTLD is also known as a public suffix [[RFC7719]].
+	next domain name label, proceeding from right to left. An eTLD is also known as a public suffix [[RFC7719]].
 
 : Registration
 :: The ceremony where a user, a [RP], and the user's computing device(s) (containing at least one
@@ -207,8 +207,8 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
 :: The entity whose web application utilizes the Web Authentication API to register and authenticate users. See
     Registration and Authentication, respectively.
 
-    Note: While the term [RP] is used in other contexts (e.g., X.509 and OAuth), an entity acting as an [RP] in one context is
-        not necessarily an [RP] in others.
+    Note: While the term [RP] is used in other contexts (e.g., X.509 and OAuth), an entity acting as a [RP] in one context is
+        not necessarily a [RP] in others.
 
 : Relying Party Identifier
 : RP ID
@@ -330,7 +330,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
 1. If {{CredentialOptions/timeoutSeconds}} was specified, check if its value lies within a reasonable range as defined by the
     platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted value.
-    If {{CredentialOptions/timeoutSeconds}} was not specified then set |adjustedTimeout| to a platform-specific default.
+    If {{CredentialOptions/timeoutSeconds}} was not specified, then set |adjustedTimeout| to a platform-specific default.
 
 2. Let |promise| be a new Promise. Return |promise| and start a timer for |adjustedTimeout| seconds.
     Then asynchronously continue executing the following steps.
@@ -406,7 +406,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
 1. If {{AssertionOptions/timeoutSeconds}} was specified, check if its value lies within a reasonable range as defined by the
     platform and if not, correct it to the closest value lying within that range. Set |adjustedTimeout| to this adjusted value.
-    If {{AssertionOptions/timeoutSeconds}} was not specified then set |adjustedTimeout| to a platform-specific default.
+    If {{AssertionOptions/timeoutSeconds}} was not specified, then set |adjustedTimeout| to a platform-specific default.
 
 2. Let |promise| be a new Promise. Return |promise| and start a timer for |adjustedTimeout| seconds.
     Then asynchronously continue executing the following steps.
@@ -1019,7 +1019,7 @@ This specification also defines a number of attestation types. These define how
 attestation statement, after verifying that it is cryptographically valid.
 
 Attestation formats are orthogonal to attestation types, i.e. attestation formats in general are not restricted to a single
-attestation type. For example the "packed" attestation format (see below) can be used in conjunction with all attestation types.
+attestation type. For example, the "packed" attestation format (see below) can be used in conjunction with all attestation types.
 Broadly speaking, attestation formats pertain to the formatting / encoding of the attestation statement
 rawData, while attestation types pertain to the semantics.
 The privacy, the security and the operational characteristic of attestation mainly depends 
@@ -1164,7 +1164,7 @@ DAA-Verify. The FIDO Metadata Service [[FIDOMetadataService]] provides an easy w
 
 #### Attestation Certificate Hierarchy #### {#cert-hierarchy}
 
-A 3 tier hierarchy for attestation certificates is recommended (i.e., Attestation Root, Attestation Issuing CA, Attestation
+A 3-tier hierarchy for attestation certificates is recommended (i.e., Attestation Root, Attestation Issuing CA, Attestation
 Certificate). It is also recommended that for each WebAuthn Authenticator device line (i.e., model), a separate issuing CA is
 used to help facilitate isolating problems with a specific version of a device.
 
@@ -1267,7 +1267,7 @@ arranged as given below:
         
             Public key algorithm and encoding (16-bit big-endian value). Allowed values are:
 
-            1. 0x0100. This is raw ANSI X9.62 formatted Elliptic Curve public key [[!SEC1]], i.e.,
+            1. 0x0100. Raw ANSI X9.62 formatted Elliptic Curve public key [[!SEC1]], i.e.,
                 `[0x04, X (n bytes), Y (n bytes)]`, where the byte `0x04` denotes the uncompressed point compression method and
                 n denotes the key length in bytes.
 
@@ -1283,7 +1283,7 @@ arranged as given below:
     
     
         2
-        Byte length m of following public key bytes (16 bit value with most significant byte first).
+        Byte length m of following public key bytes (16-bit value with most significant byte first).
     
     
         (length)
@@ -1380,7 +1380,7 @@ The attestation certificate MUST have the following fields/extensions:
 
 ## TPM Attestation ("tpm") ## {#tpm-attestation}
 
-This attestation format returns an attestation statement in the same format as defined in [[#packed-attestation]]. However the
+This attestation format returns an attestation statement in the same format as defined in [[#packed-attestation]]. However, the
 `rawData` and `signature` fields are computed differently, as described below.
 
 
@@ -1530,8 +1530,8 @@ A [RP] shall verify the {{ClientData}} contextual bindings (see step 4 in [[#ver
 # WebAuthn Extensions # {#extensions}
 
 The mechanism for generating scoped credentials, as well as requesting and generating WebAuthn assertions, as defined in
-[[#api]], can be extended to suit particular use cases. Each case is addressed by defining a registration extension and/or a
-authentication extension. Extensions can define additions to the following steps and data:
+[[#api]], can be extended to suit particular use cases. Each case is addressed by defining a registration extension and/or
+an authentication extension. Extensions can define additions to the following steps and data:
 
 - {{makeCredential()}} request parameters for registration extension.
 
@@ -1638,7 +1638,7 @@ the authenticator argument.
 ## Extending authenticator processing ## {#extension-authenticator-processing}
 
 Extensions that define additional authenticator processing may similarly define an authenticator data value. The value may be
-any data that can be encoded in CBOR. An authenticator that processes a authentication extension that defines such a value must
+any data that can be encoded in CBOR. An authenticator that processes an authentication extension that defines such a value must
 include it in the `authenticatorData`.
 
 As specified in [[#sec-authenticator-data]], the authenticator data value of each processed extension is included in the
@@ -2052,7 +2052,7 @@ platform to enumerate all the authenticator's credentials so that the client can
 
 ## Registration ## {#sample-registration}
 
-This is the first time flow, when a new credential is created and registered with the server.
+This is the first-time flow, in which a new credential is created and registered with the server.
 
 1. The user visits example.com, which serves up a script. At this point, the user must already be logged in using a legacy
     username and password, or additional authenticator, or other means acceptable to the [RP].
@@ -2239,7 +2239,7 @@ handled on the server side and do not need support from the API specified here.
 
 
 # Acknowledgements # {#acknowledgements}
-We thank the following for their contributions to, and thorough review of, this specification: Jing Jin, Giridhar Mandyam.
+We thank the following for their contributions to, and thorough review of, this specification: Jing Jin and Giridhar Mandyam.
 
 
 {  

From 5369029b843d3eb049ec76d410b724391c826a65 Mon Sep 17 00:00:00 2001
From: JeffH 
Date: Thu, 1 Sep 2016 13:50:56 -0700
Subject: [PATCH 6/7] adding draft-hodges-webauthn-registries source and output
 files to repo

---
 draft-hodges-webauthn-registries-00b.html | 736 ++++++++++++++++++++++
 draft-hodges-webauthn-registries-00b.txt  | 448 +++++++++++++
 draft-hodges-webauthn-registries.xml      | 483 ++++++++++++++
 3 files changed, 1667 insertions(+)
 create mode 100644 draft-hodges-webauthn-registries-00b.html
 create mode 100644 draft-hodges-webauthn-registries-00b.txt
 create mode 100644 draft-hodges-webauthn-registries.xml

diff --git a/draft-hodges-webauthn-registries-00b.html b/draft-hodges-webauthn-registries-00b.html
new file mode 100644
index 000000000..f0355380c
--- /dev/null
+++ b/draft-hodges-webauthn-registries-00b.html
@@ -0,0 +1,736 @@
+
+
+
+
+  
+
+  Registries for Web Authentication (WebAuthn)
+
+  
+
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+  
+  
+  
+  
+  
+
+
+
+
+
+  
+    
+    
+    	
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+    	
+    
+  
Network Working GroupJ. Hodges
Internet-DraftPayPal
Intended status: InformationalJune 2016
Expires: December 3, 2016

+
+  
Registries for Web Authentication (WebAuthn)

+  draft-hodges-webauthn-registries-00b

+  
+  

+  Abstract
+

+
This specification defines IANA registries for W3C Web Authentication [WebAuthn] attestation formats and extension identifiers.

+

+  Status of This Memo
+

+
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

+
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

+
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

+
This Internet-Draft will expire on December 3, 2016.

+

+  Copyright Notice
+

+
Copyright (c) 2016 IETF Trust and the persons identified as the document authors.  All rights reserved.

+
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

+
+  
+  

+  
Table of Contents

+  
+
+  
1. Introduction

+
This specification defines IANA registries for W3C Web Authentication [WebAuthn] attestation formats and extension identifiers, and supplies initial entries within each registry.  

+
2. Registering WebAuthn Attestation Formats

+
WebAuthn attestation format identifiers are strings whose semantic, syntactic, uniqueness, and string-matching criteria are specified in [WebAuthn], along with the concepts of attestation and attestation formats.  

+
WebAuthn attestation formats are registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (per [RFC5226]).  

+
The Expert(s) will establish procedures for requesting registrations, and make them available from the registry page.  

+
Registration requests consist of at least the following information: 

+
+
    
+  
  • WebAuthn Attestation Format Identifier: 
    • 
+  
  • Description: A relatively short description of the attestation format.
    • 
+  
  • Specification Document: Reference to the specification of the attestation format. 
    • 
+  
  • Notes: [optional]
    • 
+

+
+
 

+
The Expert(s) MAY define additional fields to be collected in the registry.  

+
See Section 4.2 for intial registrations, which may be used as examples for subsequent registrations.  

+
Registrations MUST reference a freely available specification, e.g., as described in [RFC2026] Section 7.  

+
Note that WebAuthn attestation formats can be registered by third parties, if the Expert(s) determine that an unregistered attestation format is widely deployed and not likely to be registered in a timely manner.  

+
Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list).  

+

+  

+  

+

+
3. Registering WebAuthn Extension Identifiers

+
WebAuthn extension identifiers are strings whose semantic, syntactic, uniqueness, and string-matching criteria are specified in [WebAuthn].  

+
WebAuthn extension identifiers are registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (per [RFC5226]).  

+
The Expert(s) will establish procedures for requesting registrations, and make them available from the registry page.  

+
Registration requests consist of at least the following information: 

+
+
    
+  
  • WebAuthn Extension Identifier: 
    • 
+  
  • Description: A relatively short description of the extension.
    • 
+  
  • Specification Document: Reference to the specification of the extension. 
    • 
+  
  • Notes: [optional]
    • 
+

+
+
 

+
The Expert(s) MAY define additional fields to be collected in the registry.  

+
See Section 4.3 for intial registrations, which may be used as examples for subsequent registrations.  

+
Registrations MUST reference a freely available specification, e.g., as described in [RFC2026] Section 7.  

+
Note that WebAuthn extensions can be registered by third parties, if the Expert(s) determine that an unregistered extension is widely deployed and not likely to be registered in a timely manner.  

+
Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app-ads@tools.ietf.org email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the iesg@iesg.org mailing list).  

+

+  

+  

+

+
4. IANA Considerations

+
4.1. WebAuthn Attestation Formats and Extension Identifiers Registries

+
This specification establishes two registries: 

+
+
    
+  
  • the WebAuthn Attestation Formats registry; see Section 2. Initial registry contents are given in Section 4.2.
    • 
+  
  • the WebAuthn Extension Identifiers registry; see Section 3. Initial registry contents are given in Section 4.3.
    • 
+

+
+
 For both registries, the Expert(s) and IANA will interact as outlined below: 

+
IANA will direct any incoming requests regarding the registry to the processes established by the Expert(s); typically, this will mean referring them to the registry HTML page.  

+
The Expert(s) will provide registry data to IANA in an agreed form (e.g. a specific XML format). IANA will publish: 

+
+
    
+  
  • The raw registry data
    • 
+  
  • The registry data, transformed into HTML
    • 
+  
  • The registry data in any alternative formats provided by the Expert(s)
    • 
+

+
+
 

+
Each published document will be at a URL agreed to by IANA and the Expert(s), and IANA will set HTTP response headers on them as (reasonably) requested by the Expert(s).  

+
Additionally, the HTML generated by IANA will: 

+
+
    
+  
  • Take directions from the Expert(s) as to the content of the HTML page's introductory text and markup
    • 
+  
  • Include a stable HTML fragment identifier for each registered attestation format or extension identifier
    • 
+

+
+
 

+
All registry data documents MUST include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions (<http://trustee.ietf.org/license-info>).  

+
4.2. Initial WebAuthn Attestation Formats Registry Contents

+
The WebAuthn Attestation Formats registry's initial contents are:

+

+
+
    
+  
  • WebAuthn Attestation Formats: packed
    • 
+  
  • Description: The "packed" attestation format is a WebAuthn-optimized format for attestation data. It uses a very compact but still extensible encoding method. This format is implementable by authenticators with limited resources (e.g., secure elements).
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Attestation Formats: tpm
    • 
+  
  • Description: The TPM attestation format returns an attestation statement in the same format as the packed attestation format, although the the rawData and signature fields are computed differently.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Attestation Formats: android
    • 
+  
  • Description: Android-based, platform-provided authenticators may produce an attestation statement based on the Android SafetyNet API.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Attestation Formats: android2
    • 
+  
  • Description: Platform-provided authenticators based on Android versions "N", and later, may provide a "hardware attestation" statement.
    • 
+  
  • Specification Document: [AndroidHWAttstn]
    • 
+

+

+  

+  

+

+
4.3. Initial WebAuthn Extension Identifiers Registry Contents

+
The WebAuthn Extension Identifiers registry's initial contents are:

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_txAuthSimple
    • 
+  
  • Description: This signature extension allows for a simple form of transaction authorization. A WebAuthn Relying Party can specify a prompt string, intended for display on a trusted device on the authenticator
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_txAuthGeneric
    • 
+  
  • Description: This generic txauth extension allows images to be used as prompts as well. This allows authenticators without a font rendering engine to be used and also supports a richer visual appearance than accomplished with the webauthn.txauth.simple extension.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_authnSel
    • 
+  
  • Description: This registration extension allows a WebAuthn Relying Party to guide the selection of the authenticator that will be leveraged when creating the credential. It is intended primarily for WebAuthn Relying Parties that wish to tightly control the experience around credential creation.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_exts
    • 
+  
  • Description: The Supported Extensions extension data is a list (CBOR array) of extension identifiers encoded as UTF-8 Strings. This extension is added automatically by the authenticator. This extension can be added to attestation statements.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_uvi
    • 
+  
  • Description: The user verification index (UVI) is a value uniquely identifying a user verification data record. The UVI data can be used by servers to understand whether an authentication was authorized by the exact same biometric data as the initial key generation. This allows the detection and prevention of "friendly fraud". 
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_loc
    • 
+  
  • Description: The location extension provides the client device's current location to the WebAuthn relying party, if supported by the client device and subject to user consent.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+

+
+
    
+  
  • WebAuthn Extension Identifier: webauthn_uvm
    • 
+  
  • Description: The user verification mode (UVM) extension returns to the Webauthn relying party which user verification methods (factors) were used for the WebAuthn operation.
    • 
+  
  • Specification Document: [WebAuthn]
    • 
+

+

+  

+  

+

+
5. Security Considerations

+
See [WebAuthn] for relevant security considerations.

+
6. Change Log

+
Note to RFC Editor: Please remove this section before publication.

+
This is the initial -00 rev of this spec, hence no changes to log here at this time.

+
7. Acknowledgements

+
Thanks to Mark Nottingham for valuable comments and suggestions.

+
8. Normative References

+
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+

+        [AndroidHWAttstn]
+      , , "Android Hardware Attestation", Andorid Developers Reference     , 2016.

+        [RFC2026]
+      Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996.

+        [RFC5226]
+      Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.

+        [WebAuthn]
+      Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A., Birgisson, A., Hodges, J., Jones, M. and R. Lindemann, "Web Authentication: An API for accessing Scoped Credentials", World Wide Web Consortium (W3C) Recommendation-track, May 2016.

+

+  Author's Address
+

+

+  

+	
+	  Jeff Hodges 
+	  
+	
+	PayPal
+	
+	  2211 North First Street
+
+	  
+		San Jose,  
+		California 
+		95131
+	  
+	  US
+	
+	EMail: Jeff.Hodges@PayPal.com
+
+  

+

+
+
+
diff --git a/draft-hodges-webauthn-registries-00b.txt b/draft-hodges-webauthn-registries-00b.txt
new file mode 100644
index 000000000..c255648ef
--- /dev/null
+++ b/draft-hodges-webauthn-registries-00b.txt
@@ -0,0 +1,448 @@
+
+
+
+
+Network Working Group                                          J. Hodges
+Internet-Draft                                                    PayPal
+Intended status: Informational                                 June 2016
+Expires: December 3, 2016
+
+
+              Registries for Web Authentication (WebAuthn)
+                  draft-hodges-webauthn-registries-00b
+
+Abstract
+
+   This specification defines IANA registries for W3C Web Authentication
+   [WebAuthn] attestation formats and extension identifiers.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on December 3, 2016.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Hodges                  Expires December 3, 2016                [Page 1]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Registering WebAuthn Attestation Formats  . . . . . . . . . .   2
+   3.  Registering WebAuthn Extension Identifiers  . . . . . . . . .   3
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
+     4.1.  WebAuthn Attestation Formats and Extension Identifiers
+           Registries  . . . . . . . . . . . . . . . . . . . . . . .   4
+     4.2.  Initial WebAuthn Attestation Formats Registry Contents  .   5
+     4.3.  Initial WebAuthn Extension Identifiers Registry Contents    5
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   6.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7
+
+1.  Introduction
+
+   This specification defines IANA registries for W3C Web Authentication
+   [WebAuthn] attestation formats and extension identifiers, and
+   supplies initial entries within each registry.
+
+2.  Registering WebAuthn Attestation Formats
+
+   WebAuthn attestation format identifiers are strings whose semantic,
+   syntactic, uniqueness, and string-matching criteria are specified in
+   [WebAuthn], along with the concepts of attestation and attestation
+   formats.
+
+   WebAuthn attestation formats are registered on the advice of a
+   Designated Expert (appointed by the IESG or their delegate), with a
+   Specification Required (per [RFC5226]).
+
+   The Expert(s) will establish procedures for requesting registrations,
+   and make them available from the registry page.
+
+   Registration requests consist of at least the following information:
+
+   o  WebAuthn Attestation Format Identifier:
+   o  Description: A relatively short description of the attestation
+      format.
+   o  Specification Document: Reference to the specification of the
+      attestation format.
+   o  Notes: [optional]
+
+   The Expert(s) MAY define additional fields to be collected in the
+   registry.
+
+
+
+
+Hodges                  Expires December 3, 2016                [Page 2]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+   See Section 4.2 for intial registrations, which may be used as
+   examples for subsequent registrations.
+
+   Registrations MUST reference a freely available specification, e.g.,
+   as described in [RFC2026] Section 7.
+
+   Note that WebAuthn attestation formats can be registered by third
+   parties, if the Expert(s) determine that an unregistered attestation
+   format is widely deployed and not likely to be registered in a timely
+   manner.
+
+   Decisions (or lack thereof) made by the Designated Expert can be
+   first appealed to Application Area Directors (contactable using app-
+   ads@tools.ietf.org email address or directly by looking up their
+   email addresses on http://www.iesg.org/ website) and, if the
+   appellant is not satisfied with the response, to the full IESG (using
+   the iesg@iesg.org mailing list).
+
+
+3.  Registering WebAuthn Extension Identifiers
+
+   WebAuthn extension identifiers are strings whose semantic, syntactic,
+   uniqueness, and string-matching criteria are specified in [WebAuthn].
+
+   WebAuthn extension identifiers are registered on the advice of a
+   Designated Expert (appointed by the IESG or their delegate), with a
+   Specification Required (per [RFC5226]).
+
+   The Expert(s) will establish procedures for requesting registrations,
+   and make them available from the registry page.
+
+   Registration requests consist of at least the following information:
+
+   o  WebAuthn Extension Identifier:
+   o  Description: A relatively short description of the extension.
+   o  Specification Document: Reference to the specification of the
+      extension.
+   o  Notes: [optional]
+
+   The Expert(s) MAY define additional fields to be collected in the
+   registry.
+
+   See Section 4.3 for intial registrations, which may be used as
+   examples for subsequent registrations.
+
+   Registrations MUST reference a freely available specification, e.g.,
+   as described in [RFC2026] Section 7.
+
+
+
+
+Hodges                  Expires December 3, 2016                [Page 3]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+   Note that WebAuthn extensions can be registered by third parties, if
+   the Expert(s) determine that an unregistered extension is widely
+   deployed and not likely to be registered in a timely manner.
+
+   Decisions (or lack thereof) made by the Designated Expert can be
+   first appealed to Application Area Directors (contactable using app-
+   ads@tools.ietf.org email address or directly by looking up their
+   email addresses on http://www.iesg.org/ website) and, if the
+   appellant is not satisfied with the response, to the full IESG (using
+   the iesg@iesg.org mailing list).
+
+
+4.  IANA Considerations
+
+4.1.  WebAuthn Attestation Formats and Extension Identifiers Registries
+
+   This specification establishes two registries:
+
+   o  the WebAuthn Attestation Formats registry; see Section 2.  Initial
+      registry contents are given in Section 4.2.
+   o  the WebAuthn Extension Identifiers registry; see Section 3.
+      Initial registry contents are given in Section 4.3.
+
+   For both registries, the Expert(s) and IANA will interact as outlined
+   below:
+
+   IANA will direct any incoming requests regarding the registry to the
+   processes established by the Expert(s); typically, this will mean
+   referring them to the registry HTML page.
+
+   The Expert(s) will provide registry data to IANA in an agreed form
+   (e.g. a specific XML format).  IANA will publish:
+
+   o  The raw registry data
+   o  The registry data, transformed into HTML
+   o  The registry data in any alternative formats provided by the
+      Expert(s)
+
+   Each published document will be at a URL agreed to by IANA and the
+   Expert(s), and IANA will set HTTP response headers on them as
+   (reasonably) requested by the Expert(s).
+
+   Additionally, the HTML generated by IANA will:
+
+   o  Take directions from the Expert(s) as to the content of the HTML
+      page's introductory text and markup
+   o  Include a stable HTML fragment identifier for each registered
+      attestation format or extension identifier
+
+
+
+Hodges                  Expires December 3, 2016                [Page 4]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+   All registry data documents MUST include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions
+   ().
+
+4.2.  Initial WebAuthn Attestation Formats Registry Contents
+
+   The WebAuthn Attestation Formats registry's initial contents are:
+
+      WebAuthn Attestation Formats: packed
+      Description: The "packed" attestation format is a WebAuthn-
+      optimized format for attestation data.  It uses a very compact but
+      still extensible encoding method.  This format is implementable by
+      authenticators with limited resources (e.g., secure elements).
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Attestation Formats: tpm
+      Description: The TPM attestation format returns an attestation
+      statement in the same format as the packed attestation format,
+      although the the rawData and signature fields are computed
+      differently.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Attestation Formats: android
+      Description: Android-based, platform-provided authenticators may
+      produce an attestation statement based on the Android SafetyNet
+      API.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Attestation Formats: android2
+      Description: Platform-provided authenticators based on Android
+      versions "N", and later, may provide a "hardware attestation"
+      statement.
+      Specification Document: [AndroidHWAttstn]
+
+
+4.3.  Initial WebAuthn Extension Identifiers Registry Contents
+
+   The WebAuthn Extension Identifiers registry's initial contents are:
+
+      WebAuthn Extension Identifier: webauthn_txAuthSimple
+      Description: This signature extension allows for a simple form of
+      transaction authorization.  A WebAuthn Relying Party can specify a
+      prompt string, intended for display on a trusted device on the
+      authenticator
+      Specification Document: [WebAuthn]
+
+
+
+Hodges                  Expires December 3, 2016                [Page 5]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+      WebAuthn Extension Identifier: webauthn_txAuthGeneric
+      Description: This generic txauth extension allows images to be
+      used as prompts as well.  This allows authenticators without a
+      font rendering engine to be used and also supports a richer visual
+      appearance than accomplished with the webauthn.txauth.simple
+      extension.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Extension Identifier: webauthn_authnSel
+      Description: This registration extension allows a WebAuthn Relying
+      Party to guide the selection of the authenticator that will be
+      leveraged when creating the credential.  It is intended primarily
+      for WebAuthn Relying Parties that wish to tightly control the
+      experience around credential creation.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Extension Identifier: webauthn_exts
+      Description: The Supported Extensions extension data is a list
+      (CBOR array) of extension identifiers encoded as UTF-8 Strings.
+      This extension is added automatically by the authenticator.  This
+      extension can be added to attestation statements.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Extension Identifier: webauthn_uvi
+      Description: The user verification index (UVI) is a value uniquely
+      identifying a user verification data record.  The UVI data can be
+      used by servers to understand whether an authentication was
+      authorized by the exact same biometric data as the initial key
+      generation.  This allows the detection and prevention of "friendly
+      fraud".
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Extension Identifier: webauthn_loc
+      Description: The location extension provides the client device's
+      current location to the WebAuthn relying party, if supported by
+      the client device and subject to user consent.
+      Specification Document: [WebAuthn]
+
+
+      WebAuthn Extension Identifier: webauthn_uvm
+      Description: The user verification mode (UVM) extension returns to
+      the Webauthn relying party which user verification methods
+      (factors) were used for the WebAuthn operation.
+      Specification Document: [WebAuthn]
+
+
+
+Hodges                  Expires December 3, 2016                [Page 6]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+5.  Security Considerations
+
+   See [WebAuthn] for relevant security considerations.
+
+6.  Change Log
+
+   Note to RFC Editor: Please remove this section before publication.
+
+   This is the initial -00 rev of this spec, hence no changes to log
+   here at this time.
+
+7.  Acknowledgements
+
+   Thanks to Mark Nottingham for valuable comments and suggestions.
+
+8.  Normative References
+
+   [AndroidHWAttstn]
+              Google, "Android Hardware Attestation", Andorid Developers
+              Reference  , 2016,
+              .
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+              .
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              .
+
+   [WebAuthn]
+              Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A.,
+              Birgisson, A., Hodges, J., Jones, M., and R. Lindemann,
+              "Web Authentication: An API for accessing Scoped
+              Credentials", World Wide Web Consortium (W3C)
+              Recommendation-track, May 2016, .
+
+Author's Address
+
+
+
+
+
+
+
+
+
+
+Hodges                  Expires December 3, 2016                [Page 7]
+
+Internet-DraftRegistries for Web Authentication (WebAuthn)     June 2016
+
+
+   Jeff Hodges
+   PayPal
+   2211 North First Street
+   San Jose, California  95131
+   US
+
+   Email: Jeff.Hodges@PayPal.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges                  Expires December 3, 2016                [Page 8]
diff --git a/draft-hodges-webauthn-registries.xml b/draft-hodges-webauthn-registries.xml
new file mode 100644
index 000000000..264a441a4
--- /dev/null
+++ b/draft-hodges-webauthn-registries.xml
@@ -0,0 +1,483 @@
+
+
+  
+  
+]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    Registries for Web Authentication (WebAuthn)
+    
+    
+          PayPal
+      

+        
+          2211 North First Street
+          San Jose
+          California
+          95131
+          US
+        
+        Jeff.Hodges@PayPal.com
+      

+    
+    
+    
+    
+    webauthn
+    attestation
+    extensions
+    registry
+    
+    
+      This specification defines IANA registries for W3C Web Authentication 
+      
+      attestation formats and extension identifiers.
+    
+    
+  
+  
+  
+    

+      
+        This specification defines IANA registries for W3C Web Authentication  attestation formats and extension identifiers, and supplies initial 
+        entries within each registry.
+      
+    

+
+          
+        
          
+            
+          
+            WebAuthn attestation format identifiers are strings whose semantic, syntactic,
+            uniqueness, and string-matching criteria are specified in , 
+            along with the concepts of attestation and attestation formats.
+          
+          
+            WebAuthn attestation formats are registered on the advice of a Designated Expert
+            (appointed by the IESG or their delegate), with a Specification Required (per ).
+          
+          
+            The Expert(s) will establish procedures for requesting registrations,
+            and make them available from the registry page.
+          
+          
+            Registration requests consist of at least the following information:
+            
+              WebAuthn Attestation Format Identifier: 
+              Description: A relatively short description of the attestation
+                format.
+              Specification Document: Reference to the specification of the 
+                attestation format. 
+              Notes: [optional]
+            
+          
+          
+            The Expert(s) MAY define additional fields to be collected in the registry.
+          
+          
+            See  for intial registrations, 
+            which may be used as examples for subsequent registrations. 
+          
+          
+             Registrations MUST reference a freely available specification, e.g., as 
+             described in  Section 7.
+          
+          
+            Note that WebAuthn attestation formats can be registered by third parties, if the
+            Expert(s) determine that an unregistered attestation format is widely deployed and not
+            likely to be registered in a timely manner.
+          
+          
+             Decisions (or lack thereof) made by the Designated Expert can be
+             first appealed to Application Area Directors (contactable using
+             app-ads@tools.ietf.org email address or directly by looking up their
+             email addresses on http://www.iesg.org/ website) and, if the
+             appellant is not satisfied with the response, to the full IESG (using
+             the iesg@iesg.org mailing list).
+          
+          
+
+        
    
+
+        
+        
          
+            
+          
+            WebAuthn extension identifiers are strings whose semantic, syntactic,
+            uniqueness, and string-matching criteria are specified in .
+          
+          
+            WebAuthn extension identifiers are registered on the advice of a Designated Expert
+            (appointed by the IESG or their delegate), with a Specification Required (per ).
+          
+          
+            The Expert(s) will establish procedures for requesting registrations,
+            and make them available from the registry page.
+          
+          
+            Registration requests consist of at least the following information:
+            
+              WebAuthn Extension Identifier: 
+              Description: A relatively short description of the extension.
+              Specification Document: Reference to the specification of the 
+                extension. 
+              Notes: [optional]
+            
+          
+          
+          
+            The Expert(s) MAY define additional fields to be collected in the registry.
+          
+          
+            See  for intial registrations, 
+            which may be used as examples for subsequent registrations. 
+          
+          
+             Registrations MUST reference a freely available specification, e.g., as 
+             described in  Section 7.
+          
+          
+            Note that WebAuthn extensions can be registered by third parties, if the Expert(s)
+            determine that an unregistered extension is widely deployed and not likely to be
+            registered in a timely manner.
+          
+          
+             Decisions (or lack thereof) made by the Designated Expert can be
+             first appealed to Application Area Directors (contactable using
+             app-ads@tools.ietf.org email address or directly by looking up their
+             email addresses on http://www.iesg.org/ website) and, if the
+             appellant is not satisfied with the response, to the full IESG (using
+             the iesg@iesg.org mailing list).
+          
+          
+
+
+                    
+        
    
+        
+        
+
+    

+
+      

+      
+        
+          This specification establishes two registries:
+          
+            the WebAuthn Attestation Formats registry; see . Initial registry contents are given in 
+            .
+            the WebAuthn Extension Identifiers registry; see . Initial registry contents are given in 
+            .
+          
+          For both registries, the Expert(s) and IANA will interact as outlined below:
+        
+        
+          IANA will direct any incoming requests regarding the registry to the processes established
+          by the Expert(s); typically, this will mean referring them to the registry HTML page.
+        
+        
+          The Expert(s) will provide registry data to IANA in an agreed form (e.g. a specific XML
+          format). IANA will publish:
+          
+            The raw registry data
+            The registry data, transformed into HTML
+            The registry data in any alternative formats provided by the Expert(s)
+          
+        
+        
+          Each published document will be at a URL agreed to by IANA and the Expert(s), and IANA
+          will set HTTP response headers on them as (reasonably) requested by the Expert(s).
+        
+        
+          Additionally, the HTML generated by IANA will: 
+          
+            Take directions from the Expert(s) as to the content of the HTML page's introductory
+            text and markup
+            Include a stable HTML fragment identifier for each registered attestation format or
+            extension identifier
+          
+        
+        
+          All registry data documents MUST include
+          Simplified BSD License text as described in Section 4.e
+          of the Trust Legal Provisions
+          ().
+        
+          
+      

+
+      
+      
+        

+          The WebAuthn Attestation Formats registry's initial contents are:
+          
+            
+              WebAuthn Attestation Formats: packed
+              Description: The "packed" attestation format
+              is a WebAuthn-optimized format for attestation
+              data. It uses a very compact but still extensible encoding method. This
+              format is implementable by authenticators with limited resources (e.g.,
+              secure elements).
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Attestation Formats: tpm
+              Description: The TPM attestation format returns an attestation statement in the
+              same format as the packed attestation format, although the the rawData and signature
+              fields are computed differently.
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Attestation Formats: android
+              Description: Android-based, platform-provided authenticators may produce an attestation statement based on the Android SafetyNet API.
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Attestation Formats: android2
+              Description: Platform-provided authenticators based on Android versions "N", and
+              later, may provide a "hardware attestation" statement.
+              Specification Document: 
+            
+          
+
+          
       
+      
+      
+        

+          The WebAuthn Extension Identifiers registry's initial contents are:
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_txAuthSimple
+              Description: This signature extension allows for a simple form of transaction authorization. A WebAuthn Relying Party can specify a prompt string, intended for display on a trusted device on the authenticator
+              Specification Document: 
+            
+          
+
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_txAuthGeneric
+              Description: This generic txauth extension allows images to be used as prompts as well. This allows authenticators without a font rendering engine to be used and also supports a richer visual appearance than accomplished with the 
+              webauthn.txauth.simple extension.
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_authnSel
+              Description: This registration extension allows a WebAuthn Relying Party to guide the selection of the authenticator that will be leveraged when creating the credential. It is intended primarily for WebAuthn Relying Parties that wish to tightly control the experience around credential creation.
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_exts
+              Description: The Supported Extensions extension data is a list (CBOR array) of extension identifiers encoded as UTF-8 Strings. This extension is added automatically by the authenticator. This extension can be added to attestation statements.
+              Specification Document: 
+            
+          
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_uvi
+              Description: The user verification index (UVI) is a value uniquely identifying a user verification data record. The UVI data can be used by servers to understand whether an authentication was authorized by the exact same biometric data as the initial key generation. This allows the detection and prevention of "friendly fraud". 
+              Specification Document: 
+            
+                    
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_loc
+              Description: The location extension provides the client device's current
+              location to the WebAuthn relying party, if supported by the client device and
+              subject to user consent.
+              Specification Document: 
+            
+                    
+
+          
+            
+              WebAuthn Extension Identifier: webauthn_uvm
+              Description: The user verification mode (UVM) extension returns to the 
+              Webauthn relying party which user verification methods (factors) were used
+              for the WebAuthn operation.
+              Specification Document: 
+            
+                    
+
+
+          
 
+        
+      
+    
 
+
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    

+      See  for relevant security considerations.
+    

+
+    

+      Note to RFC Editor: Please remove this section before publication.
+      
+      This is the initial -00 rev of this spec, hence no changes to log 
+        here at this time.
+        
+         
+
+    

+
+    

+      Thanks to Mark Nottingham 
+        for valuable comments and suggestions.
+    

+  
+  
+  
+  
+    
+      &rfc2026;
+      &rfc5226;
+      
+
+      
+        
+          Web Authentication: An API for accessing Scoped Credentials
+          
+            Microsoft
+            

+              vijay.bharadwaj@microsoft.com
+            

+          
+  
+          
+            PayPal
+            

+              hlevangong@paypal.com
+            

+          
+          
+          
+            Google
+            

+              balfanz@google.com
+            

+          
+          
+          
+            Google
+            

+              aczeskis@google.com
+            

+          
+          
+          
+            Google
+            

+              arnarb@google.com
+            

+          
+          
+          
+            PayPal
+            

+              Jeff.Hodges@paypal.com
+            

+          
+  
+          
+            Microsoft
+            

+              mbj@microsoft.com
+            

+          
+          
+          
+            Nok Nok Labs
+            

+              rolf@noknok.com
+            

+          
+          
+          
+        
+        
+        
+      
+
+      
+        
+          Android Hardware Attestation
+          
+            Google
+            

+              
+            

+          
+          
+        
+        
+        
+      
+            
+            
+    
+  
+

From f3e6ad2b553c0bc29b8943e76651a8be938454e4 Mon Sep 17 00:00:00 2001
From: =JeffH 
Date: Thu, 1 Sep 2016 15:45:38 -0700
Subject: [PATCH 7/7] editorial cleanups (#185)

* clarify optionality of FIDO MDS.  Fixes #47.

* ref to {#sec-attestation-privacy} section. fixes #100.

* clarify 'algorithm member' language. Fixes #113.

* normalizing indents for markdown, and also line lengths

* fix xref

* incorp feedback from @vijaybh, thanks!
---
 index.bs | 84 +++++++++++++++++++++++++++++++-------------------------
 1 file changed, 47 insertions(+), 37 deletions(-)

diff --git a/index.bs b/index.bs
index e37a4c662..16a7f6bb0 100644
--- a/index.bs
+++ b/index.bs
@@ -1,10 +1,10 @@
-
- Title: Web Authentication: An API for accessing Scoped Credentials
+
+Title: Web Authentication: An API for accessing Scoped Credentials
 Status: ED
 TR: http://www.w3.org/TR/webauthn/
 ED: http://w3c.github.io/webauthn/
 Shortname: webauthn
-Level:
+Level: none
 Editor: Vijay Bharadwaj, Microsoft, vijay.bharadwaj@microsoft.com
 Editor: Hubert Le Van Gong, PayPal, hlevangong@paypal.com
 Editor: Dirk Balfanz, Google, balfanz@google.com
@@ -162,6 +162,12 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
 : Assertion
 :: See WebAuthn Assertion.
 
+: Attestation
+:: Generally, a statement that serves to bear witness, confirm, or authenticate. 
+    In the WebAuthn context, attestation is employed to attest to the provenance of an authenticator and the data it emits; 
+    including, for example: credential IDs, public keys, signature counters, etc. 
+    See also attestation formats, and attestation types. 
+
 : Attestation Certificate
 :: A X.509 Certificate for a key pair used by an Authenticator to attest to its manufacture and capabilities. The
     Authenticator uses the attestation private key to sign the [RP]-specific public key (and additional data) it
@@ -533,8 +539,8 @@ authorizing an authenticator with which to complete the operation.
 
     The type member specifies the type of credential to be created.
 
-    The algorithm member specifies the cryptographic algorithm with which the newly generated credential will be
-    used.
+    The algorithm member specifies the cryptographic signature algorithm with which the newly generated credential
+    will be used, and thus also the type of asymmetric key pair to be generated, e.g., RSA or Elliptic Curve.
 

 
 
@@ -659,7 +665,7 @@ providing provenance information for the attesting key, enabling a trust decisio
     must be preserved as the hash (clientDataHash) has been computed over it.
 
     The statement element contains the actual attestation statement. The structure of this object depends on the
-    attestation format. For more details, see [[#attestation]].
+    attestation format. For more details, see [[#cred-attestation-stmts]].
 

 
 This attestation statement is delivered to the [RP] by the [RP]'s script running on the client, using methods outside
@@ -826,7 +832,7 @@ generates an identifier for the credential, such that this identifier is globall
 credentials with the same type across all authenticators. It then associates the credential with the specified RP ID hash such
 that it will be able to retrieve the RP ID hash later, given the credential ID. Finally, it generates an attestation statement
 that describes its own attributes as well as some attributes of the credential. For more details on attestation, see
-[[#attestation]].
+[[#cred-attestation-stmts]].
 
 On successful completion of this operation, the authenticator returns the following to the client:
 
@@ -1002,31 +1008,33 @@ MUST return clientDataJSON, authenticatorData and the signature to
 in the `clientData` member of the {{WebAuthnAssertion}} and {{WebAuthnAttestation}} structures.
 
 
-## Credential Attestation Statements ## {#attestation}
+## Credential Attestation Statements ## {#cred-attestation-stmts}
 
 An attestation statement is a specific type of signature, which contains statements about a credential itself and the
 authenticator that holds it. Therefore, the procedures for generating attestation statements closely parallel those for
 generating WebAuthn assertions as described in [[#signature-format]], though the semantics of the contextual bindings are quite
 different.
 
-This specification defines a number of attestation formats, i.e., ways to serialize the data being attested to by the
-Authenticator. The reason is to be able to support existing devices like TPMs and other platform-specific formats. Each
-attestation format provides the ability to cryptographically attest to a public key, the authenticator model, and contextual data
-to a remote party. They differ in the details of how the attestation statement is laid out, and how its components are computed.
-The different attestation formats are defined in [[#defined-attestation-formats]].
+This specification defines a number of attestation formats, i.e., ways to serialize the data being attested to by an
+Authenticator. The reason is to be able to support existing devices such as TPMs and other platform-specific formats. 
+Each attestation format provides the ability to cryptographically attest to a public key, the authenticator model, and 
+contextual data to a remote party. They differ in the details of how the attestation statement is laid out, and how its 
+components are computed. The different attestation formats are defined in [[#defined-attestation-formats]].
 
-This specification also defines a number of attestation types. These define how a [RP] establishes trust in a particular
-attestation statement, after verifying that it is cryptographically valid.
+This specification also defines a number of attestation types. These define how a [RP] establishes trust in a 
+particular attestation statement, after verifying that it is cryptographically valid.
 
 Attestation formats are orthogonal to attestation types, i.e. attestation formats in general are not restricted to a single
 attestation type. For example, the "packed" attestation format (see below) can be used in conjunction with all attestation types.
 Broadly speaking, attestation formats pertain to the formatting / encoding of the attestation statement
 rawData, while attestation types pertain to the semantics.
 The privacy, the security and the operational characteristic of attestation mainly depends 
-on the attestation type while it is largely independent from the attestation format.
-
+on the attestation type while it is largely independent from the attestation format. 
+Specific privacy considerations are given in [[#sec-attestation-privacy]]. 
 
-### Attestation Types ### {#attestation-types}
+
+### Attestation Types ### {#sctn-attestation-types}
 
 WebAuthn supports multiple attestation types:
 
@@ -1057,7 +1065,7 @@ WebAuthn supports multiple attestation types:
     [[FIDOEcdaaAlgorithm]]) in this specification.
 
 
-Compliant servers MUST support all attestation types. Authenticators can choose what attestation type to implement.
+Compliant servers MUST support all attestation types. Authenticators MAY choose which attestation type to implement.
 
 Note: [RPS] can always decide what attestation types are acceptable to them by policy.
 
@@ -1070,8 +1078,9 @@ Upon receiving an attestation statement, the [RP] shall:
 1. Verify that the attestation statement is properly formatted.
 
 2. If `alg` is not ECDAA (e.g., not "ED256" and not "ED512"):
-    - Look up the attestation root certificate from a trusted source. The FIDO Metadata Service [[FIDOMetadataService]] provides
-        an easy way to access such information. The `claimedAAGUID` can be used for this lookup.
+    - Look up the attestation root certificate from a trusted source. 
+        For example, the FIDO Metadata Service [[FIDOMetadataService]] provides
+        one way to access such information. The `claimedAAGUID` can be used for this lookup.
     - Verify that the attestation certificate chain is valid and chains up to a trusted root (following [[RFC5280]]).
     - Verify that the attestation certificate has the right Extended Key Usage (EKU) based on the WebAuthn Authenticator type
         (as denoted by the `type` member). In case of a type="tpm", this EKU shall be OID "2.23.133.8.3". Defined attestation
@@ -1088,8 +1097,9 @@ Upon receiving an attestation statement, the [RP] shall:
     - If such extension doesn't exist, the attestation root certificate is dedicated to a single Authenticator model.
 
 3. If `alg` is ECDAA (e.g., "ED256", "ED512"):
-    - Look up the DAA root key from a trusted source.  The FIDO Metadata Service [[FIDOMetadataService]] provides an easy way to
-        access such information. The `claimedAAGUID` can be used for this lookup.
+    - Look up the DAA root key from a trusted source.  
+        For example, the FIDO Metadata Service [[FIDOMetadataService]] provides one way to access such information. 
+        The `claimedAAGUID` can be used for this lookup.
     - Perform DAA-Verify on `signature` for `rawData` (see [[!FIDOEcdaaAlgorithm]]).
     - Verify `rawData` syntax and that it doesn't contradict the signing algorithm specified in `alg`.
     - The DAA root key is dedicated to a single Authenticator model.
@@ -1097,7 +1107,7 @@ Upon receiving an attestation statement, the [RP] shall:
 4. Verify the contextual bindings (e.g., token binding) from the `clientData` (see [[#authenticator-signature]]).
 
 5. Verify that user verification method and other authenticator characteristics related to this authenticator model, match the
-    [RP] policy. The FIDO Metadata Service [[FIDOMetadataService]] provides an easy way to access the authenticator
+    [RP] policy. For example, the FIDO Metadata Service [[FIDOMetadataService]] provides one way to obtain authenticator 
     characteristics.
 
 The [RP] MAY take any of the below actions when verification of an attestation statement fails:
@@ -1105,9 +1115,9 @@ The [RP] MAY take any of the below actions when verification of an attestation s
 - Reject the request, such as a registration request, associated with the attestation statement.
 
 - Accept the request associated with the attestation statement but treat the attested Scoped Credential as one with surrogate
-    basic attestation (see [[#attestation-types]]), if policy allows it. If doing so, there is no cryptographic proof that the
-    Scoped Credential has been generated by a particular Authenticator model. See [[FIDOSecRef]] and [[UAFProtocol]] for more
-    details on the relevance on attestation.
+    basic attestation (see [[#sctn-attestation-types]]), if policy allows it. If doing so, there is no cryptographic proof 
+    that the Scoped Credential has been generated by a particular Authenticator model. See [[FIDOSecRef]] and [[UAFProtocol]]
+    for more details on the relevance to attestation.
 
 Verification of attestation statements requires that the relying party trusts the root of the attestation certificate chain.
 Also, the [RP] must have access to certificate status information for the intermediate CA certificates. The relying party must
@@ -1152,14 +1162,14 @@ unless the WebAuthn Authenticator manufacturer has this capability.
 
 If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [RP]'s policy
 requires rejecting the registration/authentication request in these situations, then it is recommended that the [RP] also
-un-registers (or marks as "surrogate attestation" (see [[#attestation-types]]), policy permitting) scoped credentials that were
-registered post the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus
+un-registers (or marks as "surrogate attestation" (see [[#sctn-attestation-types]]), policy permitting) scoped credentials that
+were registered post the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus
 recommended that [RPS] remember intermediate attestation CA certificates during Authenticator registration in order to
 un-register related Scoped Credentials if the registration was performed after revocation of such certificates.
 
 If a DAA attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked authenticators)
 maintained by the related DAA-Issuer. The [RP] should verify whether an authenticator belongs to the RogueList when performing
-DAA-Verify. The FIDO Metadata Service [[FIDOMetadataService]] provides an easy way to access such information.
+DAA-Verify. For example, the FIDO Metadata Service [[FIDOMetadataService]] provides one way to access such information.
 
 
 #### Attestation Certificate Hierarchy #### {#cert-hierarchy}
@@ -1173,9 +1183,9 @@ must be specified either in the attestation certificate itself or it must be spe
 
 # Defined Attestation Formats # {#defined-attestation-formats}
 
-WebAuthn supports pluggable attestation data formats. This allows support of TPM generated attestation data as well as support of
-other WebAuthn authenticators. As mentioned in [[#attestation]], these differ in how the attestation statement is
-computed and formatted. This section defines these details.
+WebAuthn supports pluggable attestation data formats. This allows support of TPM generated attestation data as well as support
+of other WebAuthn authenticators. As mentioned in [[#cred-attestation-stmts]], these differ in how the attestation
+statement is computed and formatted. This section defines these details.
 
 The contents of the attestation data must be controlled (i.e., generated or at least verified) by the authenticator itself.
 
@@ -1374,8 +1384,8 @@ The attestation certificate MUST have the following fields/extensions:
 - 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]].
+    are both optional as the status of many attestation certificates is available through authenticator metadata services. 
+    See, for example, the FIDO Metadata Service [[FIDOMetadataService]].
 
 
 ## TPM Attestation ("tpm") ## {#tpm-attestation}
@@ -1433,8 +1443,8 @@ TPM attestation certificate MUST have the following fields/extensions:
 - 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 many attestation certificates is available through metadata services. 
+    See, for example, the FIDO Metadata Service [[FIDOMetadataService]].
 
 
 ## Android Attestation (type="android") ## {#android-attestation}