w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials

Web Authentication Specification

This is the repository for the W3C WebAuthn Working Group, producing the draft "Web Authentication" specification.

• The editor's copy is available at https://w3c.github.io/webauthn/, or in the gh-pages branch of this repository.
  • The current offically-published working-draft snapshot is here: https://www.w3.org/TR/webauthn/.
• The build history is available from the repo Actions tab
• W3C WebAuthn Blog
• Web platform tests repository

Contributing

To materially contribute to this specification, you must meet the requirements outlined in CONTRIBUTING.md. Also, before submitting feedback, please familiarize yourself with our current issues list and review the mailing list discussion.

Building the Draft

Formatted HTML for the draft can be built using bikeshed (see below for instructions for bikeshed installation):

$ bikeshed spec

You may also want to use the watch functionality to automatically regenerate as you make changes:

$ bikeshed watch

Bikeshed Installation and Setup

See the full instructions at https://tabatkins.github.io/bikeshed/#installing.

You will need to have the Python 3.7 or later installed. Once you do have Python 3.7 or later installed, to install Bikeshed itself, run the following:

pip3 install bikeshed && bikeshed update

When that is completed, Bikeshed should be installed, and the bikeshed command should work in your shell.

Continuous Integration & Branches

https://w3c.github.io/webauthn/ is autopublished from the gh-pages branch on every push to the main branch, using https://github.com/w3c/webauthn/blob/main/.github/workflows/build-validate-publish.yml to configure the autopublishing behavior.

Creating a new Working Draft

To build a new WD and upload it to the W3C publishing system:

• Register as a W3C member and join the Web Authentication working group. Note down your W3C USERNAME and PASSWORD to use in the command below. If you don't remember either one, please go here to retrieve it.
• Copy the url of the meeting minutes in which the working group decided to publish a new draft as the DECISION_URL to be used below
• Make sure Bikeshed is installed locally (follow the Bikeshed Installation and Setup section above)
• Go into the ./bikeshed directory and use git pull to update Bikeshed.
• Run the following command to update Bikeshed's datafiles:

bikeshed update

• Edit the Bikeshed metadata to change the status from ED to WD (do not commit this change)
• Ensure Bikeshed can compile without any error or warning by running through the following command:

bikeshed spec

• Build and upload the new draft with

bikeshed echidna --u USERNAME --p PASSWORD --d DECISION_URL

The command above will create a tarball of the HTML and images, and upload to Echidna, W3C's automated publishing system. The command should return a url, thhrough which you can know whether you successfully publish the draft. Status of the request can also be tracked through the Mailing List Archive. You can also use W3C API as described in the Echidna documentation. Note that on Windows, this will give an error about failing to delete a temporary file because it is in use by a different process. This error is harmless; it happens after the submission has completed.

If the publication through the process is unsuccessful, it's likely because of Specbreus, a spec compliance checker. Echidna automatically runs through Specbreus and will reject the publication if any error is reported by Specbreus. You can run your document through Pubrules to understand why your document is rejected. You may modify either the index.bs file or the index.html file to ensure compliance.

More often than not, you will discover the Pubrules errors are due to bugs in either Bikeshed or Specbreus. If so, you will have to modify the compiled index.html file to bypass Echidna and use the manual process to publish. While you are editing the html file to avoid errors, you should also check to ensure the document still renders correctly.

The manual process requires you to first create a tar file. To create the tar file, you need to first copy the index.html file and rename the copied file as Overview.html. This is because Echidna doesn't recognize index.html. You can then use the following command to create a tar file:

tar -cvf WD.tar Overview.html image1 image2 image3

Then you can run the following command curl to publish to Echidna (use the command at the same directory as your tar file):

curl 'https://labs.w3.org/echidna/api/request' --user '<username>:<password>' -F "[email protected]" -F "decision=<decisionUrl>"

Feel free to contact your chair or any W3C staff when you are stucked. Overall info on echidna is here: https://github.com/w3c/echidna/wiki and here https://labs.w3.org/echidna/.

Taking meeting minutes

• Scribe instructions from the W3C Guidebook
• Alternate instructions from the XML Security WG

webauthn's Issues

key-attestation: S 2.3 "attestation types" -- move into S 2.1 "attestation models" ?

Originally submitted by: equalsJeffH, on: Tuesday Oct 27, 2015 at 07:52 GMT

