Labs/Identity/VerifiedEmailProtocol: Difference between revisions

Jump to navigation Jump to search

Labs/Identity/VerifiedEmailProtocol (view source)

Revision as of 17:01, 25 March 2011

215 bytes added ,  25 March 2011
Wikification
(First draft; needs more wikifying)
 
(Wikification)
Line 1: Line 1:
'''Identity in the Browser'''
'''Verified Email Protocol: Overview and Introduction'''


1. The really short version:<br>This proposal defines a way for a user to prove to a website that they control an email address. It does not require that email providers support the system, but provides a better experience and more control if they do. Since most user logins have an email-based password reset option, this system is effectively a universal login system for most of the web; websites that have stronger login requirements are free to use them, and have a more secure way to federate their logins to other sites.
''WikiMedia tip: If you aren't seeing numbered section headings in the body of this document, you need to login and click the "My preferences" link, at left, and select "Auto-number headings"''
 
<br> __TOC__
 
= The really short version =
 
This proposal defines a way for a user to prove to a website that they control an email address. It does not require that email providers support the system, but provides a better experience and more control if they do. Since most user logins have an email-based password reset option, this system is effectively a universal login system for most of the web; websites that have stronger login requirements are free to use them, and have a more secure way to federate their logins to other sites.


The goal of this proposal is to provide a very simple web-centric binding to a well-understood identity token.
The goal of this proposal is to provide a very simple web-centric binding to a well-understood identity token.


2. Introduction:<br>A number of web-scale identity proposals start by creating a new identity token - for example a user ID or personal URL - and go on to describe how to use that token to authenticate the user. What we've learned from several years of experience with OpenID (and related protocols) is that this isn't quite good enough: establishing an identity token, in isolation from the rest of the web, doesn't actually help a site developer engage with their users.
= Introduction=
 
A number of web-scale identity proposals start by creating a new identity token - for example a user ID or personal URL - and go on to describe how to use that token to authenticate the user. What we've learned from several years of experience with OpenID (and related protocols) is that this isn't quite good enough: establishing an identity token, in isolation from the rest of the web, doesn't actually help a site developer engage with their users.


This proposal instead focuses on an identity that is universally understood and useful for users and service operators: the email address. Email is already a fully-distributed system, with millions of participating hosts and billions of identities. It is deeply interdependent with the Domain Name System, which provides a globally-distributed name lookup system. It is understood that a single human may have more than one address, and that an address may represent shared authority between several persons. Email already supports pseudonymous identity, through anonymous remailers. And, most importantly, users understand what an email address represents.
This proposal instead focuses on an identity that is universally understood and useful for users and service operators: the email address. Email is already a fully-distributed system, with millions of participating hosts and billions of identities. It is deeply interdependent with the Domain Name System, which provides a globally-distributed name lookup system. It is understood that a single human may have more than one address, and that an address may represent shared authority between several persons. Email already supports pseudonymous identity, through anonymous remailers. And, most importantly, users understand what an email address represents.
Line 19: Line 27:
It is understood that a system like this cannot expect anything close to universal deployment overnight, or ever. This system therefore makes use of another special property of the email address -- the fact that it can be independently verified by a third party -- to propose a system of "secondary identity authorities". These are servers, operated by trusted entities, that authenticate an email address on behalf of a server that does not participate in the protocol described here. A relying party can choose which, if any, secondary authorities they trust. These secondary authorities can help bootstrap the system by providing verified email addresses to relying parties, even if the mail host isn't able to support the system.
It is understood that a system like this cannot expect anything close to universal deployment overnight, or ever. This system therefore makes use of another special property of the email address -- the fact that it can be independently verified by a third party -- to propose a system of "secondary identity authorities". These are servers, operated by trusted entities, that authenticate an email address on behalf of a server that does not participate in the protocol described here. A relying party can choose which, if any, secondary authorities they trust. These secondary authorities can help bootstrap the system by providing verified email addresses to relying parties, even if the mail host isn't able to support the system.


3. Scope of the system
= Scope of the system =


The system proposed here allows a user agent (that is, a web browser) to:
The system proposed here allows a user agent (that is, a web browser) to:
Line 39: Line 47:
*Verify the identity assertion locally, without leaking information about the user to third parties, or, optionally, use a trusted verification service.
*Verify the identity assertion locally, without leaking information about the user to third parties, or, optionally, use a trusted verification service.


<br>4. Operation of the system
= Operation of the system =


