X9.59 mailing list

x959 Postings and Posting Index, next - home



OTP and X9.59 Offline Ordering
AADS, Security, and the Federal CP Model
X9.59 & AADS deployment considerations
CA disaster recovery issues (cross-posting with pkix)
AADS and non-face-to-face transactions
AADS, X9.59 and privacy
more AADS, X9.59 and privacy
Positioning AADS and CADS
AADS/X9.59 cost sharing intuition
US firms gird for privacy rules
US firms gird for privacy rules
US firms gird for privacy rules


X9.59 email purchase transactions (from lynn)

From: Lynn Wheeler
To: ansi-epay@xxxxxxxxmerce.Net
Subject: X9.59 email purchase transactions (from lynn)

+----------------------------------------------------------------------+
This message was addressed to:  ansi-epay@xxxxxxxx
+----------------------------------------------------------------------+

From: Anne Wheeler on 12/03/97 05:49:50 PM
To:   otp-dev@xxxxxxxx
cc:   Thomas_C_Jones@xxxxxxxx
Subject:  X9.59 email purchase transactions (from lynn)

+----------------------------------------------------------------------+
This message was addressed to:  otp-dev@xxxxxxxx
+----------------------------------------------------------------------+
Something that has been raised as part of the x9.59 business requirements is the ability to perform a purchase from something like a cdrom by sending off an email message and (eventually) getting an email response with approval/ack that the transaction actually takes place. The implicit requirement is for sufficient information being included on the cdrom such that a order/puchase/payment can be performed in a single round trip. This may mean that some of the selection process is somewhat statically limited ... and also implies the initialization and selection process doesn't happen so much as a message exchange ... but more as a database walk of static information on the cdrom (although some amount of html presentation, is a database walk). somewhat philisophically is whether there are explicit or implicit features that prevent a order/purchase occuring in a single round-trip.

Federal CP model and financial transactions

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: william.burr@xxxxxxxx
cc: x9f5@xxxxxxxx, ansi-epay@xxxxxxxxmerce.Net, smedinghoff@xxxxxxxx
Subject: Federal CP model and financial transactions


+----------------------------------------------------------------------+ This message was addressed to: ansi-epay@xxxxxxxx +----------------------------------------------------------------------+
Mike Versace distributed your model certificate policy draft to the x9f5 and x9a10 mailing lists.

I've been working on a revised PKI-model in support of financial transactions and x9.59 electronic payments. This PKI-model is slightly different the offline PKI-model being addressed by your certificate policy draft, but is at least as important to the financial community. In addition to the operational differences between the AADS-model and the CADS-model for financial systems, there is also a huge systemic risk difference between the two models when financial transactions are involved.

While the AADS-model doesn't negate any of the business requirements for certificate policy statement standards supporting the offline PKI-model, it does open up a new important class of PKI operations for supporting business and financial transactions. Also, many of the authentication issues are the same for in AADS and CADS registration.

In the AADS-model and in X9.59 financial transactions, there could be multiple relying parties on the digital signature verification done by the payer's/customer's financial institution. This opens up the possible requirement for a policy statement associated with the signature verification process (similar to policy statement for certificate, although there is a signficant difference in the scope of the business risks between AADS and CADS).

For a more detailed description of the AADS and CADS issues see

http://www.garlic.com/~lynn/

As an aside ... I coined the term certificate manufacturing about a year ago; this is the first time I've seen it used anyplace else.


Brought to you by the CommerceNet Consortium <http://www.commerce.net>,
the premier industry association for companies working together to make
Internet commerce easy, trusted, and ubiquitous.




From: Lynn Wheeler
To: william.burr@xxxxxxxx
cc: x9f5@xxxxxxxx, ansi-epay@xxxxxxxxmerce.Net, smedinghoff@xxxxxxxx
Subject: Federal CP model and financial transactions ... addenda

+----------------------------------------------------------------------+
This message was addressed to:  ansi-epay@xxxxxxxx
+----------------------------------------------------------------------+
Another issue for some portions of the financial infrastructure for reliance on certificates is the security level of the certification implementation and infrastructure.

In general, these financial infrastructures have to remove certificates out of mailine core processing because of real-time status and systemic risk issues (but could still use AADS-model PKI). However, certificates could be used as part of an AADS registration process. Depending on the degree of reliance on the meaning of the certificate, it is possible that the certification infrastructure then would have to meet the same level of security implementation and audit (not just good programming practices, but security defined process for the architecture, design, coding, and testing of the certification implementation ... in addition to various levels of security audits of the operation system).

