Re: [w3ctag/spec-reviews] Credential Management API (#49)

Latest FIDO (Now Web Authentication): https://w3c.github.io/webauthn/
Credential Management L1: https://w3c.github.io/webappsec-credential-management/

Previous questions (from [20 May 2015 teleconference](https://github.com/w3ctag/meetings/blob/gh-pages/2015/telcons/05-20-credentials%26fingerprinting-minutes.md))
* security of the name (`idName`) attribute when reading after transferring to alternate origin (mnot)
   * This appears to be addressed in that `SiteBoundCredential::name` and `SiteBoundCredential::iconURL` are both `readonly` now. Other related security and privacy considerations are outlined in: https://w3c.github.io/webappsec-credential-management/#security-cross-origin-leakage, and this seems complete (as expected from Mike West).

Relationship and alignment of `Credential` between Web Authentication and Credential Management.
* WebAuthn doesn't seem to [take any dependency ](https://w3c.github.io/webauthn/#dependencies)on Credential Management
    * Uses a generic (but matching) description of `interface Credential`. The type is `"ScopedCred"` (case-mismatch with other types defined in Credential management: `"password"`, `"federated"`
    * There are some weird mis-matches between Credential management's `SiteBoundCredential` and Web Authentication's [`ScopedCredentialInfo`](https://w3c.github.io/webauthn/#scopedcredentialinfo). However, they look to be roughly compatible, though I expect Web Authentication may need to refactor a bit for the two specs to align better. (e.g., I recommend that Web Authentication sub-class the `SiteBoundCredential`. It's unclear why Web Authentication would want to leverage the Credential Management storage system (vs. just IndexedDB), since their ScopedCredentialInfo objects (and the Credential they contain) are primarily used during registration (to be sent back to the server), or optionally to help in UI selection assistance during later getAssertion() calls--but is not really even needed then (getAssertion, on success, returns the asserted credential needed to send back to the server).

Other notes:
* User agents MAY use the Public Suffix List to offer/share (with user mediation) Credentials from the TLD to an eTLD+1 for example. Leaves it up to the user agent within a security framework.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/49#issuecomment-224683633