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
https://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 ....
- a large regulatory infrastructure that needs to regularly audit
webservers for unauthorized &/or misuse of privacy information like
name & address ... or
- 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 https://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