Confirmed users
170
edits
Identity/Verified Email Protocol: Difference between revisions
Deprecate VEP; link to BrowserID
(Deprecate VEP; link to BrowserID) |
|||
| (4 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 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 44: | 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 == | ||