Description of the pilot concept

This submission introduces the Account Authority Digital Signature (AADS) scheme as an optional method by which a bank may authenticate its accountholder. AADS could authenticate accountholders in a variety of payment models. This proposal discusses AADS authentication of Buyers by Buyer's Banks in the Internet Credit Push (ICP) model, as an illustration of its potential use.

What is AADS

The Account Authority Digital Signature scheme of Public Key Infrastructure proposes to deploy asymmetric cryptography in support of financial (or account oriented) transactions, yet avoid some of the complexity and infrastructure requirements of other PKI schemes such as that proposed by ITU X.509. In AADS, there is no requirement for the issuance of digital certificates per se. Instead, an account holder (such as the Buyer in ICP) holds a key pair signing key and a validation key. The account holder securely communicates the validation key to the account issuer (the Buyer's Bank in ICP). The account issuer securely holds the validation key within its records concerning the account.

When the account holder wishes to send a signed message to the account issuer, she uses the signing key to create an encrypted message digest, which is sent with the message to the account issuer. Note that there is no transmission of key material or certificates with the message and no involvement of any trusted third party. The account issuer decrypts the received digest, using the validation key from the account data, and compares it to a new digest of the underlying message. If the digests match, then the sender of the message possesses the signing key corresponding to the validation key in the account records, and the message sender's authority over the subject account is validated.

This model simplifies the authentication of the account holder because:

• The status of the key is equal to the status of the account which is already well-known to the account issuer. There is no need to handle revocation information.
• Because there is no certificate, there is no possibility that a certificate will be misused or "leaked," nor is there any possibility that the issuer will have to defend against charges of negligent misrepresentation.
• The idea of a key protecting an account may be more easily understood by consumers as an evolutionary enhancement over "PIN"s, and may therefore achieve faster market acceptance than accounts protected by digital certificates.

This is a brief introduction to AADS and does not attempt to provide comprehensive documentation: please refer to
https://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt or to
https://www.garlic.com/~lynn/aadsover.htm
for more details.

Buyer Authentication in Credit Push

In the Internet Credit Push model, as submitted to the Internet Council in response to the RFI, the first step (from the steps on page two) is the issuance of digital certificates to the buyer and the seller by their respective financial institution CA's. Subsequently, in step 4, the "Buyer transmits signed invoice, its certificate, and seller's certificate to the buyer's bank" These steps are illustrated in the figure on the right.

Buyer Authentication using AADS

This proposal would leave intact the authentication flow described above, but would also define an alternative in which buyer authentication would use AADS. Any bank could elect traditional certificate based buyer authentication, or could elect to use AADS.

Because the buyer's authentication involves only the Buyer and the Buyer's bank, this election would be fully at the discretion of each Bank. Here would be no need for consensus among banks, nor any need for pairs of banks to agree among themselves.

The pilot would proceed exactly as documented in the Internet Credit Push submission except as follows:

The Buyer's Bank would not issue a certificate to the buyer. Rather, the buyer (or the banking software/plug-in/player provided by the Bank) will generate a key pair and then register the public or validation key with the Bank.

The Buyer when countersigning an invoice in order to send it to the Buyer's Bank, will not use any certificate nor include any certificate or key in the material sent to the bank. Rather, the buyer will sign the invoice using an AADS signature, consisting of the invoice together with an encrypted digest of the invoice created with the Buyer's signing key.

Validation of the Buyer's signature on the invoice is performed by the Buyer's Bank using the validation key in the bank's account records.

Duration

The duration of time the pilot would need to be operational to derive meaning/lessons learned.

There may be an investment of a couple of months while banks and their software providers determine how AADS functionality for key registration, signature creation, and signature validation will be implemented in Buyer client software and Bank servers. Combining these two months with the 60 to 90 day estimate in the ICP proposal, I will estimate 120 to 150 days.

Concepts

What concepts specifically are being tested in the pilot, and why a pilot is necessary to gain adequate knowledge about the concept

This proposal is designed to test a hypothesis that eliminating the need for Buyer's certificates and lifecycle maintenance thereof, while retaining the Buyer's ability to create signed messages that can be authenticated by the Buyer's Bank, will

• Create a more easily deployed and maintained infrastructure
• Reduce risk
• Facilitate consumer acceptance

By defining the pilot to offer each bank the option to use X.509 certificates or AADS for buyer authentication, we could create an opportunity to observe contemporaneous implementations of comparable facilities, and examine the relative benefits of these two approaches.

Advancing the business of PKI and/or payments

The AADS approach to authentication, if included in the ANT2 pilot, would add the following value:

PKI

• Would provide an opportunity to demonstrate the concrete costs, benefits, and risk management afforded by incorporating certificate-free PKI authentication into a payment process.
• Would provide a demonstration of AADS and X.509 incompatible mechanisms being used by different banks that would nevertheless participate in a seamlessly integrated application flow.

Payments

• Would create a potential model for Internet-originated payments which, if it succeeds in being simpler, less difficult to deploy and maintain, and easier to explain and understand, may hasten the adoption of Internet-originated ACH.
• Would provide an opportunity to test proposed amendments to NACHA Operating Rules on different technologies, which will help to avoid inappropriate technology-specific wording.