Identity/Verified Email Protocol: Difference between revisions
< Identity
(Deprecate VEP; link to BrowserID) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{| class="fullwidth-table" | |||
|- | |||
| '''Note: The Verified Email Protocol has been deprecated. Please check the [[Identity/BrowserID|BrowserID]] protocol.''' | |||
|} | |||
{| class="fullwidth-table" | {| class="fullwidth-table" | ||
|- | |- | ||
| Line 29: | Line 33: | ||
== Next Steps == | == Next Steps == | ||
* Deal with TODOs in Verified Email doc | * Deal with TODOs in Verified Email doc | ||
** cert refresh - decide on long-lived (reusable) keys or not | |||
* Polish/expand session API specification doc | * Polish/expand session API specification doc | ||
* Security review | * Security review | ||
| Line 45: | Line 50: | ||
== Open Issues == | == Open Issues == | ||
How is this different from SSL Client Authentication? | |||
#Trusted 3rd party signs a certificate that you store in your browser | |||
#The browser has a "Selector" to let you choose the cert based on acceptable signed 3rd parties | |||
#The cert can be expired or revoked | |||
#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 == | == Use Cases == | ||
Latest revision as of 19:13, 3 April 2012
| 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 |
Summary
Team
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
- Current
- Archived
Open Issues
How is this different from SSL Client Authentication?
- Trusted 3rd party signs a certificate that you store in your browser
- The browser has a "Selector" to let you choose the cert based on acceptable signed 3rd parties
- The cert can be expired or revoked
- 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
Goals
Non-Goals
Other Documentation
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. |