AADS
Public key digital signature technology can represent part of a strong authentication business process. However, it only represents a part of a business process infrastructure, also required is (at least) the binding of the digital signature to something that has meaning within a business process.
There is currently a lot of attention in the public key sector on the use of digital certificates for new kinds of electronic commerce applications. Digital certificates provides a mechanism for binding a public key to some identity or set of attributes where there is no existing binding infrastructure.
The traditional PKI infrastructure talks about issuing certificates that are signed by a certification authority which attest to the:
The associated PKI-use model has an entity "digitally signing" a document with their private key and "pushing"
to another party. The receiving party presumably will validate the authenticity of the digital-signature and the originator's public key via the contents of the associated digital certificate (as well as processing the certificate supplied identity and/or attribute information). Originally the contents of the digital certificate was assumed to be sufficient such that digital signature validation and identity/attribute processing could be performed without any additional electronic transmissions. As the methodology matured, it became apparent that more and more complex verification mechanisms were needed, if nothing else various status could have changed between the time that the certificate was originally manufactured and the current moment. Certificate revocation lists (CRLs) were one such development in an attempt to partially address the issue of current real-time status in the offline verification model.
An objective of AADS is to incorporate (public key digital signature) strong authentication into existing business infrastructures; enabling them for electronic commerce operations. Many of the existing business infrastructures already use account-based methodology as a means of binding attributes. Several of these account-based business processes already support non-face-to-face transactions using authentication bindings with things like "mother's maiden name", "social security number", and PINs.
In many cases, adding AADS capability represent simple extensions to existing (account-based) business infrastructures. Public keys are added to existing non-face-to-face transaction capability (i.e. account registering a public key using processes similar for registering things like mother's maiden name, SSNs and PINs). This represents the minimal change to the existing business processes (maintaining the current business process environment) while at the same time extending account-based business processes to strong authentication electronic commerce transactions.
An AADS transaction eliminates the need to append a certificate to a digitally signed transaction. The transaction/document with appended digital signature is all that is necessary for an AADS transaction (with no appended certificate). At the receiving party, the appended digital signature is authenticated by retrieving the public key from the associated account record (not from an appended certificate). The values and attributes in the account record will contain sufficient information to authorize the transaction.
There have been some early electronic commerce pilots that have relied on certificate-based bindings which minimize the software changes to existing business implementations. However, for account-based business processes, the certificate-based bindings are disjoint from the standard business processes. For small pilots, there is an acceptable trade-off which ignores the risks created by having part of the infrastructure totally disjoint and non-integrated against having to modify existing data processing implementations. Benefits from small pilots would typically be less than expense of modifying existing business process implementations (especially if it hasn't yet been determined exactly what the changes should be long term).
To make electronic commerce real, it will be necessary to demonstrate integration of public-key bindings into the core account-based business processes. This requires changes to installed data processing implementations. Without this integration, there is little hope of deploying electronic commerce on a large scale. The lack of business process integration and the associated risks far outweighs any increased costs associated with modifying existing data processing implementations. In fact, for an account-based business process that might try and grow a non-integrated certificate-based binding pilot, the long-term result would be massive increase in amounts of technology, software and human effort constantly trying to reconcile the independent certificate-based binding and the account-based binding business processes. Integration of public-keys into existing account-based business processes is the only reasonable method of scaling electronic commerce operations (in those account-based operations).
One of the policy issues for an electronic commerce payment protocol, like X9.59, is privacy. In a typical retail electronic commerce payment, a merchant is interested in knowing if funds will be paid; it is not necessary to know the identity of the consumer (for payment; it might be necessary to know an address for hardgood shipment, but not for payment). The response from the Consumer's financial institution in X9.59 would assure a merchant of payment (w/o having to divulge any consumer identity information). A X9.59 payment utilizes account authority digital signature for the consumer's bank to authenticate the payment transaction.
CA-based digital signature transaction might typically carry with it a X509v3 certificate. Such certificates are nominally defined as carrying identity information; nominally the person's "distinguished name" and possibly additional attributes like address. In some CA-based business scenarios, it has been proposed that various fields in X509v3 identity certificates be truncated and/or redefined to minimize the amount of identity information (and therefore the privacy exposure utilizing such certificates).
In the account-based business world, the issue is primarily authentication, not identification. Any identity issues are part of the business process that establishes the account. Different account-based business processes have different identity requirements for establishing an account. Hypothetically, if the business account-setup identity requirements are similar to identity requirements for a certificate, such a certificate might be appropriate for an account establishment transaction.
Normal account-based business transactions involve authentication (and authorization) issues against the information that are bound with the account. A partial issue in the use of accounts for attribute binding are the requirements for real-time attributes (like amount of money available in the account and/or total charges out-standing to-date).
Identity certificates in an account-based payment environment unnecessarily propagates individual privacy information (say to a merchant when it is not necessary for the merchant to know anything except that funds will be available). Other types of attribute-based certificates are superfluous in an account-based environment because they duplicate the attribute binding function already provided by the account infrastructure. Furthermore, attribute certificates could actual create unnecessary fraud and risk scenarios when the certificate represent stale copies of attributes maintained in real-time at the account.
The progression of the authentication world can be characterized as
The non-electronic and offline world can be characterized as driver's licenses, letters of credit, employee identification cards, etc. In the credit card world, paper invalid credit-card booklets were distributed to merchants on a regular basis.
Certificates were original developed as electronic analogs of the non-electronic methods. This electronic world was offline but involved things like point-to-point communication and stand-alone badge readers. This was also characteristic of the dominant mode of "offline" email operation, calls were made to an email server, queued email exchanged and the connection was broken. Actual email processing occurred offline on a machine that was only sporadically connected involving simple point-to-point exchange with variety of different machines.
Certificates can improve identity and/or authentication process in offline transactions, where there was no access to any online account-based bindings. In such scenarios, certificates can represent an improvement in the level of confidence regarding the offline transaction. This is similar to the use of drivers license to improve authentication in a retail check or credit transaction. The financial industry didn't have the technology to online authenticate the consumer at point-of-sale and so had to rely on the merchant (and whatever credentials were commonly available).
The transition to the electronic and online world can be exemplified by the current credit-card infrastructure (which skipped over the electronic and offline stage which would have been exemplified by distributing electronic analogs of the invalid credit card booklet). The credit-card industry went to an online paradigm involving real-time authorization including checking of real-time credit-limit status.
In online business transaction, a certificate typically would represent a duplication of the binding information provided by a business account record. Furthermore, use of the certificate could seriously degrade the transaction quality because the certificate binding might not be a one-to one match up of information required by the business process (represented by the information in the account record) and/or the certificate binding might represent stale information (compared to that in the account record).
Flowing certificates in an online account-based transaction would typically represent at least a superfluous effort. However, such certificate flow potentially degrades the quality of the transaction by:
A financial infrastructure with triple-redundant bunkered datacenters in different geographically locations will not have its availability and/or integrity improved if dependencies to complete a transaction are introduced involving external sources.
A x509v3 highly trusted identity certificate with name & address could possibly be interesting for account setup & registration for financial institutions; possibly helping with the government "know your customer" mandates.
However, possibly lost when wrapped around the certificate-axle when assuming that every digital signature automatically mandates a certificate to go with it, certificates can be superfluous in the account authority world and for consumer retail payments raises privacy concerns.
The financial industry's X9.59, is a light-weight, high integrity, strong authentication payment protocol targeted for all methods of electronic payment; including, but not limited to settop boxes, point-of-sale with online authorization, as well as merchant web servers.
With the appropriate smartcard, X9.59 can work at point-of-sale, even improving the integrity of the current POS infrastructure, while eliminating the necessity for any identity information in the payment transactions (a high-integrity smartcard would eliminate the additional authentication processes involving cross-checking the name on the credit-card with things like a driver's license).
With the appropriate smartcard, the account number and the digital signature on the transaction would be sufficient to satisfy high integrity requirements. A combination of the appropriate smartcard, digital signature, and online network provides the financial industry the necessary components to authenticate consumers at retail locations.
One of the issues simplified in the AADS model (compared to trusted third party Certification Authorities) is liability.
It is sometimes remarkable what happens when you shift the paradigm.
This is just a little of the fall-out when a Certification Authority digitally signs a certificate that attests to some binding between a public key and some identity or set of attributes (and a relying party becomes dependent on the certified binding).
There still may be individual liability depending on how their digital signature on a transaction is treated. If signature is on a financial transaction, then it could be treated as a more secure form of PIN authentication, in which case it can fall totally within existing regulations.