---

what's difference between "2.1 attstn models' and '2.3 attstn types' ?

suggest moving S 2.3 into S 2.1 (as subsection?) and clearly defining the difference between "attstn models" and "attstn types"

Silent/touchless Authn? clarification of bit 0 in AuthenticatorData

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:43 GMT

---

Section 4. Authenticator data

re: authenticatorData bit 0. In which case the authenticator will generate a signature without first detecting/verifying user presence via some authenticator specific gesture? Does FIOD 2.0 support silent authentication? If not, I suppose the TUP bit will always be set if an assertion is generated.

SigFormat: Clarification of assertion delivery in platform specific manner

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:45 GMT

---

Section 6.1 Attributes

Last paragraph reads “This assertion is delivered to the RP in either a platform specific manner, or in the case of web applications, according to the FIDO Web API [FIDOWebApi]. It contains all the…”. In case of non-web applications, if the assertion is delivered to the RP in a platform specific manner it will imply that the RP will have to support multiple platform-specific encodings/formats and perhaps protocol? Is this the intention?

need description & illustrations of overall flow: authnr <--> platform API <--> RP

Originally submitted by: equalsJeffH, on: Tuesday Oct 06, 2015 at 18:42 GMT

---

The fido-2 specs so far lack a cohesive exposition of the overall flow: authnr <--> platform API <--> RP

the fido-u2f-raw-message-formats spec covers this in its section 1 Introducion, and has figure 1 illustrating it. Similar discussion and illustrations are in fido-uaf-protocol --- I suggest we have a similar exposition and figure(s) in the fido-2 specs that are slated for W3C submission.

I also note that I was asked about this by a smart person who was looking at the fido-2 specs and couldn't figure out "where the protocol is"

key-attestation: lacks explanation of "attestation"

Originally submitted by: equalsJeffH, on: Tuesday Oct 27, 2015 at 07:39 GMT

---

the key-attestation spec open with section 1 "notation", and then section 2 Overview listing four attestation models, but does not provide the reader with an introduction to the concept of "attestation" and why it is of interest in some use cases.

Verification of publicKey missing in section 3.5 Verifying an Attestation Statement

Originally submitted by: rlin1, on: Friday Jan 08, 2016 at 09:06 GMT

---

the verification of the publicKey is missing.
Idea:
Get publicKey from Credential structure.
Depending on core.type do:
(1) "packed": compare with core.rawData.publicKey
(2) "tpm": compute digest of publicKEy and compare against TPMS_ATTEST.qualifiedSigner or TPM_CERTIFY_INFO/TPM_CERTIFY_INFO2.pubKeyDigest.
(3) "safetynet": compare with header.clientData.publicKey

Genericize nomenclature, where possible

Where possible, replace references to the "FIDO" trademark in the specification.

