Re: [spec-reviews] Review FIDO spec (#97)

Reviewed this in Melbourne ([raw minutes](https://pad.w3ctag.org/p/14-01-2016-minutes.md))

Points to review with FIDO folks/WG when it get started below:
TODOs:
    - clarification on mismatch between [WebCrypto](https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html), [FIDO Signature Format](https://www.w3.org/Submission/2015/SUBM-fido-signature-format-20151120/), [JWA nomenclature on hash algorithm naming](https://www.w3.org/Submission/2015/SUBM-fido-signature-format-20151120/#widl-ClientData-hashAlg)
    - clarification on some data structures
    - `Credential` interface, e.g.:
 - `type`
 - `id`
 - `imageUri` (align with manifest syntax for multiple sizes?) in [User Account Information](https://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/#dom-account-imageuri)
    - reasons for [eTLD+1 rather than origin](https://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/#dom-fidocredentials-makecredential) (and unclear wording in section about how the origin and RP ID are used in authenticator operations)
    - feedback on the API design
       - options object instead of optional params?
       - clarify the `Credential` interface between Credential Management draft and FIDO drafts
    - specs need more examples & explainer doc, e.g. end-to-end code for Credentials + FIDO?
    - specs need more links of terms to their definitions
    - request time to meet at a TAG call

We also compared it to previous requirements for keygen replacement ([here](http://w3ctag.github.io/client-certificates/#requirements-and-recommendations)), and found that it meets the requirements. However, it does not provide a way to generate credentials that are not origin-specific. Though this was not a specific requirement, some folks were interested in having that capability for identity purposes. We note that FIDO is not trying to provide identity, only authentication.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-171519930

Received on Thursday, 14 January 2016 03:35:51 UTC