slightly related reference to the discussion about differentiating certification from certificates .... where certification can be either online or offline ... it is the business process .... and certificates is a specific delivery mechanism for an offline environment/paradigm. http://www.garlic.com/~lynn/aadsm14.htm#47"; UK: PKI "not working"
so an extremely widely deployed internet online authentication mechanism ... that is sort of a subset of the online credit/debit is the age verification mechanism in use by the adult entertainment business. Baiscally, having a valid credit card is assumed to be equivalent to a being of age to sign a valid contract. So the online age authentication asks for sign-up/registration by filling in credit card information .... with a disclaimer that nothing shows up on your bill. Basically, they take the credit card information and do whats called a one dollar auth. If there is a positive response from the credit card transaction, the online age authentication service then creates its own account record as to the validity of the entity. In the future, when visiting an adult website, there is a request to do an online transaction with one of the age authentication services .... which does an online lookup and provides a response to the adult website. FSTC's FAST would have been able to provide something similar directly from the financial institution rather than going through a two-level authentication infrastructure. note that intrinsicly the 8583 network doesn't necessarily is a high-overhead transaction. There is wide deployment in the US of magstripe online stored-value mechanism that use the same point-of-sale terminal & network as the credit & debit card transactions; modulo the issue of fraud management, an internet 8583 payment gateway could also handle internet debit and stored-value transactions as easily as it handles internet credit transactions (it isn't a technology issue, it is a .business management issue). another one of the examples is RADIUS authentication server for a multitude of widely deployed relying-parties. An example is some of the large US ISPs that have either their own POPs (point of present) local telephone numbers or contract with other vendors for POPs. This can involve hundreds, if not thousands of routers distributed thru-out the US. ISP customers may have on the order of thousand local telephone numbers around the world that they can call and connect to their ISP. Each one of tghese POPs tends to have local ROUTER than performs the initial authentication of the incoming call before allowing connection to the ISP services. As mentioned, the numerous POPs may actually belong to the ISP, or belong to some other organization that the ISP has a contractual relationship with. Basically these thousands of routers around the world have direct connection to the ISP's RADIUS server in order to obtain the authentication information as well as various authorization and accounting information. While the extensive use of RADIUS as the fundamental authentication mechanism on the internet is used by PPP for client to ISP connection, the RADIUS service is a generalized facility that can be called by a large number of different operations. For instance, there are typically RADIUS plugins for many of the available webservers that support client authentication via RADIUS service. The use by ISPs of RADIUS for account-based authentication, authorization, and accounting control spanning the world and thousands of servers .... easily exceeds the requirements and demands of any existing e-gov webserver infrastructures. In fact, given that ISPs supported account-based st digital signature RADIUS authentication, and some contractual relationship between a collection of e-gov servers .... it would be possible for e-gov server to directly rely on the ISPs' authentication process w/o requiring a separate e-gov portal authentication service. Many of the existing e-gov authentication portals basically implement the KERBEROS model with proprietary technology. An e-gov authentication portal could implement a PK-INIT Kerberos digital signature authentication and provide KERBEROS authentication for all the other webservers in a particular e-gov infrastructure. This basically allows for adoptation of standard distributed authentication infrastructure using existing factilities already available on the base platforms that the any of the e-gove initiatives are deployed on. Not only is account-based authentication the dominant and most widely used authentication paradigm in the world today .... but some flavor is built into most of the base platforms. misc. past descriptions of the one dollar auth scenario http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59 http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda) http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol http://www.garlic.com/~lynn/2003h.html#23 Authentication protocol misc. past RADIUS threads: http://www.garlic.com/~lynn/subpubkey.html#radius misc. past Kerberos threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
