Identity/Verified Email Protocol: Difference between revisions
< Identity
Jump to navigation
Jump to search
(Deprecate VEP; link to BrowserID) |
|||
| (7 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 8: | Line 12: | ||
<section begin="status" /> | <section begin="status" /> | ||
| [[Identity/Verified Email Protocol|Verified Email Protocol]] | | [[Identity/Verified Email Protocol|Verified Email Protocol]] | ||
| {{StatusHealthy|status= | | {{StatusHealthy|status=First draft done. Refining/polishing.}} | ||
| | | TBD | ||
| Dan Mills | | Dan Mills | ||
<section end="status" /> | <section end="status" /> | ||
| Line 28: | Line 32: | ||
== Next Steps == | == 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 | * Security review | ||
* Privacy review | * Privacy review | ||
| Line 40: | Line 41: | ||
;Current | ;Current | ||
* [[/Latest|Latest]] | * [[/Latest|Latest (Verified Email)]] | ||
* [[/Latest-Session|Latest (Session)]] | |||
;Archived | ;Archived | ||
| Line 48: | 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 == | ||
| Line 58: | Line 69: | ||
[[File:Verified_Email_Primary_Authority_Flow.jpg|200px|thumb|left|'''Protocol flow'''<br>Primary Authority + Relying Party verification using crypto]] | [[File:Verified_Email_Primary_Authority_Flow.jpg|200px|thumb|left|'''Protocol flow'''<br>Primary Authority + Relying Party verification using crypto]] | ||
[[File:Verified_Email_Secondary_Authority_Flow.jpg|200px|thumb|left|'''Protocol flow'''<br>Secondary Authority + Relying Party verification using crypto]] | |||
<br clear="all"/> | <br clear="all"/> | ||
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. |