Identity/Verified Email Protocol

From MozillaWiki
Jump to: navigation, search
Note: The Verified Email Protocol has been deprecated. Please check the BrowserID protocol.
Feature Status ETA Owner
Verified Email Protocol First draft done. Refining/polishing. TBD Dan Mills



Who's working on this?

  • Feature Manager: Dan Mills
  • Lead Author: Michael Hanson
  • Product Manager: Dan Mills
  • Security: Michael Coates
  • Privacy: Sid Stamm

Next Steps

  • Deal with TODOs in Verified Email doc
    • cert refresh - decide on long-lived (reusable) keys or not
  • Polish/expand session API specification doc
  • Security review
  • Privacy review

Protocol Links


Open Issues

How is this different from SSL Client Authentication?

  1. Trusted 3rd party signs a certificate that you store in your browser
  2. The browser has a "Selector" to let you choose the cert based on acceptable signed 3rd parties
  3. The cert can be expired or revoked
  4. You have the same issues with crl checking, if my "key" is comprimised and i have my provider revoke it before it expires the RP still needs to validate it against a revocation list at some point

A certificate can store all the information a JSON token can (shoot, it could store a JSON token if thats the way you wanted to go). Certificate based authentication is already working and would provide a much greater range for not just consumer sites but enterprise apps as well.

Use Cases



Other Documentation

Protocol flow
Primary Authority + Relying Party verification using crypto
Protocol flow
Secondary Authority + Relying Party verification using crypto

Legend (remove if you like)

  Healthy: feature is progressing as expected.
  Blocked: feature is currently blocked.
  At Risk: feature is at risk of missing its targeted release.
ETA Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.