Identity/Verified Email Protocol: Difference between revisions

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

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.

@@ 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"
 |-
@@ Line 8: / Line 12: @@
 <section begin="status" />
 | [[Identity/Verified Email Protocol|Verified Email Protocol]]
-| {{StatusHealthy|status=Draft 1}}
+| {{StatusHealthy|status=First draft done. Refining/polishing.}}
 | TBD
 | Dan Mills
@@ Line 28: / Line 32: @@
 == Next Steps ==
-* Flesh out this doc :)
+* Deal with TODOs in Verified Email doc
-* Integrate Services & Labs versions of Verified Email Protocol
+** cert refresh - decide on long-lived (reusable) keys or not
-* Use certification flow (exclusively)
+* Polish/expand session API specification doc
-* Add session API
 * Security review
 * Privacy review
@@ Line 38: / Line 41: @@
 ;Current
-* [[Identity/Verified Email Protocol/Draft 1|Draft 1]]
+* [[/Latest|Latest (Verified Email)]]
+* [[/Latest-Session|Latest (Session)]]
-;Obsolete
+;Archived
 * [[Labs/Identity/VerifiedEmailProtocol|Labs v0]]
 * [[MozillaID/Spec|Services v0]]
@@ Line 46: / Line 50: @@
 == 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 ==
@@ Line 54: / Line 67: @@
 == Other Documentation ==
+[[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"/>
 == Legend (remove if you like) ==