ISO8583 (credit-card) Flow ... ebcdic/ascii mapping

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: ISO8583 (credit-card) Flow ... ebcdic/ascii mapping
One of the issues in the 8583/credit-card flow is the ebcdic/ascii mapping. At the ibm mainframe not all ebcdic->assci translate tables are the same. X9.59 calls for the signed data elements to be in ascii format.

Since DSS is a bit-wise encryption of SHS ... and SHS is bit-wise encoding of the data elements ... digital signature verification is very bit sensitive.

Long ago & far way ... when I was an undergraduate ... four of us built our own mainframe control unit (someplace the four of us are documented/blamed for originating the IBM OEM control unit business).

I hadn't done some adequate investigation of a couple of IBM's convention ... and after we got the channel interface hardware debugged ... and was getting data into the mainframe memory ... it looked all garbage (we were using tty/ascii devices). Little bit of investigation turned up inconsistency in the line-scanners.

Standard ascii convention is to transmit the high-order bit (within a byte) in the leading bit position. Standard IBM mainframe convention is to transmit the low-order bit (within a byte) in the leading bit position. Standard TTY/ASCII data arriving at ibm mainframe memory thru a standard ibm control unit it bit-reversed within each byte (analogous to ... but different from little/big endian issues). The ibm ebcdic/ascii telecommunication translate tables ... deal with translating ebcdic to & from this "reversed-bit" ascii format (under the assumption that ascii data is only there to be sent/received via a ibm control unit ... with bit-reversed transmission convention.

For a x9.59 digital signature to be verified (on an ebcdic ibm mainrame) the original ascii data element format has to be recreated. If this is going to be done in the memory of the ibm mainframe ... the ebcdic representation from the 8583/interchange interface must be converted back to ascii. However, if a ebcdic->ascii telecommunication translate table is used ... the resulting ascii representation would be in bit-reversed format (because of the assumption made about ascii be only used for transmission). To correctly be able to validate an x9.59 digital signature ... the original ascii bit representation has to be recreated ... not the bit-reversed ascii representation.



From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: ISO8583 (credit-card) Flow ... ebcdic/ascii mapping ... addenda
The other issue that shows up with doing public key operations in &/or around mainframes is the use of outboard public key accelerator boxes. The outboard boxes can typically be accessed by LU6.2, TCP/IP, or customer channel protocol. The functions performed can be as simple as performing the digital signature verification when passed a hash, an existing digital signature, and the presumed public key (i.e. decrypt the digital signature and compare the resulting value with the hash). Slightly more complex is passing the signed data (in correct format) and the outboard box calculates both the hash and performs the digital signature verification (somewhat driving up bandwidth requirements, but removing the hash calculation from the mainframe).

Standard IBM mainframe tcp/ip product has had a design point of half the thruput of LU6.2 .... making neither TCP/IP nor LU6.2 a great choice for this function ... for any high thruput areas.

One of the issues is the traditional open system I/O paradigm involving buffer copy operations (also shared by some of the mainframe telecommunication protocols) ... where the data involved in the I/O is copied between buffers at least once ... and possibly as many as 10-15 times. The traditional mainframe normal I/O thruput involve no buffer copies (sometimes referred to by "locate-mode"). In the open system arena this has shown up in recent years with POSIX asynch I/O (although not part of the standard paradigm operation ... primarily found with DBMS subsystems when doing DISK "raw" I/O to non-filesystem drives). An issue that arises in the buffer-copy mode is that the machine-cycles involved in doing the data copying can exceed the machine-cycles involved in the instruction execution for the whole application.

The original IBM TCP/IP product ocnsumed significant amount of 3090 CPU in order to achieve throughput of 44kbytes/sec. At that time, I had implemented & integrated RFC1044 support which shipped in at least some of the standard IBM TCP/IP products ... and benchmarked at Cray Research between a 4341 and a Cray with sustained TCP/IP thruput at IBM channel media spead (1mbyte/sec) using only nominal amounts of 4341 CPU utilization.

disaster recovery cross-posting

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: disaster recovery cross-posting
cross-posting from pkix on disaster recovery issue

From: Lynn Wheeler
To:   ietf-pkix@xxxxxxxx
Subject:  RE: Disaster recovery
that is precisely one of the areas that account authority addressses ... certificate manufacturing represents trust propagation ... unless every use of the certiicate comes back to the certificate manufacturing ...

the manufactur of the certificate has no idea where that trust is being propagated. In the online world, having every use of the certificate come back to the manufactur ... provides several beneiftis (online status, knowledge of all relying parties, knowledge of all relying uses); for many criticial relying uses for certificates, online reference may be the only method that would meet business requirments.

In account authority .... certificates can be eliminated since either 1) the relying party and the registration party are the same or 2) business requirements require online status ... since certificates were originally formulated as a solution for offline transactions ... introduction of online status effectively nullifies their original design goal ... any online status protocol is really interested as to the current status of the public key ... getting online status of the certificate instead ... is a 2nd order obsfuscation.