The basic message flow that makes this system work is independent of the exact cryptographic protocols and message formats that encode the messages. For purposes of clarity, however, it is described it using a specific set of protocols. The reader is asked to understand that those choices are for illustrative purposes, and that multiple encodings of the trust relationships described herein are possible.
The basic message flow that makes this system work is independent of the exact cryptographic protocols and message formats that encode the messages. For purposes of clarity, however, it is described it using a specific set of protocols. The reader is asked to understand that those choices are for illustrative purposes, and that multiple encodings of the trust relationships described herein are possible.
Line 61: Line 69:
(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…)


<br>4.1: 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.
Line 73: Line 81:
Note that optional arguments to saveVerifiedAddress could include:
Note that optional arguments to saveVerifiedAddress could include:


* expire-timestamp: a timestamp beyond which the private key is no longer valid<br>* 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)<br>* 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<br>* require-encryption: an indication that the user agent should only persist the private key in a browser-level encrypted format<br>* refresh-url: a URL that the browser can visit to re-establish a verified address, if the current key has expired<br>* refresh-method: a snippet of JavaScript that can be executed to re-establish a verified address, if the current key has expired
* 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)
* 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
* 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


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.


4.2: Relying Parties
== Relying Parties ==


The user then navigates to a website that wants to use his or her identity.
The user then navigates to a website that wants to use his or her identity.
Line 103: Line 116:
1. Retrieves the email address from the assertion
1. Retrieves the email address from the assertion


2. Performs webfinger discovery on alice@mailhost.com. This leads to an XRDS document that contains one or more public-key LINK elements.
2. Performs discovery on alice@mailhost.com. For example, it perfroms webfinger discovery on the address, which leads to an XRDS document that contains one or more public-key LINK elements.


