Merge branch 'master' of github.com:w3c/apa

JaninaSajka · JaninaSajka · commit 5f32c6e29c37 · 2019-10-23T10:42:57.000-04:00
diff --git a/index.html b/index.html
@@ -10,7 +10,8 @@
 	<body>
 		<section id="abstract">
 			<h2>Abstract</h2>
-			<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robots</a>. The traditional <a>CAPTCHA</a> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent noninteractive and tokenized approaches. We have grouped these approaches by two category classifications: <a href="#stand-alone-approaches">Stand-Alone Approaches</a> that can be deployed on a web host without engaging the services of unrelated third parties and <a href="#multi-party-approaches">Multi-Party Approaches</a> that engage the services of an unrelated third party.</p>
+			<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robots</a>. The traditional <a>CAPTCHA</a> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent
+				non-interactive and tokenized approaches. We have grouped these approaches by two category classifications: <a href="#stand-alone-approaches">Stand-Alone Approaches</a> that can be deployed on a web host without engaging the services of unrelated third parties and <a href="#multi-party-approaches">Multi-Party Approaches</a> that engage the services of an unrelated third party.</p>
 		</section>
 		<section id="sotd"> </section>
 		<section>
@@ -30,8 +31,8 @@ <h3>The CAPTCHA Context</h3>
 
 <p>An early (and still widespread) solution relies on the use of graphical representations of text in registration or comment areas of a web site. The site attempts to verify that the user is in fact a human by requiring the user to complete a task referred to as a "Completely Automated Public <a>Turing Test</a>, to Tell Computers and Humans Apart," or <a>CAPTCHA</a>. The assumption is that humans find this task relatively easy, while robots find it nearly impossible to perform.</p>
 			<p>The CAPTCHA was <a href="http://captcha.net">initially developed by researchers at Carnegie Mellon University</a> and has been primarily associated with a technique whereby an individual identifies a distorted set of characters in a bit-mapped image, then enters those characters into a web form. This approach is widely familiar to users of the web, though the term CAPTCHA is generally recognized only by web professionals.</p>
-			<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully noninteractive approaches.</p>
-			<p>It will surprise no one that we applaud the recent emergence of noninteractive approaches because functional noninteractive approaches pose no accessibility challenge to users. Unfortunately,  some current noninteractive approaches come at the price of exposing much data about the individual user to the noninteractive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testing</a> requiring only minimal interaction with users.</p>
+			<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully non-interactive approaches.</p>
+			<p>It will surprise no one that we applaud the recent emergence of non-interactive approaches because functional non-interactive approaches pose no accessibility challenge to users. Unfortunately, some current non-interactive approaches come at the price of exposing much data about the individual user to the non-interactive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testing</a> requiring only minimal interaction with users.</p>
 		</section>
 			                <section>
 						                        <h3>The Accessibility Challenge</h3>
@@ -186,7 +187,7 @@ <h4>Spam Filtering</h4>
 				  <h4>Proof-Of-Work</h4>
 				  <p>One strategy for thwarting misuse of web resources is to load suspicious clients with significant computational workloads, thus 
 				  slowing down the interaction and hopefully deterring malicious parties by reducing their ability to engage in undesirable activities such as disseminating spam. This approach has been explored in the development of proof-of-work challenges. [[kaPoW-plugins]] These can be made arbitrarily expensive computationally based on an associated reputation score for each client that attempts to access a resource. Clients that are adjudged more likely to be malicious are required to solve more computationally expensive problems. Less resource-consumptive problems are provided to clients that are adjudged more likely to be web browsers operated by human users.</p>
-				  <p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots&mdash;perhaps even greater than the cost of hiring human workers as <a>CAPTCHA</a> solvers.</p>
+					<p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots—perhaps even greater than the cost of hiring human workers as <a>CAPTCHA</a> solvers.</p>
 				  <p>Implementing this approach is straightforward. It requires the client to execute JavaScript code to solve the computational problem, and the solution is then verified by a server to establish that the work has been performed. It  poses no direct accessibility problems, though it may slow performance for users of older hardware.</p>
 				</section>
 				<section>