From: Lynn Wheeler To: ietf-pkix@xxxxxxxx Subject: RE: Disaster recovery ... addenda
I had coined the term certificate manufacturing a couple years ago ... but in the late 80s working on high availability systems ... i also coined the term disaster survivability to help distinquish between most disaster recovery implementations ... typically involving off-site storage and rebuild of infrastructure after disaster; objective of disaster survivability was to eliminate the outage and rebuild ... actually have the infrastructure continue operation in the face of disasters (also one of the reasons that account authority digital signature talks about not adding additional systemic risks to existing business processes).

Account Authority Digital Signatures ... in support of x9.59

From: Lynn Wheeler
To:     ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Subject: Account Authority Digital Signatures ... in support of x9.59

Account Authority Digital Signatures

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.

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 numbers", and PINs.

In many cases, addiing 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.

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 modifiy 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).



Account Authority Digital Signatures ... in support of x9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Subject: Re: Account Authority Digital Signatures ... in support of x9.59
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).

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 redundant and 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, static copies of attributes maintained in real-time at the account.

Certificates were originally intended to 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.

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, static information (compared to that in the account record).

Flowing certificates in an online account-based transaction would typically represent at least a redundant and superfluous effort. However, such certificate flow potentially degrades the quality of the transaction by:

• unnecessarily divulging information (like identity) to parties in the transaction

• creating a false impression of security if decisions are made based on stale, static or inconsistent information bound in the certificate

• opening the infrastructure to unnecessary systemic risks like attacks on the certificate signing key

[E-CARM] AADS, x9.59, & privacy

Refed: **, - **, - **
From: Lynn Wheeler
To: e-carm@xxxxxxxx
Subject: Re: [E-CARM] AADS, x9.59, & privacy
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, one of the issues possibly lost when wrapped around the certificate-axle is the issue of privacy ... the idea that every digital signature automatically mandates a certificate to go with it, turns out to be redundant and superfluous in the account authority world ...and for consumer retail payments raises a whole bunch of privacy issues.

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 (i.e. no name, address, phone no, etc). With the appropriate smartcard, the account number and the digital signature on the transaction would be sufficient to satisfy high integrity requirements.

AADS NWI and XML encoded X9.59 NWI

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: AADS NWI and XML encoded X9.59 NWI
there has been further work to position AADS/X9.59 along the lines of:

there are two modes: electronic and non-electronic and two paradigms offline and online. There are four possible combinations (actually three of interest):

1) non-electronic and offline paradigm

letters of credit, checks, drivers license, paper-based world. another example was the original offline credit-card world that mailed out the paper lists of invalid credit card numbers.

2) electronic and offline paradigm

this is where certificates and certificate authorities came in. this was in the days of point-to-point communication and things like stand-alone badge readers. electronic analogs of drivers license were invented to handle the situation of non-face-to-face communication in an electronic point-to-point environment. It was necessary to provide the electronic analog of paper-based credentials that would worked in the electronic point-to-point (i.e. non-networked, offline) environment. certificates were invented to serve the purpose of electronic credential analogs for offline operation. This has also been applied to the email paradigm ... where at least one mode of operation assumes that email can be delivered and then allowed to be processed synchronously and offline (while the recipient may have no direct connectivity to the sender and/or any online authority).

3) electronic and online paradigm

this is the AADS environment that assumes online networks and interconnectivity (rather than simple offline, point-to-point electronic operation from #2). another example is the current existing online credit-card operation which jumped from the non-electronic, offline environment directly to online authorizations .... skipping any intermediate, offline stage that might have attempted to do something like distributing electronic analogs of the invalid credit card lists.

this is the method followed for X9.59 and AADS assuming both an electronic and an online paradigm both.

4) (hypothetical for completeness) non-electronic and online paradigm

