note that the aads chip strawman (instantiated as http://www.asuretee.com) http://www.garlic.com/~lynn/index.html#aads
has definitions that supports signing all financail transactions ... aka part of the task given the x9a10 working group for x9.59 payment standard was all retail payments (not just internet, not just face-to-face, not just pos, not just non-face-to-face, not just credit, not just debit, not just stored-value, ... but ALL) ... http://www.garlic.com/~lynn/index.html#x959 and also piloted in the NACHA debit network trial .... pointer at: http://www.garlic.com/~lynn/index.html#aads basically some amount of AADS has focused on standards support for FIPS186-2, ecdsa/x9.62 digital signature standard as means of authentication ... and the aads chip strawman basically focused on just doing FIPS186-2, ecdsa/x9.62 digital signing. Note that the standards activity of having FIPS182-2, ecdsa/x9.62 digital signature standard as means of authentication doesn't mandate that it be done with a hardware token. the protocol specification of FIPS186-2/x9.62 authentication is independent of the environment that performs the signing. The issue of whether it is some PC software, or PDA software, or hardware and/or what kind of hardware token is an integrity and business issue. The protocol part can be common to all implementations ... and the end-point implementation then is purely a business & integrity issue (one factor authentication, two factor authentication, three factor authentication, and/or integrity level of the components). The other part is that possibly over 90 plus percent of the internet-related authentication events occur with RADIUS ... aka majority of the isps internets & corporate internets. aads enhanced radius has been demo'ed a number of times .... misc. discussions http://www.garlic.com/~lynn/subtopic.html#radius and pointer to demo at http://www.asuretee.com/ Another major authentication process that goes on in the world today is the kerberos based stuff supported by most of the operating system platforms (and not solely internet). the original kerberos standard has been shared-secret based ... however there is a draft standard to extend it to include public key based authentication that includes both certificate-based public key as well as certificate-less (aka AADS) based public key http://www.ietf.org/ids.by.wg/krb-wg.html http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt other discussions of upgraded the current certificate-based SSL public key infrastructure to certificate-less based infrastructure: http://www.garlic.com/~lynn/subtopic.html#sslcerts basically, any shared-secret, pin/password based infrastructure can be upgraded by using the same business process ... but with a public key, non-shared-secret based paradigm (and can all be supported by a single asuretee hardware token). for more information on kerberos & radius authentication standards ... go to http://www.garlic.com/~lynn/rfcietff.htm and under "RFCs listted by" select "Term (term->RFC#)" from there, it is possible to select RADIUS from the acronym fastpath .... aka remote authentication dial in user service (RADIUS ) see also authentication , network access server , network services 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 or scroll to kerberos ... aka kerberos see also authentication , security 3244 3129 2942 2712 2623 1964 1510 1411 [EMAIL PROTECTED] on 12/14/2002 9:53 am wrote: Those signing devices you refer to should not be limited to ecom. Face to face transaction need something similar. "Who is this person checking my signature and what qualification do they have?" I ask this question every time, especially this time of year after the fear mongering of the Associations to encourage checking of cards . We should not limit solutions to one medium this creates differences in our payment habits and further confuses the masses, lemmings that they are. To find a secure solution that does not bridge multiple mediums will go the path of SET.