2.1. 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.
2.1. 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.
Line 119: Line 132:
The user agent can easily record the fact that the user consented to a getVerifiedEmail() call during the initial login step, and save that into secure private local storage. It can then (with the user's consent) automatically provide the identity assertion when the user returns to the site - or, if that identity has expired, smoothly guide the user through the authentication refresh step. It can also store a list of all identities that have been provided to the site and provide a "fast user switch" feature between them (though some additional work on session termination is required [[ hyperlink ]])
The user agent can easily record the fact that the user consented to a getVerifiedEmail() call during the initial login step, and save that into secure private local storage. It can then (with the user's consent) automatically provide the identity assertion when the user returns to the site - or, if that identity has expired, smoothly guide the user through the authentication refresh step. It can also store a list of all identities that have been provided to the site and provide a "fast user switch" feature between them (though some additional work on session termination is required [[ hyperlink ]])


4.3: Secondary Authorities
== Secondary Authorities ==


As noted above, it is unrealistic to expect every mail host on the internet to adopt this protocol. A secondary authority is a trusted intermediary who verifies an email address on behalf of a relying party. Secondary authorities could be operated by entities that make strong guarantees about user privacy and authentication accuracy, and are perceived by users and developers to be both technically competent and commercially disinterested.
As noted above, it is unrealistic to expect every mail host on the internet to adopt this protocol. A secondary authority is a trusted intermediary who verifies an email address on behalf of a relying party. Secondary authorities could be operated by entities that make strong guarantees about user privacy and authentication accuracy, and are perceived by users and developers to be both technically competent and commercially disinterested.
Line 140: Line 153:
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.


4.4: Verification Services
== Verification Services ==


It is hoped that this scheme could be adopted by sites of all sizes, but experience shows that small sites might have a hard time executing all of the cryptographic steps to perform verification.
It is hoped that this scheme could be adopted by sites of all sizes, but experience shows that small sites might have a hard time executing all of the cryptographic steps to perform verification.
Line 181: Line 194:
A certificate can also be created by a secondary issuer; just as in the non-certificate case, the relying party will decide whether they trust the issuer. The presence of an "issuer" attribute would indicate that the certificate was issued by an entity other than the primary authority. The issuer key can be discovered through the same HTTPS lookup described above or distributed out-of-band.
A certificate can also be created by a secondary issuer; just as in the non-certificate case, the relying party will decide whether they trust the issuer. The presence of an "issuer" attribute would indicate that the certificate was issued by an entity other than the primary authority. The issuer key can be discovered through the same HTTPS lookup described above or distributed out-of-band.


<br>5. User Experience Discussion
= 5. User Experience Discussion =


5.1. XX darn it, I can't remember what I wanted to put here


5.2. User experience before an identity is registered
== User experience before an identity is registered ==


If the user agent does not have any verified addresses stored already, the getVerifiedEmail call is an opportunity to bootstrap the user into the system. User agents should be free to adopt whatever flow they think is most effective for this.
If the user agent does not have any verified addresses stored already, the getVerifiedEmail call is an opportunity to bootstrap the user into the system. User agents should be free to adopt whatever flow they think is most effective for this.


5.3. Multiple devices and synchronization
== Multiple devices and synchronization ==


Most users have more than one internet-enabled device. This scheme does not require that the same private keys on each device; neither does it disallow it. A user could independently log in to each device, creating a new private key (and registering a new public key with the server) on each, or they could use a synchronization service to securely transfer the private keys from the origin device to another device.
Most users have more than one internet-enabled device. This scheme does not require that the same private keys on each device; neither does it disallow it. A user could independently log in to each device, creating a new private key (and registering a new public key with the server) on each, or they could use a synchronization service to securely transfer the private keys from the origin device to another device.


5.4. Informed Consent during Identity Disclosure
== Informed Consent during Identity Disclosure ==


The user agent is in a unique position to assist the user during the getVerifiedEmail flow. During this call, the user agent could present information relating to the privacy policy and terms of service of the relying site. The site could, for example, present a machine-readable or simplified version of their privacy policy to the user agent in the page.
The user agent is in a unique position to assist the user during the getVerifiedEmail flow. During this call, the user agent could present information relating to the privacy policy and terms of service of the relying site. The site could, for example, present a machine-readable or simplified version of their privacy policy to the user agent in the page.


5.5. Creation of pseudonymous addresses
== Creation of pseudonymous addresses ==


The user agent could, if a primary or secondary authority supported it, maintain a map of pseudonymous forwarding addresses on a per-site basis. New identities could be requested from the authority when a previously-unknown domain was encountered. This map would need to be synchronized across a user's devices or accessed in realtime from the server.  
The user agent could, if a primary or secondary authority supported it, maintain a map of pseudonymous forwarding addresses on a per-site basis. New identities could be requested from the authority when a previously-unknown domain was encountered. This map would need to be synchronized across a user's devices or accessed in realtime from the server.  


5.6. Potential for registration abuse
== Potential for registration abuse ==


XX sites could call saveVerifiedAddress aggressively to get their (potentially bogus) identities into the browser's list; potential for "identity hijack?"
XX sites could call saveVerifiedAddress aggressively to get their (potentially bogus) identities into the browser's list; potential for "identity hijack?"


5.7 Automatic key refresh
== Automatic key refresh ==


XX want the browser to be able to re-submit credentials, but also want the ability to have strong (e.g. two-factor) authentication flows
XX want the browser to be able to re-submit credentials, but also want the ability to have strong (e.g. two-factor) authentication flows


6. Security Discussion
= Security Discussion =


6.1. Registration of addresses across domains:<br>In the scheme as proposed here, any domain can make a claim to verify any address. This is an attempt to preserve flexibility for operators who have complicated domain name schemes (for example, a "login.site.com" server that handles logins for "sitemail.com"). Attempts to counterfeit the system would be defeated at the assertion verification step, where an attempt to retrieve the public key of the user (e.g. at sitemail.com) would fail.
== Registration of addresses across domains: ==
 
In the scheme as proposed here, any domain can make a claim to verify any address. This is an attempt to preserve flexibility for operators who have complicated domain name schemes (for example, a "login.site.com" server that handles logins for "sitemail.com"). Attempts to counterfeit the system would be defeated at the assertion verification step, where an attempt to retrieve the public key of the user (e.g. at sitemail.com) would fail.


Only secondary authorities are allowed to provide a public key outside of the normal public key lookup flow, and relying parties are required to explicitly trust secondary authorities.
Only secondary authorities are allowed to provide a public key outside of the normal public key lookup flow, and relying parties are required to explicitly trust secondary authorities.
Line 217: Line 231:
In the primary authority certificate-based flow, the authority is required to serve the public key for the email domain from the email domain itself. The verification of the certificate with this key proves that the certificate-issuing host had the public key for the email domain, which proves the delegation relationship.
In the primary authority certificate-based flow, the authority is required to serve the public key for the email domain from the email domain itself. The verification of the certificate with this key proves that the certificate-issuing host had the public key for the email domain, which proves the delegation relationship.


6.2. Synchronization of keys
== Synchronization of keys ==


This protocol does not require the user's private key to be synchronized across user agents or devices; it is expected that authorities will present more than one public key when queried. It does not forbid synchronization, however, and the system should work fine in that case. User agents should be prepared to deal with expired keys at any time.
This protocol does not require the user's private key to be synchronized across user agents or devices; it is expected that authorities will present more than one public key when queried. It does not forbid synchronization, however, and the system should work fine in that case. User agents should be prepared to deal with expired keys at any time.


6.3. Use of Key Identifiers
== Use of Key Identifiers ==


Retrieving all of the user's public keys is workable but involves extra work for the RP client and the authority server. The addition of a simple key identifier to the public key registration, identity assertion, and identity certificate would allow the RP to request just the public key they want. In X.509 parlance, this could be a Subject Key Identifier - though other schemes could be used.
Retrieving all of the user's public keys is workable but involves extra work for the RP client and the authority server. The addition of a simple key identifier to the public key registration, identity assertion, and identity certificate would allow the RP to request just the public key they want. In X.509 parlance, this could be a Subject Key Identifier - though other schemes could be used.


6.4. Identity Authority authentication context records <br>The identity authority could advertise additional authentication metadata along with the user's public key. This metadata would be intended to allow a relying party to have greater confidence in the use of the authentication and could include the client IP address, the mode of authentication, the timestamp of the authentication or expected expiry, and so forth. In some cases, this metadata would represent sensitive data and the relying service would be expected to authenticate itself to the authority.  
== Identity Authority authentication context records ==
 
The identity authority could advertise additional authentication metadata along with the user's public key. This metadata would be intended to allow a relying party to have greater confidence in the use of the authentication and could include the client IP address, the mode of authentication, the timestamp of the authentication or expected expiry, and so forth. In some cases, this metadata would represent sensitive data and the relying service would be expected to authenticate itself to the authority.  


It would make sense to either include this data as part of the certificate, or as additional data included with the public key lookup.
It would make sense to either include this data as part of the certificate, or as additional data included with the public key lookup.
Line 231: Line 247:
This metadata would probably be substantially identical to the SAML Authentication Context; see more at http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
This metadata would probably be substantially identical to the SAML Authentication Context; see more at http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf


6.5. Enumerability of identities<br>A naive identity server implementation would allow an attacker to trivially enumerate all identities on the server by brute-force queries. This problem exists for all personal identity delivery protocols (see, for example, the SMTP VRFY command), but can mitigated by ensuring that the authority server presents a valid page for every public key lookup request (containing, perhaps, a random but stable public key).<br> <br>7. Links
== Enumerability of identities ==


8. Acknowledgements
A naive identity server implementation would allow an attacker to trivially enumerate all identities on the server by brute-force queries. This problem exists for all personal identity delivery protocols (see, for example, the SMTP VRFY command), but can mitigated by ensuring that the authority server presents a valid page for every public key lookup request (containing, perhaps, a random but stable public key).<br> <br>


Many thanks to Dick Hardt for a clear summary of the actual goals of RPs and inspiration on the architecture, and to the organizers and members of the Identity Commons 2011 event for constructive commentary and feedback.
= Links =


= Acknowledgements =


 
Many thanks to Dick Hardt for a clear summary of the actual goals of RPs and inspiration on the architecture, and to the organizers and members of the Identity Commons 2011 event for constructive commentary and feedback.
'''OPEN ISSUES:'''
 
Key expiration: No mechanism is specified to allow the authority (whether primary or secondary) to tell the client that a key has expired/been revoked - right now, I just have an expiry argument to the register call. There needs to be some way for the client to be told; this may be a ping from the client to the authority.
 
RP errors: There is no way for the RP to tell the UA that an address was rejected (so no way to tell the UA why it was rejected). This puts the UA in a bad position of submitting data which might work or might not, but with no way to recover if it doesn't work. Might need some markup or something to help with that.






= OPEN ISSUES: =


== Key expiration: ==
No mechanism is specified to allow the authority (whether primary or secondary) to tell the client that a key has expired/been revoked - right now, I just have an expiry argument to the register call. There needs to be some way for the client to be told; this may be a ping from the client to the authority.


<br><br>
== RP errors: ==
There is no way for the RP to tell the UA that an address was rejected (so no way to tell the UA why it was rejected). This puts the UA in a bad position of submitting data which might work or might not, but with no way to recover if it doesn't work. Might need some markup or something to help with that.
Mhanson
348

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/293977"

Navigation menu