since online presumes electronic ... this is a null set.

===================================================

One of the successes for email following the "offline" paradigm (at least assuming no direct connectivity between the participants) has been decoupling synchronous communication between the two parties. Although the asyncronicity assumption doesn't have to include "offline" ... for many years a lot of the mailers had to work in mode where the local machine called up a mail server, download the appropriate pieces of mail, hung-up ... and then distributed the email locally. A significant number of the mailers continue to provide for this as the assumed mode of operation (i.e. being able to process and read mail in a very sporadically connected world).

For related information see Knowledge Machines, Language and Information in a Technology Society by Denise E. Murray In the early '80s Denise spent nine months in the back of my offices taking notes on how I communicated ... and also doing detailed analysis of all my email. This turned into her PhD thesis at Stanford (i believe there was some number that I had email communication with avg of 280 different people per week over the nine month period).

Part of the challenge for email certificates in the offline paradigm is they are basically targeted for communication between two parties that have had no prior business relationship. In the personal correspondence space .... there are locally stored, personal "account authorities" ... with some capability of transferring information from a central "account authority" to the local "account authority" as needed. In the business space, there is EDI being carried via email mechanisms. This is really an automated prior business relationship scenario requiring extensive access to local account information regarding the business relationship. There is a vanishing niche for email certificates is the no-prior-business relationship where the email processing is truly offline ... and the recipient has to process the business email with no access to a real-time, online credentialing and/or verification service.

As the online world becomes more and more pervasive, this electronic but offline paradigm will continue to shrink. It will be interesting to see whether it shrinks faster in the business sector ... with the push to have more and more information up-to-the-minute and in as near real-time as possible or in the consumer sector ... with possibly online entertainment being a driving force.

AADS/X9.59 cost sharing intuition

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: AADS/X9.59 cost sharing intuition
Several times at X9A10 meetings there have been statements about the advantages of infrastructure cost sharing associated with AADS operation.

assertion #1: majority of a certificate authority is account-based management

assertion #2: cryptography for digital signature infrastructure can be added to existing financial account infrastructure at 1%-5% of the cost of the current infrastructure

corollary: cost sharing with integration of digital signatures into an existing financial account based infrastructure will have existing non-digital signature applications carrying 95%-99% of the total account costs.

assertion #3: high value digital signature financial applications can carry 90%-95% of the digital signature infrastructure cost

corollary: non-financial application use of a integrated financial digital signature infrastructure can be done at 1/200th to 1/2000th the per account cost of an independent non-financial digital signature infrastructure.

In a financial AADS infrastructure:

fraction of account costs covered by non-digital signature applications
.95 to .99

fraction of account costs covered by digital signature applications
.05 to .01

fraction of digital signature account costs covered by financial digital signature applications
.90 to .95

fraction of digital signature account costs covered by non-financial digital signature applications
.10 to .05

fraction of account costs covered by non-financial digital signature applications
.1*.05 to .05*.01
or
.005 to .0005 (1/200th to 1/2000th)

This is applicable to the integration and use of AADS/X9.59 in an existing financial account infrastructure.

This is also independent of the privacy and liability issues that have been identified by the European Union associated with X509 identity certificates.

U.S. firms gird for privacy rules

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: U.S. firms gird for privacy rules
some amount of the privacy information exists because of requirements by payment business processes. eliminating places where privacy information is required ... doesn't eliminate the problem of protecting privacy information when it is required ... just minimizes the number of places that the protection has to be applied (i.e. not having any privacy information to protect is even better than having privacy information and needing to protect it).

The hypothesis is that the actual aim of the EU is not to create protection infrastructures fpr tje sake of having protection mechanism (i.e. that is a second order effect) .... the hypothesis is that the EU is actually trying to achieve unnecessary divulging and use of privacy information. In places where privacy information has to exist ... then protection mechanisms have to exist in order to achieve the real goal. The claim is that the goal can also be achieved by elinating the instances of privacy information .... then it is not around for it to be divulge/used ... and therefor no protection mechanism is needed to protect the divulging/using something that doesn't exist.

We are assuming that the EU is really saying that protection mechanisms are necessary to prevent the misuse of privacy information .... not that we need privacy protection mechanisms just because there is a mandate to have protection mechanisms and that the protection mechanisms otherwise serve no purpose. Eliminating the existance of privacy information is also a method of preventing privacy information misuse .... since it is rather difficult to misuse something that doesn't exist.