(From https://www.w3.org/2016/03/16-webauthn-minutes.html#action02)

WebAPI: USB fob use case

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:04 GMT

---

Section 1.3 Other configurations
I suggest to add:
o The external authenticator can be a USB fob without a display. User interactions with the authenticator e.g. Select an identity from a list, are done through the browser.

web-api: is further language needed describing AppID (aka rpId) usage ?

Originally submitted by: equalsJeffH, on: Monday Aug 24, 2015 at 20:07 GMT

---

in PR #78 "We need to talk about RP IDs (nee App IDs) here", @balfanz notes:

when the calling app is an Android app there is no callerOrigin for the platform to send to the Authenticator.

My main question regarding incorporating PR #78 is: given web-api is explicitly a "web api" spec, do we really want/need to address the AppID/rpID-for-native-apps use case in the web-api spec ? i.e., is it appropriate?

I am thinking that we should perhaps note the AppID/rpID-for-native-apps aspect in a non-normative NOTE in web-api, and add further language to platform-api-reqs.

Thus I do not recommend merging PR #78 to master as yet.

Plus, PR #89 would change the markup of PR #78 somewhat. [this is now moot, PR#89 was merged to master on 25-Aug - JeffH]

See also wrt the term "rpId": #91

encodedClientData should be clientDataJSON ?

Originally submitted by: equalsJeffH, on: Monday Dec 07, 2015 at 20:11 GMT

---

section 3.1 of signature-format says down near end: "The client platform SHOULD also preserve the exact encodedClientData string used to create [clientDataHash],"

also, in S 3.2.2 of key-attestation, it says " The client platform MUST also preserve the exact encodedClientData string (see [FIDOSignatureFormat]),"

encodedClientData should be clientDataJSON in both places ?

TAG review feedback: Should we be using array types instead of base64-encoded DOMStrings?

I believe Alex Russell mentioned this in person at the San Francisco F2F, elaborating on comments in w3ctag/design-reviews#97

It may seem more natural to use BufferSource, ArrayBuffer, or ArrayBufferView in various places where we have base64-encoded DOMStrings currently. This may also make it easier for script authors to manipulate these locally if needed (e.g. WebCrypto APIs take array types) and it avoids prescribing the use of base64.

The FIDO Metadata Service needs a non-FIDO analogous mechanism

Right now the WebAuthn specification utilizes the FIDO Metadata Service to determine facts about authenticators, such as characteristics and certificates. We should consider developing a similar capability that does not depend on one organization.

key-attestation: KeyHandle in attestaion rawData type="packed"

Originally submitted by: equalsJeffH, on: Tuesday Dec 08, 2015 at 00:07 GMT

---

section "3.4.1.1 Attestation rawData (type="packed")" -- in the rawData table, after the public key and before clientDataHash length, there is a KeyHandle and its length, like so..

2           Byte length l of KeyHandle
(length)    KeyHandle (l bytes)

What is this for? is it extraneous? it is not mentioned elsewhere in this spec or in the other two specs.

WebAPI: Credential Identifier scope

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:20 GMT

---

Section: .5.1 Credential Type enumeration (enum CredentialType)

Does the ID need to be globally unique across platforms/authenticators and Accounts that are associated with the same RP?

WebAPI: Authentication failure due to inactivity

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:24 GMT

---

Section 5.2 Authentication
• re: step 9.b if de-registration of the public key on the server due to inactivity resulted on the credential being removed from the authenticator these type of authentication failures - which can frustrate users- can be avoided.

TAG review comments on eTLD+1

w3ctag/design-reviews#97

Put all the extensions in one spot

Originally submitted by: leshi, on: Friday Aug 28, 2015 at 16:33 GMT

---

Right now, extensions are both in attestation and in web api. Let's put them in one spot

WebAPI: FIDO Authenticator model - clarifications needed

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:07 GMT

---

1. webauthn Authenticator model
   You may want to explain and/or clarify in this section if :

a) More than 1 webauthn credentials on the same authenticator can be associated with a single account at the Relying party? e.g. a privileged shared account that is accessed from the same desktop station with an embedded webauthn authenticator. Each one of the users of the shared account may use their own Biometric gestures to unlock their own credential for identification.

b) One webauthn credential can be associated with more than one user accounts with the same Relying Party? If so we will have to revisit the registration flow. If not and a webauthn credential must be unique per-user account/identity per-RP then it needs to be stated.

c) A user could register more than one authenticator (a mix of embedded and external authenticator) with the same Relying party and associated with the same user account?

d) Cloned webauthn credentials are allowed? I assume not, but how would the RP ensure that the webauthn credential is bound to one authenticator?

WebAPI: Registration (embedded authenticator mode) use cases assumptions

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 00:58 GMT

---

Section 1.1 Registration (embedded authenticator mode)
We shouldn’t always assume that the user has an existing account and existing credentials to sign in first and then register FIDO credentials. We should consider the case where FIDO credentials could be “the only” or “the primarily” credentials to register as part of the account creation. If the goal is to get rid of passwords, we shouldn’t assume or require passwords to register and recover FIDO credentials.

SigFormat: clarification of FIDOWebAPI scope

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:40 GMT

---

Section 2. Overview

3rd paragraph reads: “When the RP client-side application is a web-application, the interface between 1 and 2 is the FIDO 2.0 Web API [FIDOWebApi], but is platform specific for native applications.” Does the text "but is platform specific for native applications" means that FIDOWebAPI is not relevant to native apps using FIDO 2.0 for authentication and the expectation is that platform vendors will provide custom APIs?

Abstraction layer for attestations

We are looking for the correct way to define an abstraction for attestations so that we don't have to go to operating-system particular (i.e. Android) discussions in the W3C spec.

TAG review feedback: Align Credential interface with Credential Management?

w3ctag/design-reviews#97