@@ -245,22 +246,9 @@ <h4>Version 2: Are you a robot?</h4>
 request right now." Users who have depended on audio CAPTCHA alternatives, who have previously been able to function with reCAPTCHA v2, are thus suddenly and seemingly capriciously locked out and denied service on sites still using V2.</p>
 			</section>
 			<section id="recap3">
-			<h4>The Noninteractive Version 3</h4>
-
-<p>Late in 2018 Google released <a
-					href="https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html">
-	reCAPTCHA v3</a> promising to eliminate "the need to interrupt users
-with challenges at all." <a
-	href="https://lists.w3.org/Archives/Public/public-rqtf/2019Mar/0019.html">Google
-	also informed us</a> that their goals with v included increasing "the
-accessibility of the web by removing traditional CAPTCHAs" entirely.
-Obviously, fully noninteractive <a>Turing testing</a> is a most welcome development
-direction for accessibility. When the noninteractive <a>Turing test</a> returns a
-score indicating high confidence that the user is human, or indeed a score
-indicating high confidence that the user is a robot, and experience has
-demonstrated the noninteractive engine is reliable, we can only offer praise
-and gratitude for technological progress that more effectively supports persons
-with disabilities.  </p>
+			<h4>The Non-interactive Version 3</h4>
+
+<p>Late in 2018 Google released <a href="https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html"> reCAPTCHA v3</a> promising to eliminate "the need to interrupt users with challenges at all." <a href="https://lists.w3.org/Archives/Public/public-rqtf/2019Mar/0019.html">Google also informed us</a> that their goals with v included increasing "the accessibility of the web by removing traditional CAPTCHAs" entirely. Obviously, fully non-interactive <a>Turing testing</a> is a most welcome development direction for accessibility. When the non-interactive <a>Turing test</a> returns a score indicating high confidence that the user is human, or indeed a score indicating high confidence that the user is a robot, and experience has demonstrated the non-interactive engine is reliable, we can only offer praise and gratitude for technological progress that more effectively supports persons with disabilities. </p>
 
 <p>Of course no approach will always return unambiguous results. <a
 	href="https://developers.google.com/recaptcha/docs/v3">In such
@@ -270,8 +258,7 @@ <h4>The Noninteractive Version 3</h4>
 specific to their site to make a more informed judgment." Google intends
 that traditional CAPTCHA no longer be used as a  fallback mechanism and has dropped  it from v reCAPTCHA, though it remains in their slightly older, 2017 <a href="https://developers.google.com/recaptcha/docs/invisible">reCAPTCHA v2 Invisible</a> service.</p>
 
-<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testing</a>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ  declares that <a href="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going away</a>. It is therefore imperative that methods for disambiguating an ambiguous noninteractive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach.
-</p>
+<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testing</a>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ declares that <a href="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going away</a>. It is therefore imperative that methods for disambiguating an ambiguous non-interactive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach. </p>
 
 			</section>
         </section>
@@ -361,15 +348,9 @@ <h3>Turing Tokens from the Cloud?</h3>
 		<section id="fedtoken">
 			<h3>Why not Federated Turing Tokens?</h3>
 
-<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <a href="http://lastpass.com">Last Pass</a>,  offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices.
-Services like
-Amazon's <a href="https://aws.amazon.com/cognito">Cognito,</a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control.
-Others, like
- <a href="https://developers.facebook.com/products/account-creation">Facebook's
-Account Kit</a>, 
-seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform.
-It has been unclear to us at first blush which, if any, of these services prioritize  restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for noninteractively authenticating their humanity with third parties. The only exceptions of which we're aware are <a href="#recap3">reCAPTCHA v3</a and <a href="#privpass">Privacy Pass</a.</p>
-			<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPN</a> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee&mdash;such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?</p>
+<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <a href="http://lastpass.com">Last Pass</a>, offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices. Services like Amazon's <a href="https://aws.amazon.com/cognito">Cognito,</a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control. Others, like <a href="https://developers.facebook.com/products/account-creation">Facebook's Account Kit</a>, seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform. It has been unclear to us at first blush which, if any, of these services
+					prioritize restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for non-interactively authenticating their humanity with third parties. The only exceptions of which we're aware are <a href="#recap3">reCAPTCHA v3</a> and <a href="#privpass">Privacy Pass</a>.</p>
+			<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPN</a> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee—such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?</p>
 		</section>
 		</section>
 		<section>