U.S. firms gird for privacy rules

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: U.S. firms gird for privacy rules
sure it does .... typically if i go to a current typical web srever payment screen for buying/downloading software ... they want my name and address in addition to credit card number and credit card number expiration date.

the business point of x9.59 stated as one of the first things in the draft is that it can preserve the integrity of the financial infrastructure for all electronic retail payments using only a digital signature. additional discussions were predictions that digital content and softgoods were going to represent 90-99+% of future electron commerce transactions.

the draft then goes on to describe message elements that are digital signed that will meet the business objective. the message elements don't include any name and/or address to preserve the integrity of the financial infrastructure ... as is found today. while the main part of the x9.59 draft does in fact describe message formats .... x9.59 states a business reason/requirement for the message formats to exist. It is the stated business reason/requirement that were followed in the specification of the x9.59 message formats and the assurtion is that meeting those business stated business requires is what improves privacy (i.e. eliminating any financial infrastructure integrity requirements in the financial payment protocol for anything but the digital signature, no name, no address).

what is better when trying to eliminate unauthorized &/or misuse of privacy information ....
  1. a large regulatory infrastructure that needs to regularly audit webservers for unauthorized &/or misuse of privacy information like name & address ... or
  2. a web server environment that has no name & address informatinn


x9.59 contributes to name & address information never having to exist at the webserver in the first place ... the claim is that eliminating requirements for name & address to have ever existing at webservers is better. it is harder to misuse information that you don't even have ... than to figure out how to misuse information you have..

The claim is also that a digital signature card at the appropriate assurance level can be deployed for point-of-sale .... eliminating the requirement that there is even a name on the card and/or a signature (or than digital) is required. This then not only improves privacy in the web world ... but also improves privacy in the physical world.. This is not because of the message formats described by X9.59 ... but a stated requirement for X9.59 specification to even exist is to preserve the integrity of the financial infrastructure for all electronic retail payments with only a digital signature i.e. it is not another electronic message specification for the sake of having an electronic message specification ... it is a specification that meets some specific business requirements for all account-based payments; web, point-of-sale, debit, credit, set-top, etc.

U.S. firms gird for privacy rules

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: U.S. firms gird for privacy rules
or even simpler example ... say in 5-10 years there are 50million websites doing financial transactions of one sort or another ... mostly for digital content. X9.59 business requirements is that it preserve the integrity of the financial infrastructure for all electronic retail payments with only digital signature ... no name, no address, no phone number. In that respect X9.59 could reduce the number of web sites where privacy information flows thru because of payment system requirements (especially compared to the existing infrastructure) by a factor of 1000 ... say from 50,0000,000 to 50,000. The remaining 50,000 are primarily need name/address/phone because of hard goods shipment.

Note however, that large percentage of those shippers are now operating with barcode computerized routing code information ... not name/address. I claim that it would be very straightforward to set up account infrastructure with such shippers ... that would accept X9.59 digital signed transactions that only contained the (shipping) account number. This could achieve an additional factor of 1000 reduction in the number of web sites requiring name/address/phone .... from the original 50,000,000 to possibly 50. The website would apply the barcode account number ... and the shipper might apply any final name/address information at end delivery depot.

I would contend that the privacy regulators would have a much easier job dealing with 50 web sites that had to protect privacy information ... than 50,000,000.

One of the inhibiters in seeing such shipment infrastructure supporting privacy today is the MOTO payment infrastructure uses name/address ... so the privacy shipment function wouldn't actually reduce the number of places privacy information is required. With X9.59 eliminating privacy information for web MOTO payments ... the incremental benefit from privacy-neutral shipping becomes more signficant (and would in fact be facilitated by x9.59 account infrastructure with the shipper).

Lets throw into the digital content pot the whole ISP infrastructure .... i.e. your ISP may need your name/address because of payment requirement. X9.59 payment eliminates requirement that ISP need name/address because of payments. Also, as has been discussed (and archived at http://www.garlic.com/~lynn/) an AADS strawman supporting X9.59 could also be used by ISP in lieu of password authentication (with digital signature support by radius) ... improving the integrity and ISP confidence ... while further reducing requirements for unnecessary propagation of privacy information.

x959 Postings and Posting Index, next - home