Confirmed users
170
edits
Labs/Identity/VerifiedEmailProtocol: Difference between revisions
Deprecate; point to BrowserID
(Deprecate; point to BrowserID) |
|||
| (15 intermediate revisions by 5 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" | |||
|- | |||
| '''Note: this document has been merged with others, see [[Identity/Verified_Email_Protocol/Latest]] for the latest version.''' | |||
|}<br> | |||
'''Verified Email Protocol: Overview and Introduction''' | '''Verified Email Protocol: Overview and Introduction''' | ||
| Line 23: | Line 32: | ||
It is understood that "alice@site.com" means that there is a person, here called "alice", who has agreed to trust "site.com" to test her identity and to act as a secure relay for messages. The fact that we use this identifier only for SMTP mail delivery is an accident of history; there is no reason we can't bootstrap from this identifier to other protocols (as recent proposal like Webfinger have made clear). | It is understood that "alice@site.com" means that there is a person, here called "alice", who has agreed to trust "site.com" to test her identity and to act as a secure relay for messages. The fact that we use this identifier only for SMTP mail delivery is an accident of history; there is no reason we can't bootstrap from this identifier to other protocols (as recent proposal like Webfinger have made clear). | ||
Many systems that are based on username/password authentication have an email password reset mechanism. This fact means that, for those users, the username/password pair is effectively a shorthand reference for "control of this email address". This proposal asserts that, for those use cases, proof of control of the email address is a better authentication mechanism than a username/password; | Many systems that are based on username/password authentication have an email password reset mechanism. This fact means that, for those users, the username/password pair is effectively a shorthand reference for "control of this email address". This proposal asserts that, for those use cases, proof of control of the email address is a better authentication mechanism than a username/password; if the site then chooses to provide a pseudonymous "user name" for their site, they are free to do so, but the verified email address is paramount. | ||
This system is completely neutral on the question of how an email host authenticates a user to prove control of the identity. If the host wants to use hardware, biometric, or social keys for their authentication scheme, they are completely free to do so. What this proposal describes is a way for this host to tell other hosts what identity the user has, and even to explain to them how that identity was established. | This system is completely neutral on the question of how an email host authenticates a user to prove control of the identity. If the host wants to use hardware, biometric, or social keys for their authentication scheme, they are completely free to do so. What this proposal describes is a way for this host to tell other hosts what identity the user has, and even to explain to them how that identity was established. | ||
| Line 78: | Line 87: | ||
(Read on for more detail, including a certification scheme that avoids the webfinger lookup, discussion of how to handle Alice's multiple browsers, expiration of the private key, secondary verifiers, and more…) | (Read on for more detail, including a certification scheme that avoids the webfinger lookup, discussion of how to handle Alice's multiple browsers, expiration of the private key, secondary verifiers, and more…) | ||
== Primary Authorities == | == Primary Authorities == | ||
The authentication flow starts with a primary identity authority talking to a user agent -- that is, a user logging in to their email account. The user does what he or she needs to do to log in - perhaps a username/password, perhaps more. | The authentication flow starts with a primary identity authority talking to a user agent -- that is, a user logging in to their email account. The user does what he or she needs to do to log in - perhaps a username/password, perhaps more. | ||
The authority then executes a method in a web page served from its domain: | The authority then executes a method in a web page served from its domain: | ||
<pre>navigator.id.saveVerifiedAddress( "alice@mailhost.com", <callback>)</pre> | <pre style="overflow:scroll;">navigator.id.saveVerifiedAddress( "alice@mailhost.com", <callback>, [{optionalKey: value, ... }]) | ||
The browser will then: | </pre> | ||
<blockquote><font color=green>If you're passing multiple items, you should instead use something like </font> | |||
<pre style="overflow:scroll;"> navigator.id.saveInfo({"email":"alice@mailhost.com", "expire-timestamp":..., ...}, <callback>)</pre> | |||
<font color=green>which would provide the most flexibility for future changes.</font></blockquote> | |||
The browser will then: | |||
# Create an asymmetric cryptography keypair (for example, an RSA or ECDSA keypair) | #Create an asymmetric cryptography keypair (for example, an RSA or ECDSA keypair) | ||
# Store "alice@mailhost.com", along with the private key, in secure, private, local storage | #Store "alice@mailhost.com", along with the private key, in secure, private, local storage | ||
# Return the public key to the web page through the callback | #Return the public key to the web page through the callback | ||
<blockquote><font color=green>Primary Auth is determined by webfinger lookup on the provided email address to ensure that the domain is allowed. An info block that fails this check is not stored, the user is notified of the attempt, and the code returns false.</font></blockquote> | |||
The page will then upload the public key to the server, who will store it in a database, keyed on the user's address, for later retrieval (see section 6.4 for a discussion of what else the server could provide with it). | The page will then upload the public key to the server, who will store it in a database, keyed on the user's address, for later retrieval (see section 6.4 for a discussion of what else the server could provide with it). | ||
Note that optional arguments to <code>saveVerifiedAddress</code> could include: | Note that optional arguments to <code>saveVerifiedAddress</code> could include: | ||
* expire-timestamp: a timestamp beyond which the private key is no longer valid | *expire-timestamp: a timestamp beyond which the private key is no longer valid | ||
* expire-session: an indication that the private key should be destroyed when the current browser session ends (and, probably, that the key should only be held in memory rather than ever put to disk) | *expire-session: an indication that the private key should be destroyed when the current browser session ends (and, probably, that the key should only be held in memory rather than ever put to disk) | ||
* require-challenge: an indication that the user agent should require the user to provide a "master password" or similar browser-level authentication before using the private key | *require-challenge: an indication that the user agent should require the user to provide a "master password" or similar browser-level authentication before using the private key | ||
* require-encryption: an indication that the user agent should only persist the private key in a browser-level encrypted format | *require-encryption: an indication that the user agent should only persist the private key in a browser-level encrypted format | ||
* refresh-url: a URL that the browser can visit to re-establish a verified address, if the current key has expired | *refresh-url: a URL that the browser can visit to re-establish a verified address, if the current key has expired | ||
* refresh-method: a snippet of JavaScript that can be executed to re-establish a verified address, if the current key has expired | *refresh-method: a snippet of JavaScript that can be executed to re-establish a verified address, if the current key has expired | ||
<blockquote><font color=green>See above note regarding suggestion on how this data should be passed</font></blockquote> | |||
With a little bit more work, one could specify an argument that would allow the user agent to load a page containing a login form (including anti-CSRF parameters), fill it out, and submit it, on the user's behalf. | With a little bit more work, one could specify an argument that would allow the user agent to load a page containing a login form (including anti-CSRF parameters), fill it out, and submit it, on the user's behalf. | ||
| Line 114: | Line 129: | ||
<pre>navigator.id.getVerifiedEmail();</pre> | <pre>navigator.id.getVerifiedEmail();</pre> | ||
… which informs the browser that it should start the "sign in" user interface flow immediately. This function could be called from, for example, a "Sign In" button in the web page. | … which informs the browser that it should start the "sign in" user interface flow immediately. This function could be called from, for example, a "Sign In" button in the web page. | ||
<blockquote><font color=green>Sadly, I can see most sites opting for the latter, possibly as part of the pages onLoad so that they can get "High User Engagement!"®. We should probably not directly expose the getVerifiedEmail() call in favor of a less blocking method.</font></blockquote> | |||
When getVerifiedEmail is triggered, the browser: | When getVerifiedEmail is triggered, the browser: | ||
| Line 119: | Line 135: | ||
# Presents to the user a list of the addresses that have been previously stored in the browser (note that this is a good place for browser to enhance informed consent for personal data disclosure - see the User Experience section below). | # Presents to the user a list of the addresses that have been previously stored in the browser (note that this is a good place for browser to enhance informed consent for personal data disclosure - see the User Experience section below). | ||
# When the user selects one of these addresses, retrieves the private key associated with that address | # When the user selects one of these addresses, retrieves the private key associated with that address | ||
# If the key has expired, initiates key refresh - potentially a large topic, more needs to be written on that (see also Open Issues - perhaps the UA needs to check that the key is still valid here) | # If the key has expired, initiates key refresh - potentially a large topic, more needs to be written on that (see also Open Issues - perhaps the UA needs to check that the key is still valid here) <font color=green>Please include a list of those issues for the design. I would not like to have missed any.</font> | ||
# Once a key is found, the browser creates an assertion containing the email address, an audience, and a valid-until timestamp, and signs it with the private key. This is the '''identity assertion'''. | # Once a key is found, the browser creates an assertion containing the email address, an audience, and a valid-until timestamp, and signs it with the private key. This is the '''identity assertion'''. | ||
# The assertion is delivered to the onVerifiedEmail callback, which uploads it to the relying site. | # The assertion is delivered to the onVerifiedEmail callback, which <font color=green>(optional? required?)</font> uploads it to the relying site <font color=green>(for validation? storage? giggles?)</font>. | ||
In our example, this would mean that this assertion is provided (and signed with Alice's "alice@mailhost.com" private key) | In our example, this would mean that this assertion is provided (and signed with Alice's "alice@mailhost.com" private key) | ||
| Line 132: | Line 148: | ||
# Retrieves the email address from the assertion | # Retrieves the email address from the assertion | ||
# Performs discovery on alice@mailhost.com. For example, it | # Performs discovery on alice@mailhost.com. For example, it performs webfinger discovery on the address, which leads to an XRDS document that contains one or more public-key LINK elements. | ||
## There is probably more than one key here because Alice has more than one device, and may have reset her browser at some point without letting the server know. See 6.3 below for how a key identifier can be attached to the assertion to pick the right public key; otherwise the relying site needs to try all of them. | ## There is probably more than one key here because Alice has more than one device, and may have reset her browser at some point without letting the server know. See 6.3 below for how a key identifier can be attached to the assertion to pick the right public key; otherwise the relying site needs to try all of them. | ||
## See 6.4 for a discussion of how the authority could provide more detail about the user's credentials to the relying party, e.g. what kind of authentication was performed. | ## See 6.4 for a discussion of how the authority could provide more detail about the user's credentials to the relying party, e.g. what kind of authentication was performed. | ||
| Line 166: | Line 182: | ||
}</pre> | }</pre> | ||
The presence of the issuer field tells the relying party that this is not a primary identity assertion. The relying party should decide whether they trust the issuer listed there; if they do, then they perform discovery on the provided email against the issuer's domain. The secondary authority relationship is probably pre-arranged; it is unrealistic to think that a relying party would trust an authority they had never heard of before. Although the lookup protocol could be issuer-specific, it would be simpler and more portable to just use the same lookup method that is used for the primary authority, (e.g.) webfinger. | The presence of the issuer field tells the relying party that this is not a primary identity assertion. The relying party should decide whether they trust the issuer listed there; if they do, then they perform discovery on the provided email against the issuer's domain. The secondary authority relationship is probably pre-arranged; it is unrealistic to think that a relying party would trust an authority they had never heard of before. Although the lookup protocol could be issuer-specific, it would be simpler and more portable to just use the same lookup method that is used for the primary authority, (e.g.) webfinger. | ||
<blockquote><font color=green>lookup method(s) should be part of the assertion (just like encryption). People always assume incorrectly.</font></blockquote> | |||
When they retrieve a public key, the relying party performs assertion verification as normal. | When they retrieve a public key, the relying party performs assertion verification as normal. | ||
| Line 176: | Line 194: | ||
The verification step would be quite straightforward: the relying party would simply POST an assertion to a verifier over SSL along with their expected audience string, the verifier would verify the assertion as in 4.2, and return a result code. The audience test is necessary, as it prevents replay attacks using assertions captured at other sites. | The verification step would be quite straightforward: the relying party would simply POST an assertion to a verifier over SSL along with their expected audience string, the verifier would verify the assertion as in 4.2, and return a result code. The audience test is necessary, as it prevents replay attacks using assertions captured at other sites. | ||
<blockquote><font color=green>This requires that the server enforce that audience matches the reverse DNS of the requesting site?</font></blockquote> | |||
== Certification == | == Certification == | ||
| Line 203: | Line 223: | ||
The relying party, when it sees that a certificate is present, may choose to skip the retrieval of the user's public key by instead verifying the certificate. That flow would be: | The relying party, when it sees that a certificate is present, may choose to skip the retrieval of the user's public key by instead verifying the certificate. That flow would be: | ||
# Resolve a site-level public key for the issuer by performing host discovery on the email in the certificate (for example, by performing an RFC 5785 "well-known" lookup on an HTTPS server, or talking to a trusted directory server) | # Resolve a site-level public key for the issuer by performing host discovery on the email in the certificate (for example, by performing an RFC 5785 "well-known" lookup on an HTTPS server, or talking to a trusted directory server) <font color=green>Does this mean that there are more than one method used to do resource lookups? (WebFinger & "well-known"?) Isn't that potentially confusing to users and developers?)</font> | ||
# Verify the signature on the certificate using the public key | # Verify the signature on the certificate using the public key | ||
| Line 211: | Line 231: | ||
Unfortunately, adding revokation complicates this flow and reduces the privacy-enhancing properties of it. Just as with site-identifying certificates, the RP is required to either retrieve a revocation list or use an online status check (that is, a CRL or OCSP) to make sure an identity certificate is still valid. These steps have proven to be problematic for the site-identifying CAs that power the SSL site-identification infrastructure, and there is little reason to think that email hosts would be any more capable of handling them at larger scale. It may be realistic to think that the internet could support identity certificate revokation at scale; perhaps we should focus our attention instead on limiting the scope of breaches, for example by encouraging short-lived identity certificates and automated certificate refresh. | Unfortunately, adding revokation complicates this flow and reduces the privacy-enhancing properties of it. Just as with site-identifying certificates, the RP is required to either retrieve a revocation list or use an online status check (that is, a CRL or OCSP) to make sure an identity certificate is still valid. These steps have proven to be problematic for the site-identifying CAs that power the SSL site-identification infrastructure, and there is little reason to think that email hosts would be any more capable of handling them at larger scale. It may be realistic to think that the internet could support identity certificate revokation at scale; perhaps we should focus our attention instead on limiting the scope of breaches, for example by encouraging short-lived identity certificates and automated certificate refresh. | ||
<blockquote><font color=green>How best should this be addressed in the short term for the system we are creating? Should certificates have a mandatory expiration period of <5 minutes?</font></blockquote> | |||
= 5. User Experience Discussion = | = 5. User Experience Discussion = | ||