-Original file line number
+Diff line change
 	<body>
 		<section id="abstract">
 			<h2>Abstracth2>
 -			<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robotsa>. The traditional <a>CAPTCHAa> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent noninteractive and tokenized approaches. We have grouped these approaches by two category classifications: <a href="#stand-alone-approaches">Stand-Alone Approachesa> that can be deployed on a web host without engaging the services of unrelated third parties and <a href="#multi-party-approaches">Multi-Party Approachesa> that engage the services of an unrelated third party.p>
 +			<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robotsa>. The traditional <a>CAPTCHAa> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent
 +				non-interactive and tokenized approaches. We have grouped these approaches by two category classifications: <a href="#stand-alone-approaches">Stand-Alone Approachesa> that can be deployed on a web host without engaging the services of unrelated third parties and <a href="#multi-party-approaches">Multi-Party Approachesa> that engage the services of an unrelated third party.p>
 		section>
 		<section id="sotd"> section>
 		<section>
 <p>An early (and still widespread) solution relies on the use of graphical representations of text in registration or comment areas of a web site. The site attempts to verify that the user is in fact a human by requiring the user to complete a task referred to as a "Completely Automated Public <a>Turing Testa>, to Tell Computers and Humans Apart," or <a>CAPTCHAa>. The assumption is that humans find this task relatively easy, while robots find it nearly impossible to perform.p>
 			<p>The CAPTCHA was <a href="http://captcha.net">initially developed by researchers at Carnegie Mellon Universitya> and has been primarily associated with a technique whereby an individual identifies a distorted set of characters in a bit-mapped image, then enters those characters into a web form. This approach is widely familiar to users of the web, though the term CAPTCHA is generally recognized only by web professionals.p>
 -			<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully noninteractive approaches.p>
 -			<p>It will surprise no one that we applaud the recent emergence of noninteractive approaches because functional noninteractive approaches pose no accessibility challenge to users. Unfortunately,  some current noninteractive approaches come at the price of exposing much data about the individual user to the noninteractive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testinga> requiring only minimal interaction with users.p>
 +			<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully non-interactive approaches.p>
 +			<p>It will surprise no one that we applaud the recent emergence of non-interactive approaches because functional non-interactive approaches pose no accessibility challenge to users. Unfortunately, some current non-interactive approaches come at the price of exposing much data about the individual user to the non-interactive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testinga> requiring only minimal interaction with users.p>
 		section>
 			                <section>
 						                        <h3>The Accessibility Challengeh3>
 				  <h4>Proof-Of-Workh4>
 				  <p>One strategy for thwarting misuse of web resources is to load suspicious clients with significant computational workloads, thus
 				  slowing down the interaction and hopefully deterring malicious parties by reducing their ability to engage in undesirable activities such as disseminating spam. This approach has been explored in the development of proof-of-work challenges. [[kaPoW-plugins]] These can be made arbitrarily expensive computationally based on an associated reputation score for each client that attempts to access a resource. Clients that are adjudged more likely to be malicious are required to solve more computationally expensive problems. Less resource-consumptive problems are provided to clients that are adjudged more likely to be web browsers operated by human users.p>
 -				  <p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots—perhaps even greater than the cost of hiring human workers as <a>CAPTCHAa> solvers.p>
 +					<p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots—perhaps even greater than the cost of hiring human workers as <a>CAPTCHAa> solvers.p>
 				  <p>Implementing this approach is straightforward. It requires the client to execute JavaScript code to solve the computational problem, and the solution is then verified by a server to establish that the work has been performed. It  poses no direct accessibility problems, though it may slow performance for users of older hardware.p>
 				section>
 				<section>
 request right now." Users who have depended on audio CAPTCHA alternatives, who have previously been able to function with reCAPTCHA v2, are thus suddenly and seemingly capriciously locked out and denied service on sites still using V2.p>
 			section>
 			<section id="recap3">
 -			<h4>The Noninteractive Version 3h4>