Should we remove the algorithm from FIDOCredentialInfo?

Originally submitted by: vijaybh, on: Friday Jan 15, 2016 at 21:48 GMT

---

The public key returned by makeCredential is not meant to be examined by the client, it is only relevant to the RP. So it seems better to return it in a compact format as is done by EAP, and not bother with algorithm at all.

Should a FIDOAssertion on an Android platform use AndroidAttestationClientData?

Originally submitted by: levangongPayPal, on: Wednesday Dec 09, 2015 at 01:08 GMT

---

Section 3.4.3.3 indicates that the Android attestation statement uses an extended version of the clientData structure defined in the Signature spec (called AndroidAttestationClientData).

On Android platform, should a FIDOAssertion also use the same definition or stick to the structure defined in the Signature spec?

Where should transport hints go?

Originally submitted by: balfanz, on: Wednesday Aug 19, 2015 at 22:20 GMT

---

We currently don't have a way to hint to the platform which transports an Authenticator supports. The RP shouldn't have to be consciously aware of this (hence we don't have a parameter for this in the API). Instead, the transport hints need to be encoded somewhere else - perhaps as part of the Credential IDs. We need to figure out how we're going to do this.

WebAPI: Glossary needed

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:29 GMT

---

I suggest adding some term definitions to the spec. For example it is not obvious from reading first sections what the term “client” refers to. FIDO 1.0 Glossary could be reused or extended and referred to.

WebAPI: credential binding to a user account

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:10 GMT

---

Section 3.1 The authenticatorMakeCredential operation

It is not clear here if the new credential is associated with the user /account ID in addition to the RP ID. I assume it is, but it is not stated.

Key-Attestation: no point compression in the Packed attestation

Originally submitted by: levangongPayPal, on: Thursday Dec 10, 2015 at 00:44 GMT

---

What is the reasoning for not supporting point compression for the EC key in the packed attestation?

WebAPI: need to propagate credential de-commissioning through the system

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:28 GMT

---

Section 5.3 Decommissioning
• I don’t see why decommissioning a credential at the RP operation is no propagated to the authenticator or why the user cannot be notified (incl out of band) about the event. The user is still in control and can choose not to delete the credential on the authenticator but at least they will be notified that their credential is no longer accepted at the RP.

WebAPI: Example syntax errors

Originally submitted by: mirkop, on: Friday Dec 18, 2015 at 19:11 GMT

---

The following syntax errors should be corrected in the examples as indicated by the comments "// <<<<<".

EXAMPLE 1

var userAccountInformation = {
  rpDisplayName: "PayPal",
  displayName: "John P. Smith",
  name: "[email protected]",
  id: "1098237235409872";  // <<<<< Change this ';' to a ','
  imageUri: "https://pics.paypal.com/00/p/aBjjjpqPb.png"
};

var cryptoParams = [
  { 
    type: "FIDO",
    algorithm: "ES256", // <<<<< Remove ','
  },
  {
    type: "FIDO",
    algorithm: "RS256", // <<<<< Remove ','
  }
];

EXAMPLE 2

var acceptableCredential1 = {
  type: "FIDO",
  id: "ISEhISEhIWhpIHRoZXJlISEhISEhIQo=", // <<<<< Remove ','
};
var acceptableCredential2 = {
  type: "FIDO",
  id: "cm9zZXMgYXJlIHJlZCwgdmlvbGV0cyBhcmUgYmx1ZQo=", // <<<<< Remove ','
};

Usability Issue: Account Deletion

Originally submitted by: rlin1, on: Monday Oct 19, 2015 at 15:02 GMT

---

Scenario
• Using web app

• User has created FIDO credentials for 2 different accounts at the same RP (i.e. user 
  has registered same authenticator to same RP twice using different accountInfos).

• User deletes account 1 via the App.  The App will trigger “revocation” (or deletion) 
  of the related  FIDO Credential on the Server (according to fido-web-api).

• The fido-credential will still be present on the user device as fido-web-api doesn’t allow 
  programmatic deletion of the FIDO credential locally.

• Notes:
    o   In a 2nd factor scenario that won’t be an issue the server will never send the 
        related credentialID to the app.
    o   In a 1st factor scenario this WILL be an issue if web browser doesn’t have access 
        to synchronized persistent storage (across web browsers).  Example: Use Mobile Phone 
        as authenticator for web browsers on PC1 and PC2 or after cookie deletion etc.  In such 
        a case we would require the user to delete the credential on the authenticator first or 
        on web account and additionally on the authenticator.

Key-Attestation: Packed attestation length

Originally submitted by: levangongPayPal, on: Wednesday Dec 09, 2015 at 01:16 GMT

---

Section 3.4.1 states that the packed attestation length is "45 bytes + length of public key + length of KeyHandle + potentially more extensions".
It should say: "15 bytes + length of public key + length of KeyHandle + length of clientDataHash + potentially more extensions"

Add a Terminology Section

Some terms like Relying Party are known sources of confusion. We should add a terminology section to the specification that explains particular terms.

If you have a known confusable term, please add a comment to this issue so I can pick those up, too.

ED512 Support

Originally submitted by: apowers313, on: Tuesday Feb 09, 2016 at 06:15 GMT

---

Key Attestation Section 3.5 refers to ED512. Since ED512 isn't one of the algorithms that must be supported by a FIDO server, it seems like this might be a leftover artifact of #94 and due for removal.

Usability Issue: Server Challenge timeout

Originally submitted by: rlin1, on: Monday Oct 19, 2015 at 15:00 GMT

---

Scenario:

• Attempt 1:
    o   User starts registration of an authenticator:  
         The App retrieves the server challenge (the server assigns a maximum time 
           to live of X minutes to it).
         The App calls makeCredential and receives the response (i.e. the attestationStatement).

    o   Connection drops (e.g. user is on train entering a tunnel, battery dead, 
         provider outage, …)

    o   App cannot send the response to the server and returns an error to the user.

    o   Connection is restored after X+1 (or more) minutes and server will not accept the 
         registration response.

• Attempt 2:
    o   User re-starts registration of the same authenticator for same account:
         The App retrieves new challenge from the server.
         The App calls makeCredential and receives the fresh response
            (i.e. the attestationStatement).  

    o   Note 1: re-using the old credential from Attempt 1, i.e. skipping makeCredential 
         and first trying sign doesn’t help as the server won’t accept it without a fresh 
         attestationStatement.

    o   Note 2: at this time we don’t specify whether makeCredential MUST create a new key 
         for the same account or re-use the old one.  

all specs: update names used in examples to be faux entities

Originally submitted by: equalsJeffH, on: Friday Dec 18, 2015 at 18:13 GMT

---

all specs: update names used in examples to be faux entities -- eg rather than using "paypal.com", use something like "example.com"

Fix the licensing statement

Not sure why the draft has a public domain declaration, but W3C specs should be under the W3C Document License, https://www.w3.org/Consortium/Legal/2015/doc-license

Move extension specification out of signature format

Originally submitted by: kyang1, on: Friday Aug 21, 2015 at 23:00 GMT

---

Extension specification should be moved out of signature format spec for the following reasons:

1. Current description of extensions in the signature format is too specific to getAssertion method and FIDOAssertion object. It is inappropriate to refer to it for places where extensions are used in the context of makeCredential and AttestationStatement.
2. The way that extensions shall be processed by both the client and the authenticator for makeCredential and getAssertion are the same. It doesn't make much sense to describe the same thing twice in two specifications.

If WebAPI is not a good place, platform requirement may be another option.

Underspecified error conditions

I don’t see anything in the WebAPI that defines what errors get thrown or how promises get resolved with various error conditions when arguments are passed in wrong. For example, what is the result if getAssertion is called without the assertionChallenge argument; or what is the result if the accountInformation argument of makeCredential doesn’t contain a displayName attribute?

A comment from @vijaybh :

I think there are three buckets of errors that I would write into the spec:

1.   Errors that violate the IDL (like the example below, where getAssertion is called without a challenge) – these should not need to be talked about since the IDL layer should reject it with something like SyntaxError.
   

2.   Errors that arise from bad or mutually contradictory parameters – e.g. asking to create a credentials with crypto parameters this UA does not support.
   

3.   Stuff that goes wrong – e.g. authenticator runs out of memory when generating an assertion.
   

For #2 and #3 the TAG guidance is to always return a Promise, and reject it with a DOMException or Error in case anything goes wrong. So this is really an exercise in going through the spec, identifying where things can go wrong, and providing an Error or DOMException for each such situation. If you open an issue in the W3C Github and assign it to me, I can take a pass at it.

I would add:
4. Authenticator rejects / times out when generating an attestation
5. The blacklist prevents a valid attestation

I think those two are spelled out in the spec, but the result is that they “generate an appropriate error”.

WebAPI: add userID as input parameter in authenticatorGetAssertion

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:11 GMT

---

Section 3.2 The authenticatorGetAssertion operation
It will be useful to include the userID as an input parameter, specifically if the authenticator is used as a second factor. The user doesn’t have to select an identity if more than one FIDO credentials are associated with the same origin

Credential.id currently assumed to be RP unique

Originally submitted by: rlin1, on: Friday Jan 08, 2016 at 12:04 GMT

---

getAssertion returns Assertion. Assertion includes id as the only method to map it to a specific user account.
Until now FIDO assumed the pair of (AAID/AAGUID/attestationCertificateKeyIdentifier, KeyID) to be RP unique.
In FIDO2 KeyID has been replaced by Credential.id.
At this time there is no guaranteed way to derive the AAGUID from a FIDOAssertion.
As a result we implicitly assume KeyID (i.e. Credential.id) to be RP unique.

Rename WebAuthnAssertion / getAssertion

@vijaybh noted in the discussion around PR #48:

It seems inconsistent to say WebAuthAssertion but not WebAuthAttestationStatement for example. OTOH Assertion seems too generic. Your thoughts?

We should discuss those names.

Merge all the specs into one

Merge all three documents into one document making sure to keep connective tissue intact.

SigFormat: Question on FIDO 2.0 layers

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:38 GMT

---

section 2. Overview

Given the FIDO 2.0 layers, could a RP build a native app (such as a mobile app) with an embedded authenticator without depending on the fido client platform layer?

TAG review feedback: imageUri

w3ctag/design-reviews#97

imageUri should be renamed to imageURL, and could be aligned with manifest syntax for multiple sizes.

Define AuthenticatorVersion extension

Originally submitted by: rlin1, on: Friday Jan 08, 2016 at 12:16 GMT

---

At this time only TPMs include the AuthenticatorVersion.
We want the ability to include the AuthenticatorVersion in attestation "packed" and also FIDOAssertion.authenticatorData.

authenticatorMakeCredential and authenticatorGetAssertion parameters not uniformly specified

Originally submitted by: equalsJeffH, on: Monday Dec 07, 2015 at 20:48 GMT

---

web-api section "3.1 The authenticatorMakeCredential operation" specifies the authenticatorMakeCredential() parameters, however, the parameter set does not match with the param set given in "4.1.1 Create a new credential (makeCredential method)" step (8), nor with the implied params given in signature-format S 3.1 -- e.g., clientData and clientDataHash are not mentioned in web-api.

there are similar issues between sections "3.2 The authenticatorGetAssertion operation" and "4.1.2 Use an existing credential (getAssertion method)" in web-api

WebAPI: Clarification Credential Type

Originally submitted by: smachani1, on: Monday Oct 05, 2015 at 01:18 GMT

---

Section 4.5.1 Credential Type enumeration (enum CredentialType)

"Type" in 4.52 refers to credential seems to refer to "Type" that is described in the above paragraph but the description is not explicit and reads as if it was a different type. It will be clearer if CredentialType is referred in the description.

AAGUID extension underspecified

The description of AAGUID extension in attestation certificate in FIDO 2 is little under-specified. See https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/#attestation-statement-certificate-requirements

Look at he extension value for Extension OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid).

Structure of Credential ID

Originally submitted by: leshi, on: Thursday Jan 14, 2016 at 22:33 GMT

---

From the current Web API spec https://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/:

The id attribute contains an identifier for the credential, chosen by the platform with help from the authenticator. This identifier is used to look up credentials for use, and is therefore expected to be globally unique with high probability across all credentials of the same type. This API does not constrain the format or length of this identifier, except that it must be sufficient for the platform to uniquely select a key.

The Platform/Client will want to specify various metadata wrt to the id. For example, which transports the id should be sent over. Since various Platforms/Clients should be able to understand the metadata (i.e., Windows should be able to tell Android that an id is only useful over USB and should not be sent over BLE), the format of this metadata should be standardized.

It's not clear where this standardization should take place. One option is to make the Credential ID be an object in the Web API.