+-
 -<p>Late in 2018 Google released <a
 -					href="https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html">
 -	reCAPTCHA v3a> promising to eliminate "the need to interrupt users
 -with challenges at all." <a
 -	href="https://lists.w3.org/Archives/Public/public-rqtf/2019Mar/0019.html">Google
 -	also informed usa> that their goals with v included increasing "the
 -accessibility of the web by removing traditional CAPTCHAs" entirely.
 -Obviously, fully noninteractive <a>Turing testinga> is a most welcome development
 -direction for accessibility. When the noninteractive <a>Turing testa> returns a
 -score indicating high confidence that the user is human, or indeed a score
 -indicating high confidence that the user is a robot, and experience has
 -demonstrated the noninteractive engine is reliable, we can only offer praise
 -and gratitude for technological progress that more effectively supports persons
 -with disabilities.  p>
 +			<h4>The Non-interactive Version 3h4>
++
 +<p>Late in 2018 Google released <a href="https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html"> reCAPTCHA v3a> promising to eliminate "the need to interrupt users with challenges at all." <a href="https://lists.w3.org/Archives/Public/public-rqtf/2019Mar/0019.html">Google also informed usa> that their goals with v included increasing "the accessibility of the web by removing traditional CAPTCHAs" entirely. Obviously, fully non-interactive <a>Turing testinga> is a most welcome development direction for accessibility. When the non-interactive <a>Turing testa> returns a score indicating high confidence that the user is human, or indeed a score indicating high confidence that the user is a robot, and experience has demonstrated the non-interactive engine is reliable, we can only offer praise and gratitude for technological progress that more effectively supports persons with disabilities. p>
 <p>Of course no approach will always return unambiguous results. <a
 	href="https://developers.google.com/recaptcha/docs/v3">In such
 specific to their site to make a more informed judgment." Google intends
 that traditional CAPTCHA no longer be used as a  fallback mechanism and has dropped  it from v reCAPTCHA, though it remains in their slightly older, 2017 <a href="https://developers.google.com/recaptcha/docs/invisible">reCAPTCHA v2 Invisiblea> service.p>
 -<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testinga>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ  declares that <a href="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going awaya>. It is therefore imperative that methods for disambiguating an ambiguous noninteractive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach.
 -p>
 +<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testinga>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ declares that <a href="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going awaya>. It is therefore imperative that methods for disambiguating an ambiguous non-interactive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach. p>
 			section>
         section>
 		<section id="fedtoken">
 			<h3>Why not Federated Turing Tokens?h3>
 -<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <a href="http://lastpass.com">Last Passa>,  offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices.
 -Services like
 -Amazon's <a href="https://aws.amazon.com/cognito">Cognito,a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control.
 -Others, like
 - <a href="https://developers.facebook.com/products/account-creation">Facebook's
 -Account Kita>,
 -seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform.
 -It has been unclear to us at first blush which, if any, of these services prioritize  restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for noninteractively authenticating their humanity with third parties. The only exceptions of which we're aware are <a href="#recap3">reCAPTCHA v3a and <a href="#privpass">Privacy Passa.p>
 -			<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPNa> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee—such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?p>
 +<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <a href="http://lastpass.com">Last Passa>, offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices. Services like Amazon's <a href="https://aws.amazon.com/cognito">Cognito,a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control. Others, like <a href="https://developers.facebook.com/products/account-creation">Facebook's Account Kita>, seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform. It has been unclear to us at first blush which, if any, of these services
 +					prioritize restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for non-interactively authenticating their humanity with third parties. The only exceptions of which we're aware are <a href="#recap3">reCAPTCHA v3a> and <a href="#privpass">Privacy Passa>.p>
 +			<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPNa> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee—such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?p>
 		section>
 		section>
 		<section>