X9.59 mailing list
x959 Postings and Posting Index,
next, previous
- home
- Identity theft tops Consumer fraud complaints
- German federal employees get digital signatures
- High-tech Thieves Snatch Data From ATMs (including PINs)
- [ISN] Credit Card Scam
- I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
- credit card & gift card fraud (from today's comp.risks)
- UNCITRAL Electronic Contracting Project
- FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
- Continuing the Dialogue on New Authentication Services
- InfoSpace Buys ECash Technologies
- Working Group Cardholder Authentication and ICC Cards
- more on factoring breakthrough?
- Smartcard security (& PKI systemic risk) thread in sci.crypt n.g
- Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)
- META Report: Smart Moves With Smart Cards
- Worker Accused of Selling Colleagues' ID's Online (credit card scam)
- Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
- FC: European Commission considers mandatory digital rights management
- Misc. payment, security, fraud, & authentication GAO reports (long posting)
- Security Proportional to Risk (was: IBM Mainframe at home)
- Regarding SPKI delegation certificate format (frowaded)
- PKI: An Insider's View
- (Extensible Markup Language) XML-Signature Syntax and Processing
- Slashdot reports RSA keys under 2k insecure
- Definese Dept Criticised on Internal Credit Card Fraud
- Definese Dept Criticised on Internal Credit Card Fraud
- [dgc.chat] XML/X - part I
- Electronic Commerce Modeling Language (ECML):Version 2 Specification
- Using Microsoft Word to create Internet Drafts and RFC's
- Economics of financial applications of the smart card
- some certification & authentication landscape summary from recent threads
- some certification & authentication landscape summary from recent threads
- pk-init draft (not yet a RFC)
- some certification & authentication landscape summary from recent threads
- some certification & authentication landscape summary from recent threads
- Identity server infrastructure ... example
- landscape & p-cards
- Credit card fraud sending night-vision rifle scope to criminal
- Microsoft Trustbridge ... Kerberos (tickets) support
- AADS Chip Strawman & aSuretee
- ATM Scams - Whose Liability Is It, Anyway?
- FSTC Announces Proximity Payment Trial
- RFC3354 Internet Open Trading Protocol Version 2 Requirements
- Credit Card Skimming Rising In The US
- Credit card theft feared in Windows flaw
- x9.73 Cryptographic Message Syntax
- IBM launches smart-chip consultancy - Tech News - CNET.com
- Government of Canada Public Key infrastructure
- Finance firms push messaging standards
- glossary
- San Diego Company owns e-commerce
- REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
- First International Conference On Trust Management
- GAO Government Agencies Adhering to Privacy Laws
- Meeting to mull privacy standard's next step
- Workship on Human/Computer Interaction and Security systems
- SAML Just The Start For Web Services Security
- Cardtech/Securtech aSuretee press release
- Liberty Alliance Waves White Flag at Passport
- First Data Unit Says It's Untangling Authentication
- First Data Unit Says It's Untangling Authentication
- VeriSign unveils new online identity verification services
- MaterCard test high-tech payments
- eBay Customers Targetted by Credit Card Scam
- eBay Customers Targetted by Credit Card Scam
- eBay Customers Targetted by Credit Card Scam
- [IP] The 20th anniversary of the Internet (fwd)
- Briwn gets creatuve with wireless
- Who owns the methods of E-commerce?
- Web services specs focus on security
- Invisible Ink, E-signatures slow to broadly catch on
- Invisible Ink, E-signatures slow to broadly catch on
- Invisible Ink, E-signatures slow to broadly catch on
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- ssl certs
- ssl certs
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- SSL certs & baby steps
- SSL certs & baby steps (addenda)
- SSL certs & baby steps
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
Identity theft tops Consumer fraud complaints
From: Lynn Wheeler
To: epay@xxxxxxxx
Subject: Identity theft tops Consumer fraud complaints
Date: Wed, 23 Jan 2002 18:58:18 -0700
http://www0.mercurycenter.com/nation/nationwire/docs/1740353l.htm
Posted at 8:09 a.m. PST Wednesday, Jan. 23, 2002
Identity theft tops Consumer fraud complaints
WASHINGTON (Reuters) - Identity theft cemented its dubious status as the
most common type of U.S. consumer fraud complaint in 2001, according to
federal statistics released on Wednesday.
Hijacking of personal information for fraud or theft made up 42 percent of
the 204,000 fraud complaints filed with the Federal Trade Commission (FTC)
last year.
Identity-theft complaints grew from 23 percent of the FTC's Consumer
Sentinel database in 2000 when the problem also topped the list of consumer
fraud headaches.
Scam artists crack Internet databases, intercept mail or bluff their way
past bank tellers and credit bureaus in an attempt to gather Social
Security numbers, bank account numbers and other confidential personal
information.
Armed with that information, they can then apply for credit cards or bank
loans, set up cell phone service or pass bad checks under someone else's
name.
Recent victims include Oprah Winfrey and Tiger Woods.
Complaints about identity theft in 2001 outpaced Internet auctions, which
accounted for 10 percent of consumer gripes; Internet services, at 7
percent; and shop-at-home and catalog offers, which made up 6 percent of
the database.
The FTC statistics coincide with what experts say is increasing awareness
and increasing incidence of identity theft as the Internet makes personal
information more readily accessible.
German federal employees get digital signatures
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: German federal employees get digital signatures
Date: Wed, 23 Jan 2002 11:04:57 -0700
German federal employees get digital signatures
By Rick Perera
(IDG) -- Germany's federal government is introducing electronic signatures
for its employees, a step it hopes will help make the security procedure
generally accepted in the country. More than 200,000 employees of
ministries and agencies will be able to sign electronic documents using a
chip card with an encrypted key, giving them the same legal weight as paper
documents with a handwritten signature, the federal Cabinet said in a
statement Thursday.
The measure builds on legislation making digital signatures legally
binding, which entered force in Germany last year, in concert with an
effort to introduce such laws throughout the European Union.
Employees will be supplied with chip cards and readers between now and
2005, when a broad-ranging project to put all possible government services
online is slated for completion. About a quarter of the 400 targeted
services -- including, for example, bidding for federal procurement
contracts -- will require electronic signatures, the government said. The
one-time setup cost, including hardware, is estimated at ¥60 (US$53) per
employee, with annual maintenance costs of ¥20 to ¥40.
The new decision calls for the development of standards for the securing of
online documents, e-mail, and electronic transactions. The goal is to
implement the standards ISIS (Industrial Signature Interoperability
Specification) and MTT (MailTrusT), still under development with government
funding.
"The federal administration expects that the interoperability standard
ISIS-MTT will quickly establish itself on the market, and that appropriate
products for each application, based on ISIS-MTT, will be available," the
Cabinet decision said.
Some IT professionals were critical of the government for not being more
specific about which technology it intends to use.
The industry association Bitkom (Bundesverband Informationswirtschaft,
Telekommunikation und neue Medien e.V.), while welcoming the decision,
complained that it makes only suggestions and no concrete directions for
implementation.
"After the many rounds of voting not much more remained than a description
of the status quo," the group said in a statement. "The government thus
unfortunately waters down its clear and praiseworthy aim of quickly and
comprehensively outfitting the administration with security technology."
Bitkom called instead for a "citizens' card," with chip and electronic
signature, for all Germans.
Rick Perera is a correspondent for the IDG News Service.
Find this article at:
http://www.cnn.com/2002/TECH/ptech/01/21/german.government.idg/index.html
High-tech Thieves Snatch Data From ATMs (including PINs)
Refed: **, - **, - **, - **, - **, - **, - **
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: High-tech Thieves Snatch Data From ATMs (including PINs)
Date: Wed, 23 Jan 2002 11:02:13 -0700
some previous skimming related postings:
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card
fraud"
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit
cards!
http://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud
(from today's comp.risks)
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use
digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
==================================
http://dailynews.yahoo.com/htx/abc/20020110/bs/atmfraud020110_1.html
Thursday January 10 03:26 PM EST
High-tech Thieves Snatch Data From ATMs
By Paul Eng ABCNEWS.com
Thieves can steal an account number from an ATM or debit card, and secret
pin.
At the corner market, the skim is in the refrigerated milk - and perhaps in
the store's cash-dispensing ATM.
But this particular "skim" isn't good for customers since it involves the
poaching of an unsuspecting consumer's bank card data.
Thieves have found a way to steal not only someone's account number from an
ATM or debit card but also the person's seemingly secret personal
identification number. With this double dose of information, thieves can
electronically rob unsuspecting victims of their cash.
The scam has been reported in New York, Florida, California and points in
Canada.
The cybercrooks' technique is so clandestine that consumers often don't
know that they've become victims until they check their monthly bank
statements - or when checks start to inexplicably "bounce" due to lack of
available funds.
Suddenly Sapped of Cash
Chris Lundie, a 28-year-old market surveillance analyst with a Wall Street
investment firm, was one such victim.
Last month, Lundie and his fiancée checked their bank account online in
preparation to pay their Manhattan apartment rent. But, they noticed two
odd withdrawals - for $500 and $600 - made within hours of each other at
bank ATMs in Flushing, Queens.
"At first we questioned how this happened," says Lundie. "We don't work in
Queens and we've never been to those ATMs."
After calling his bank to stop further activity on the account, Lundie
called his local police precinct and discovered that he was the latest
victim of a high-tech crime ring that may have been targeting automatic
teller machine users for more than a year.
Detectives with New York City Police Department's Special Fraud Unit
wouldn't comment on the "ongoing investigation" into the ring. But
according to a recent report in the New York Post , the thieves may have
stolen as much as $1.5 million. Authorities told the Post they suspected
the scam was the work of the Russian mafia.
Snatching Data Clandestinely
Law enforcement officials did not disclose how the ring operated, but
industry sources gave ABCNEWS a hint at how the ring might have stolen
money from unsuspecting victims.
According to one source, the thieves may have targeted non-bank ATMs - the
stand-alone cash dispensers found at local grocers, bodegas, gas stations,
and shopping mall food courts. The machines are rigged with tiny devices
that can read a debit card's magnetic stripe as it is run through the ATM's
built-in reader. A special "logic board" or cover is placed over the ATM's
keypad and records when users enter their four-digit PIN codes.
Both the card's magnetic data and the user's PIN information are stored in
a separate memory module. The thieves retrieve the memory module and, using
commercially available computer technology, encode the stolen information
onto their own blank cards. These "cloned" debit cards can then be used
with the captured PIN to withdraw money from the victims' accounts using
other ATMs.
Con artists have targeted debit cards and ATMs in the past in a variety of
scams. Most schemes, such as the so-called Lebanese Loop, are fairly
simple.
In that scam, robbers would purposely rig the card slot of the ATM to
physically capture a person's bank card. The scammer, posing as a good
Samaritan, would then suggest that the victim repeatedly enter their secret
PIN code in order to recover the stuck card from the machine. When the
effort fails, the victim often walks away - leaving the con artist to
retrieve the card and use it with the now-disclosed PIN code.
ATMs: Tempting Targets
Experts believe that the thieves may have targeted non-bank ATMs for
several reasons.
For one, non-bank ATMs are typically owned and maintained by independent
operators who may not know that such skimming devices are being added and
removed from their cash dispensers.
Most of these stand-alone ATMs also lack built-in surveillance cameras and
are placed in locations that aren't monitored closely, leaving police with
very little evidence to work with during their investigations.
Crafting Countermeasures
Rob Evans, marketing director for NCR, a leading ATM supplier, says the
industry has developed several technologies that can defeat these
clandestine card skimming setups. ATMs supplied to NCR's bank customers,
for example, can be equipped with enhanced card readers that can scramble
the card's data as it's being read.
"When a user puts his card in, it jitters the electronic signals so it
can't be picked up by a nearby illegal card reader," says Evans.
The banking industry is also looking into other high-tech measures such as
using software encryption and so-called smart cards that store data on
hard-to-duplicate microprocessors.
But industry officials such as Evans admits that it's a tough race against
cybercriminals. "You do what you can to make the ATM as unappealing as you
can to folks that want to use it for criminal purpose," says Evans. But as
ATMs - especially stand-alone versions - proliferate, "The bad guys are
going to keep coming at these things as quickly as they can."
Enduring Losses and Lessons
And that's disheartening news for both consumers and the financial
institutions that absorb the estimated billions of dollars annually lost to
bank card fraud.
Citigroup and J.P. Morgan & Chase - two of the largest institutions
reportedly stung hard by this latest ring of thieves - wouldn't comment on
the amount lost in the latest scam. But Mark Rodgers, spokesman for
Citigroup, says, "No [customer] funds were at risk and we regret any
inconvenience that may have resulted [from this crime]." Rodgers also says,
"We've worked with customers to resolve the issues on their account."
And that's good news for consumers such as Lundie. His undisclosed
financial institution restored the stolen funds to his account in about two
weeks. After all, "$1,100 is a lot of money living in [New York] City," he
says.
Still, he and his fiancée are keeping a close eye on their new account. And
he says: "I definitely make more of an attempt to use a bank ATM."
[ISN] Credit Card Scam
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: [ISN] Credit Card Scam
Date: Wed, 23 Jan 2002 10:59:47 -0700
Forwarded from: Joe Penders <jpenders@xxxxxxxx>
Check out these sites:
http://www.ebay.com-order.fw.nu (fake ebay site ?)
same page again here
http://members.aol.com/cullcrow/
All wanting more info than anybody every needs over the net. HTML is
also encrypted so can't tell where its really going to.
Ebay, AOL and FBI all informed on 19 Jan, 2002 but page is still up
and collecting
I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
Date: Wed, 23 Jan 2002 11:07:22 -0700
significant part of x9.84 and related standards have to do with secrecy
needed to support biometrics.
Part of the issue has to do with whether it is a closed system or an open
system. In a purely closed system .... there are trusted secured sensors
that typically have a great deal of armoring (and many other security
infrastructures, supposedly making it impossible to generate a transaction
w/o using one of the heavily fortified secure fingerprint readers). If the
fingerprint reader armoring and other security measures can be trusted and
that a fingerprint is never needed in any other but the one and only,
truely closed system .... then it sort-of works.
The problem is translating to an open system and multiple closed systems
.... then it is the same problem as PINs/PASSWORDS ... which preclude using
the same value in more than one security domain (otherwise there is a
potential that institutions can impersonate you with other organizations or
bad-guys can evesdrop and impersonate you by injecting fraudulent
transactions into open networks. As stated many other times ... when
PIN/PASSWORD becomes compromised it is relatively straight-forward to issue
a new one .... when a similar compromise occurs with a fingerprint (or
other biometric) it is somewhat more difficult to issue new biometrics.
==================================================================
Date Tue, 22 Jan 2002 13:41:18 -0800
To cryptography@xxxxxxxx
From Bill Frantz <frantz@xxxxxxxx>
Subject Re: I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
At 3:50 PM -0800 1/19/02, R. A. Hettinga quoted Dorothy Denning:
>My response is, "No." A good biometrics system should not depend on
>secrecy. ...
>
>What makes biometrics successful is not secrecy, but rather the
>ability to determine "liveness." ..
>
>The same principle applies in the digital world. Your biometric
>prints need not be kept secret, but the validation process must check
>for liveness of the readings. Many biometric products work this way.
>For instance, the Sensar iris-recognition system from Iridian
>Technologies (www.iridiantech.com) looks for the "hippus
>movement"-the constant shifting and pulse that takes place in the
>eye. The liveness test ensures that the reading is fresh, so an
>adversary can't replay a previously recorded reading. ...
It seems that this situation is true only if you can trust the device
reading the biometric data. In the case an ATM, or a building entry
system, this trust is reasonable.
>Testing liveness is reasonably straightforward if the biometrics
>reader senses appropriate characteristics and is tightly coupled with
>the validation process and database of biometric prints. If the
>reader is remote from the validation process and database, encryption
>can be used to provide a secure path connecting the components. The
>encryption system, obviously, should protect against replays.
However, encryption will buy you nothing if the biometric reading device is
compromised or faked. If an attacker can take the freshness challenge from
the other end of the connection, along with your public biometric data (say
an iris pattern), then it can simulate an uncompromised device in
responding with your "credentials".
Now there may be enough physical security in many places to be able to
place reasonable trust in the devices which are installed there. However,
it strains my belief that we will be able to trust the devices in every
Internet Cafe in the world.
>Encryption can also be used to pass credentials from one system to
>another. For example, once my smart card validates my fingerprint, it
>may use a private signature key on the card to authenticate me to
>services that use my public key for authentication.
Unless your smart card has a fingerprint reader, it must trust the finger
print reader it uses. An attacker can feed your smart card your public
finger print data, responding to any freshness challenge your card may use,
and get your card to authenticate someone else as you. It seems to me in
this scheme, you must protect your smart card in much the same manner as
you protect your credit cards. (Note that the smart card scheme is better
than the credit card because, the secret data is not transmitted over a
network like the credit card number. Modulo breaking the smart card
protection, an attacker will need physical access to the card.)
Cheers - Bill
-------------------------------------------------------------------------
Bill Frantz | The principal effect of| Periwinkle -- Consulting
(408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@xxxxxxxx | fair use. | Los Gatos, CA 95032, USA
==============================================================
==============================================================
Date Fri, 18 Jan 2002 14:30:09 -0500
From Matthew Gaylor <freematt@xxxxxxxx>
Subject I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
<http://www.infosecuritymag.com/articles/january01/columns_logoff.shtml>
January 2001
SECURITY STRATEGIES FOR E-COMPANIES
WHY I LOVE BIOMETRICS
It is "liveness," not secrecy, that counts.
BY DOROTHY E. DENNING
I'm a big fan of biometrics. I'm tired of trying to remember umpteen
zillion account names and passwords in order to use the computers in
my office, browse my favorite Web sites and update the Web sites I
manage. I long for the day when computers will automatically
recognize me and handle the identification and authentication
function with little effort on my part.
I make lots of security-related presentations, and when I tell all of
this to an audience, someone inevitably asks, "What happens if
someone snatches the biometric print used to validate you? Couldn't
they just replay your biometric and pretend to be you? And wouldn't
that make your biometric useless?"
My response is, "No." A good biometrics system should not depend on
secrecy. To understand why, think about how biometrics work in the
physical world. Your friends and colleagues authenticate you by
recognizing your face, voice, eyes, hands and so on. None of this is
secret. Anyone who interacts with you sees these characteristics.
Even your fingerprints can be lifted from surfaces.
What makes biometrics successful is not secrecy, but rather the
ability to determine "liveness." I can easily distinguish the living,
flesh-and-blood you from a statue or photograph of you, or even
someone wearing a costume and mask that looks like you. If I don't
know you well, I might be fooled by a lookalike, but in the
non-Mission Impossible real world, the system generally works. If I
don't know you at all, I might ask for a photo ID. But I would use
such a photo only because I lack knowledge of your appearance. I
authenticate you by comparing your live face against the photo, not
by comparing one photo against another. For further proof, I may
watch you sign your name and compare the live signature against the
one on your ID card.
The same principle applies in the digital world. Your biometric
prints need not be kept secret, but the validation process must check
for liveness of the readings. Many biometric products work this way.
For instance, the Sensar iris-recognition system from Iridian
Technologies (www.iridiantech.com) looks for the "hippus
movement"-the constant shifting and pulse that takes place in the
eye. The liveness test ensures that the reading is fresh, so an
adversary can't replay a previously recorded reading.
This is the beauty of biometrics. Other forms of user
authentication-including passwords, tokens and encryption-all depend
on protecting a secret or device from theft. Once that secret or
device is compromised, the system fails until a new one is
established. Moreover, these methods typically require users to hold
a different secret with each and every device or service they use,
thereby burdening the user. Imagine if every time you greeted a
friend or colleague, you had to use a new secret handshake!
Testing liveness is reasonably straightforward if the biometrics
reader senses appropriate characteristics and is tightly coupled with
the validation process and database of biometric prints. If the
reader is remote from the validation process and database, encryption
can be used to provide a secure path connecting the components. The
encryption system, obviously, should protect against replays.
Encryption can also be used to pass credentials from one system to
another. For example, once my smart card validates my fingerprint, it
may use a private signature key on the card to authenticate me to
services that use my public key for authentication. Of course, the
encryption system itself requires secret keys, but in this context,
the secrets may be less prone to compromise because they don't have
to be known by humans.
Biometrics can be applied not only with human users, but also with
locations. For example, technology from CyberLocator
(www.cyberlocator.com) authenticates geodetic location by capturing a
location signature from GPS signals in a way that ensures liveness.
No secrets are required. One could imagine using biometrics to
authenticate places or anything else with distinguishing
characteristics that exhibit a form of liveness.
In addition to liveness, a biometrics system also depends on
uniqueness. Otherwise, it may be subject to false accepts or rejects.
Some forms of biometrics are better than others in this regard-iris
recognition being one of the best.
Questions about privacy abuse aside, biometrics is likely to be the
way of the future. I can't wait to get rid of my gazillion passwords.
__________________________________________________________________________
Distributed without profit to those who have expressed a prior interest in
receiving the included information for research and educational purposes.
---
Subscribe to Freematt's Alerts: Pro-Individual Rights Issues
Send a blank message to: freematt@xxxxxxxx with the words subscribe FA
on the subject line. List is private and moderated (7-30 messages per week)
Matthew Gaylor, (614) 313-5722 ICQ: 106212065 Archived at
http://groups.yahoo.com/group/fa/
credit card & gift card fraud (from today's comp.risks)
Refed: **, - **, - **, - **, - **, - **, - **
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: credit card & gift card fraud (from today's comp.risks).
Date: Wed, 23 Jan 2002 11:01:28 -0700
other postings and recent info from comp.risks:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore3 Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/2002.html#19 Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus
experienced veterans ( was Re: The demise of compa
http://www.garlic.com/~lynn/2002.html#35 Buffer overflow
http://www.garlic.com/~lynn/2002.html#37 Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
========================================================
Date Mon, 07 Jan 2002 20:07:25 -0500
From David Farber <dave@xxxxxxxx>
Subject Credit-card cloners' $1B scam
Homemade machines costing about $50 are being used to read credit-card
mag-stripes, without having to steal the cards. The information is then
e-mailed abroad, where cloned cards are fabricated. This has become a
billion-dollar-a-year enterprise.
[PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists,
mobsters in on hacking racket, by William Sherman, NY Daily News
http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp]
[The gadget was first demonstrated in maybe 1960s at Caltech as part of a
demo on how poor the mag-striped credit cards were. In spite of that,
they
won. Dave]
------------------------------
Date Sat, 29 Dec 2001 09:59:00 -0600
From Tim Christman <tjc@xxxxxxxx>
Subject Mag-stripes on retail gift cards
Here's a link to an article on MSNBC that I found interesting --
http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1
Many retailers are replacing paper gift certificates with small
plastic cards containing magnetic stripes, similar to credit cards.
Ideally, the purchase of a gift card would result in a database being
updated to reflect the balance associated with the card's unique
account number.
Some retailers are using sequential account numbers and have no
provisions to protect against a thief using a mag-stripe reader/writer
to re-program a stolen card or small denomination card so that it
matches the account number of a larger valued card purchased by
someone else. Many retailers even provide a convenient 1-800 number
so that the thief, knowing many valid account numbers, can "shop" for
a card of significantly greater value.
The RISK: A form of fraud, difficult to trace, involving a minimal
investment in equipment by the thief. Also note that the thief only
requires the ability to query the back-end database (through the
toll-free number), not the ability to manipulate the records. Perhaps
more ominously, the risk is angry family members who find a zero
balance on their gift cards!
Solutions: One retailer, mentioned in the article, uses optical
bar-coding which can't be re-encoded without defacing the card.
Another follows a technique used by many credit card companies --
extra check digits are included in the mag-stripe that are not visible
on the face of the card. It seems astounding that this isn't being
done by all.
UNCITRAL Electronic Contracting Project
Refed: **, - **, - **, - **
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: UNCITRAL Electronic Contracting Project
Date: Wed, 23 Jan 2002 11:18:27 -0700
From Richard L. Field [mailto:field@XXXXXXXX]
Sent Tuesday, January 01, 2002 7:49 PM
To DIGSIG@xxxxxxxx
Subject UNCITRAL Electronic Contracting project
To: Interested persons
The Electronic Commerce Working Group of the United Nations Commission
on International Trade Law (UNCITRAL) will next be meeting at the UN
in New York on March 11-15, 2002. In preparation for that meeting,
the UNCITRAL Secretariat has prepared a Note (A/CN.9WG.IV/WP.95)
entitled "Electronic contracting: provisions for a draft convention".
It is available at
http://www.uncitral.org/english/workinggroups/wg_ec/wp-95e.pdf
(39pages).
This is the first of the next set of projects of the UNCITRAL
E-Commerce Working Group, now that the UNCITRAL Model Law on
Electronic Signatures has been completed. The new project deals with
electronic contracting considered from the perspective of the United
Nations Convention on Contracts for the International Sale of Goods
(aka the UN Sales Convention or the Vienna Sales Convention). It is
currently limited in scope to contract formation in electronic
commerce. The WP.95 Note examines issues such as party location and
when a contract should be considered "international" in scope and
therefore subject to an international convention, offer and
acceptance, consent, receipt and dispatch, automated computer systems,
treatment of mistake and error, system requirements, and form
requirements.
Bill Luddy has offered to set up a listserv and web site at Rensselaer
Polytechnic Institute for those with an interest in keeping up with
and commenting on this project. To subscribe to the listserv, please
send an email (with your name) to Professor Luddy at <wjl@xxxxxxxx>.
The listserv will also be used to announce any telephone conference
calls to be held in preparation for the meeting.
-----------------------------
Richard L. Field, Esq.
755 Anderson Avenue, #4A
Cliffside Park, NJ 07010 USA
ph/fax: +1 201-941-8015
field@xxxxxxxx
-----------------------------
FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn.wheeler@xxxxxxxx
To: epay@xxxxxxxx
Subject: FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
Date: Wed, 23 Jan 2002 11:09:49 -0700
some recent FSTC announcements
From Zach Tumin, Executive Director
Financial Services Technology Consortium
To FSTC's Industry Friends and Colleagues
FSTC is pleased to announce its new quarterly bulletin, FSTC Exchange. You
can find the full issue at
http://www.fstc.org/news/newsletter/2002-01
Highlights are below. We look forward to working with members, associates
and friends in 2002. A happy, healthy new year to all.
Zach Tumin
Executive Director
FSTC
-----------------------------------------------------------
FSTC Exchange / Winter 2002
The quarterly newsletter of the Financial Services Technology Consortium
-----------------------------------------------------------
Director s Commentary
New FSTC Initiatives in Mobile Financial Services
Validating WAP for Secure Mobile Financial Transactions
Prototyping the Secure Mobile Financial Services Infrastructure
Enabling FAST Authentication for Aggregation Services
Universal Value eXchange (UVX)
Automated Imaged Signature Comparison (AISC)
Meridien Research Partnership
New Board Members Named
FSTC Discussion Forum
What s Coming Up in 2002
-----------------------------------------------------------
Director s Commentary
As individuals and organizations we should champion the financial services
industry. We should pool our collective wisdom, working together to build
out the national and global infrastructures over which the nation's
financial services providers conduct business, and customers access
information and financial resources.
http://www.fstc.org/news/newsletter/2002-01/article01.cfm
New FSTC Initiatives in Mobile Financial Services
IDC predicts that by 2004 the number of Internet-enabled mobile devices
will exceed that of personal computers. Given the growing importance of
mobile technology to the financial services industry, FSTC has begun two
projects to address the needs of members in delivering mobile financial
services.
http://www.fstc.org/news/newsletter/2002-01/article02.cfm
Validating WAP for Secure Mobile Financial Transactions
Together with FSTC members and WAP technology and service providers, FSTC
is now launching a three-month pilot project to develop and test an
end-to-end wireless security environment for financial transactions, based
on the emerging WAP 1.2.1/2.0 specifications. All FSTC members are invited
to participate.
http://www.fstc.org/news/newsletter/2002-01/article03.cfm
Prototyping the Secure Mobile Financial Services Infrastructure
As financial institutions move to the mobile platform, interoperability
between products and across service providers will be critical. To assure
that member interoperability needs are met, FSTC is currently developing a
submission to National Institute of Standards and Technology for a
significant mobile financial services research and development initiative.
http://www.fstc.org/news/newsletter/2002-01/article04.cfm
Enabling FAST Authentication for Aggregation Services
How can aggregation providers authenticate themselves to financial
institutions on behalf of financial institution customers? The FSTC FAST
authentication protocol will soon be piloted to provide an answer. More
information is available to members interested in reviewing the proposal or
participating in the pilot.
http://www.fstc.org/news/newsletter/2002-01/article05.cfm
Universal Value eXchange (UVX)
FSTC is undertaking a development initiative to create a Universal Value
eXchange (UVX) architecture and proof of concept. The framework will
consolidate and normalize interfaces between legacy payment systems, and
connect existing payments systems to new payment services. The project is
in the formative stages.
http://www.fstc.org/news/newsletter/2002-01/article06.cfm
Automated Imaged Signature Comparison (AISC)
Can state-of-the-art image recognition technology be used to detect
fraudulent check signatures? To find out, FSTC has engaged the
International Biometrics Group (IBG) to assemble image comparison software
from leading technology providers, develop test metrics, and exercise each
system in a controlled laboratory environment.
http://www.fstc.org/news/newsletter/2002-01/article07.cfm
Meridien Research Partnership
A new collaborative partnership with Meridien Research gives FSTC members
preferred access to Meridien s expertise in global financial services
technology. FSTC and Meridien will share expertise on strategic technology
investments, institute interactive forums to promote dialogue, and publish
research on topics of joint interest.
http://www.fstc.org/news/newsletter/2002-01/article08.cfm
New FSTC Board Members Named
C. Grant Cole, senior vice president at Bank of America, Daniel R.
Vermeire, chief technology officer at Huntington Banks, Lou Riehl, senior
vice president at JPMorganChase Bank, and Julian Wachs, enterprise CIO for
eCommerce technology and senior vice president at First Union/Wachovia
Corporation, have all joined the FSTC
Board.
http://www.fstc.org/news/newsletter/2002-01/article09.cfm
FSTC Discussion Forum
FSTC is introducing online discussion forums in which members can exchange
ideas, explore opportunities for collaboration, and turn ideas into action.
Complementing the discussion forums will be monthly live events where
members can exchange ideas about the latest in financial services
technology.
http://www.fstc.org/news/newsletter/2002-01/article10.cfm
What s Coming Up In 2002
The FSTC 2002 Winter Meeting is schedule for Feb. 27-28& FSTC will be
moving to expand its principal membership& launching a new series of
side-by-side research initiatives& launching a series of validation tests
for specifications for financial transactions brought forward by other
bodies& doing rapid prototyping of new authentication technologies&and
more.
http://www.fstc.org/news/newsletter/2002-01/article11.cfm
-----------------------------------------------------------
About FSTC
FSTC, the Financial Services Technology Consortium, is a not-for-profit
research and development organization comprised of banks, industry
partners, financial service providers, technology companies, academic
institutions, and government agencies.
FSTC sponsors collaborative technology development--pilots,
proofs-of-concept, tests, and demonstrations--supported by member financial
institutions and technology companies. Its aim is to bring forward
interoperable, open-standard technologies that provide critical
infrastructures for the financial services industry. FSTC members use these
same infrastructures to bring their own products and services to the market
place, stimulating customer interest and earning consumer confidence, and
enhancing the position of financial services institutions in the
marketplace.
About FSTC Exchange
FSTC Exchange is the official quarterly newsletter of the Financial
Services Technology Consortium.
It is available online at
http://www.fstc.org/news/newsletter/
It is available in PDF format at
http://www.fstc.org/news/newsletter/download.cfm
If you would like to receive this newsletter at no cost, please visit the
FSTC Web site at
http://www.fstc.org/news/newsletter/subscribe.cfm. For FSTC
membership information or general correspondence, please contact us at
fstcadmin@xxxxxxxx.
Copyright Financial Services Technology Consortium, 2002. All rights
reserved.
To FSTC Members, Associates and Friends
From Zach Tumin, Executive Director
FSTC is pleased to announce the launch of a new wireless security project
to validate the WAP 1.2.1 specification for mobile e-commerce. An FSTC
project team will use live transactions over the Verizon wireless network
to test critical financial transactions -- account balance, funds transfer,
and bill payment. Today, many institutions do not support these
transactions over wireless because of security concerns.
Our goal is to learn whether end-to-end encryption holds between the device
and the financial institution under the WAP 1.2.1 specification using
dynamic proxy navigation. Test results will be made available to project
participants in May, and will be available to all FSTC members later in the
fall.
FSTC members Bank of America, JPMorgan Chase, and Wells Fargo Bank are
engaged on the project team. Verizon, Openwave, 724 Solutions, RIM, Neomar
and Infogard Laboratories will also be participating and playing critical
roles.
Wells Fargo Bank is hosting the project launch session February 6-7 in San
Francisco. Project participation is open to all FSTC members. If you think
your institution or firm might be interested, please contact us quickly.
Project participation fees are frozen until the February 6 launch, at which
time they increase.
The full press release describing this FSTC effort is appended, below.
If you would like to get a copy of the project plan, the project
participation agreement, or see the participation pricing, please contact
Jim Salters, FSTC Manager of Technology Development (jim.salters@xxxxxxxx)
We invite you to participate in this project and look forward to working
together to validate this key specification.
Zach Tumin
_________________________________________________________________
Zachary Tumin
EXECUTIVE DIRECTOR
Financial Services Technology Consortium
401 N. Michigan Avenue, 22nd Floor
Chicago, IL 60611
www.fstc.org
zachary.tumin@xxxxxxxx
V 914-576-7629
F 978-336-8302
==========================================================
FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
Collaborative Three-Month Validation of End-to-End Encryption for Mobile
Financial Transactions to be Completed by May 2002
Project launch session scheduled for February 6th in San Francisco
Chicago ? January 21, 2002 ? Wireless security for mobile financial
transactions is a key technology barrier facing financial institutions,
according to the financial industry research organization Financial
Services Technology Consortium (FSTC). To address the gaps in wireless
security, and to establish a secure, end-to-end financial transaction
infrastructure, FSTC-member financial institutions and technology companies
have launched a collaborative three-month validation test, using real world
transactions to test the encryption aspects of the WAP 1.2.1 mobile
specification, and dynamic proxy navigation.
Sponsoring or participating companies in the WAP encryption test include
7/24 Solutions, Bank of America, InfoGard Laboratories, JPMorganChase Bank,
Neomar, Openwave, RIM, Verizon Wireless, and Wells Fargo Bank. The project
is open to all interested companies to join, with a two-day project launch
session scheduled for February 6-7, at Wells Fargo Bank in San Francisco.
"Financial institutions need to validate that they can communicate
privately and securely with their mobile customers," said Zachary Tumin,
Executive Director of FSTC. "This test will not be simulated, but use live
airwaves, real mobile devices, and real software products to test financial
transactions, such as bill payment, fund transfers, and account balance
inquiries. Using real applications we will be able to observe, in real
time, if the encryption holds, end-to-end, for sensitive financial
transactions. Until this test is complete, banks will be hesitant to
introduce next generation wireless financial applications for mobile
customers."
Results from the study will be available to project participants in May
2002, subsequently to non-participating FSTC members, and then to the
public in the autumn of 2002.
"Without this collaborative effort each FSTC member bank would have to
duplicate the effort and cost to conduct the same test to certify the new
WAP specifications," said Kathy DeWit, Executive Vice President of Payment
Strategies at Wells Fargo Bank. "Throughout the year, FSTC members
regularly pool their technical resources and funds to solve shared
problems. Collaboration makes our results more representative of the
industry, and much less expensive, than going alone."
This year, FSTC plans to conduct a series of side-by-side technology tests
and proofs-of-concept projects to validate emerging technologies geared
toward financial services. Currently, FSTC is comparing automated imaged
signature verification technologies that are used to reduce paper check
fraud. The objective is to determine if specific technology actually
performs as claimed and whether it can be implemented. All FSTC project
participants gain early and exclusive access to test results.
Actual testing of encryption under the WAP 1.2.1 specification will be
performed by InfoGard Laboratories of San Luis Obispo, California, with
testing overseen by FSTC. InfoGard is an accredited FIPS 140-1 test
laboratory under the National Institute Standards and Technology (NIST)
NVLAP program. Results will be conclusive.
Organizations interested in project participation or attending the project
launch session should contact Jim Salters at jim.salters@xxxxxxxx.
About FSTC
FSTC is a financial industry research organization comprised of banks,
financial service firms, industry partners, national laboratories,
universities and government agencies. Its goal is to bring forward
interoperable, open-standard technologies for the financial services
industry that makes possible new products and services. For more
information, contact FSTC Headquarters at +1 (312) 527 6724 or visit
http://www.fstc.org/.
Contact
Zachary Tumin
FSTC Executive Director
zachary.tumin@xxxxxxxx
+1 (914) 576 7629
To All FSTC Members
From Zach Tumin, Executive Director
FSTC Live Chat Event Reminder
Topic New Authentication Services What's the Financial Industry's Role?
Guest Chuck Wade, Internet Payments and Security Consultant
Time Wed., Jan. 23, 1200-100pm EST
Whitepaper Download
"New Authentication Services", By Chuck Wade
https://webworkzone.com/FSTCForums/dispatch.cgi/TopicOfTheMonth/folderFrame/10001
6/
Live Event
http://www.fstc.org/discussions/forums.cfm
Click on Live Event
If you have forgotten your username or password, check the FSTC Web site at
http://fstc.org/forgotPswd.cfm
E-mail questions to the event facilitator
live.chat@xxxxxxxx
Continuing the Dialogue on New Authentication Services
From: Lynn Wheeler
Date: 02/04/2002 08:59 AM
To: epay@xxxxxxxx
Subject: Continuing the Dialogue on New Authentication Services
zarchary.tumin@xxxxxxxx on 2/4/2002 7:26 am wrote:
To FSTC Members, Associates and Friends
From Zach Tumin, FSTC Executive Director
Subject Continuing the Dialogue on New Authentication Services
Recently, FSTC hosted a one-hour live chat event on new authentication services and the potential threat and opportunities they present to the financial industry. Our guest was Chuck Wade, a noted Internet payments and security consultant. Based on participation and feedback, the event was a great success.
Event Transcript
For those of you missed the live event, a transcript is available upon request. If you would like a copy, let me know via email and I'll forward one along.
Q&A Topics
The interactive Q&A was quite lively and we covered a number of important topics: Will financial institutions adopt Passport? Are there any general-purpose solutions that are lightweight enough for email? Will Liberty Alliance allow consumers to control their own data? What's the government's role in authentication?
Ongoing Discussion
To continue the dialogue on these important questions we have posted the relevant transcript sections as threads in the FSTC discussion forum. You can follow the conversation at:
https://webworkzone.com/FSTCForums/dispatch.cgi/TopicOfTheMonth/folderFrame/100016/
Feel free to add a reply to any of these threads or start your own if you have other authentication topics you would like to explore.
Access to the discussion forum is one of many FSTC member benefits. If you are a FSTC member and have forgotten your username or password, check the FSTC Web site at: http://fstc.org/forgotPswd.cfm.
If you are not yet a member, II urge you to consider joining FSTC now. For more information, visit http://www.fstc.org/membership/
Contact:
Zachary Tumin
FSTC Executive Director
zachary.tumin@xxxxxxxx
+1 (914) 576 7629
InfoSpace Buys ECash Technologies
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/27/2002 11:06 PM
To: epay@xxxxxxxx
Subject: InfoSpace Buys ECash Technologies
http://www.businesswire.com/cgi-bin/cnn-storydisplay.cgi?story=/www/bw/webbox/bw.021902/220500186.htm&textcolor%23000000&linkcolor=000099&vlinkcolor=purple&pre=0&strip=1&nohrule=1¬imestamp=1&noeditor=0&nocontact=0&nobackground=1&story_textcolor%23000000&story_linkcolor=000099&header=%2Fwww%2Fbw%2Finsp%2Finsp_storyheader.shtml&footer=%2Fwww%2Fbw%2Finsp%2Finsp_storyfooter.shtml&bgcolor=%23343399
BELLEVUE, Wash.--(BUSINESS WIRE)--Feb. 19, 2002--
With acquisition of eCash Technologies' assets, InfoSpace plans to
bring merchants and financial institutions secure e-debit card
processing and online and off-line stored value services such as
pre-paid cards, loyalty programs and gift certificates
InfoSpace, Inc. (Nasdaq:INSP), a provider of wireless and Internet
software and application services, today announced that the Company
has acquired substantially all of the technology and intellectual
property of eCash Technologies, Inc. which include electronic debit
and stored value transaction technologies.
Terms of the deal were not disclosed.
These innovative technologies are built on an intellectual property
portfolio of more than 20 patents issued in the US and
overseas. InfoSpace plans to offer merchants additional payment
mechanisms that are expected to reduce processing costs, while
providing exciting opportunities for merchants to drive new revenue
streams and strengthen their relationships with valued customers.
InfoSpace plans to add electronic debit functionality to its existing
credit card and electronic-check processing services that would give
merchants the ability to accept debit card payments. Through advanced
encryption and digital signature technology, the debit solution is
being designed to be able to authenticate the consumer and merchant,
and authorize the payment via secure protocols developed by leading
debit card associations. In addition, the solution is being designed
to provide consumer identification and real-time verification of
funds, allowing merchants to enjoy the equivalent of a "card present"
transaction without certain of the fraud and charge-back concerns of
"card not present" payments.
In addition, InfoSpace plans to offer merchants stored value coupon,
incentive, loyalty and promotion services that can be redeemed both
online and offline. Stored value programs can be used in a variety of
ways by merchants to lower costs and build customer loyalty. These
programs allow cash, points, etc. to be placed on a physical card or
in an online account that can be redeemed for goods and services at
the point of sale by the customer. For merchants with existing
paper-based loyalty programs such as pre-paid cards and gift
certificates, InfoSpace plans to develop these new technologies to
extend these programs into the online world, enabling these programs
to be redeemed interchangeably online and offline. InfoSpace plans to
offer these services to its broad network of merchant resellers
including leading financial institutions and other merchant service
providers.
In the fourth quarter of 2001, InfoSpace Merchant services processed
more than $1 billion in transactions, up from $700 million reported in
the previous quarter. The total number of transactions processed was
more than 12 million, up from 9 million reported in the third quarter.
"Merchants today want innovative payment solutions giving them higher
cost savings and increased fraud protection for both online and
offline transactions. In addition, consumers want secure and
convenient payment solutions that can be used both online and
offline," said Prakash Kondepudi, InfoSpace executive vice president,
merchant. "The acquisition of innovative technologies from eCash will
enhance our payment technologies offered through leading merchant
service providers and financial institutions with stored value payment
services that address the needs of today's merchant businesses."
About InfoSpace, Inc.
InfoSpace, Inc. (Nasdaq:INSP) provides wireless and Internet software
and application services. The Company develops software technologies
that enable customers to efficiently offer a broad array of
network-based services under their own brand to any device.
This release contains forward-looking statements relating to the
development of InfoSpace, Inc.'s products and services and future
operating results, including statements regarding InfoSpace's purchase
of assets from eCash Technologies, Inc., that are subject to certain
risks and uncertainties that could cause actual results to differ
materially from those projected. The words "believe," "expect,"
"intend," "anticipate," variations of such words, and similar
expressions identify forward-looking statements, but their absence
does not mean that the statement is not forward-looking. These
statements are not guarantees of future performance and are subject to
certain risks, uncertainties and assumptions that are difficult to
predict. Factors that could affect InfoSpace's actual results include
the progress and costs of the development of our products and services
and the timing of market acceptance of those products and services. A
more detailed description of certain factors that could affect actual
results include, but are not limited to, those discussed in
InfoSpace's Annual Report on Form 10-K, in the section entitled
"Factors Affecting Our Operating Results, Business Prospects and
Market Price of Stock." Readers are cautioned not to place undue
reliance on these forward-looking statements, which speak only as of
the date of this release. InfoSpace undertakes no obligation to update
publicly any forward-looking statements to reflect new information,
events or circumstances after the date of this release or to reflect
the occurrence of unanticipated events.
--30--cla/se
CONTACT: InfoSpace, Inc.
Adam Whinston, 425/201-8946
adam.whinston@xxxxxxxx
Working Group Cardholder Authentication and ICC Cards
From: Lynn Wheeler
Date: 02/27/2002 11:08 PM
To: epay@xxxxxxxx
Subject: Working Group Cardholder Authentication and ICC Cards
note that this somwhat overlaps X9.59 since X9.59 used digital
signatures for "account" holder (which has a mapping to iso 8583
payment "card") financial transaction authentication.
x9@xxxxxxxx on 2/26/2002 3:59 pm wrote:
[This message was automatically generated by X9 Forum]
There is 1 new document, TG-3 March 2002, in the X9F6 - Working Group
Cardholder Authentication and ICC Cards committee.
Forum: X9F6 - Working Group Cardholder Authentication and ICC Cards
Folder: 2002-03 March 2002 Meeting - Gulfport, MS
Entry: TG-3 March 2002
From: Steve Case
Date: 02/26/2002
more on factoring breakthrough?
From: Lynn Wheeler
Date: 02/27/2002 11:08 PM
To: epay@xxxxxxxx
Subject: more on factoring breakthrough?
http://slashdot.org/articles/02/02/26/179206.shtml?tid=93
Smartcard security (& PKI systemic risk) thread in sci.crypt n.g
Refed: **, - **, - **
From: Lynn Wheeler
Date: 02/28/2002 10:26 PM
To: epay@xxxxxxxx
Subject: Smartcard security (& PKI systemic risk) thread in sci.crypt n.g.
http://www.garlic.com/~lynn/2002c.html#7
Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)
From: Lynn Wheeler
Date: 02/28/2002 10:26 PM
To: epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)
ietf itrade working group
http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-spec-02.txt
Electronic Commerce Modeling Language (ECML):
Version 2 Specification
<draft-ietf-trade-ecml2-spec-02.txt>
Abstract
Electronic commerce frequently requires a substantial exchange of
information in order to complete a purchase or other transaction,
especially the first time the parties communicate. A standard set of
hierarchicly organized payment related information fields in an XML
syntax are defined as the second version of an Electronic Commerce
Modeling Language (ECML) so that this task can be more easily
automated, for example by wallet software.
META Report: Smart Moves With Smart Cards
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/01/2002 06:31 AM
To: epay@xxxxxxxx
Subject: META Report: Smart Moves With Smart Cards
http://itmanagement.earthweb.com/it_res/article/0,,3031_981861,00.html
Summary: Stronger authentication will supplement simple password
approaches (2002-04), but infrastructure limitations will impede smart
card adoption until 2003, and biometrics will remain niche through
2005. Privacy regulation (e.g., EU and Australian laws, GLBA, HIPAA)
will focus attention on encryption of information at the data, file,
database, and transport levels in 2002. By 2004/05, regulations will
extend to numerous industries, and the concurrent maturity and
transparency of PKI components (such as embedded in NOS, directories,
and file systems) by 2006 will accelerate widespread use of
encryption. Fine-grained authorization will remain an application play
through 2005, though coarse-grained authorization will become more
centralized throughout 2002/03.
Worker Accused of Selling Colleagues' ID's Online (credit card scam)
Refed: **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: Worker Accused of Selling Colleagues' ID's Online (credit card scam)
http://www.nytimes.com/2002/03/02/technology/02INTE.html?todaysheadlines=&pagewanted=print
March 2, 2002
Worker Accused of Selling Colleagues' ID's Online
By JACOB H. FRIES
former employee of the Prudential Insurance Company was arrested
yesterday and charged with stealing the identities of colleagues from
a database containing 60,000 names and selling some of them over the
Internet as part of a credit card scam, federal prosecutors in
Brooklyn announced.
While working in the tax department at Prudential, the former
employee, Donald Matthew McNeese of Callahan, Fla., stole the database
of personnel records, making it one of the largest potential
identity-theft cases ever, said Jim Walden, the assistant United
States attorney prosecuting the case for the Eastern District of New
York. Mr. Walden would not specify how many people had money stolen in
the scam.
Investigators in New York had been tracking Mr. McNeese for two years,
after a detective in Brooklyn went online and noticed that Mr. McNeese
had posted a message on an electronic bulletin board. In the message,
Mr. McNeese announced that he had thousands of names and Social
Security numbers for sale, according to the criminal complaint.
Investigators said they believed that Mr. McNeese also co-opted
personal information at another company, but would not provide
details, citing a continuing investigation.
Mr. McNeese, who turned 30 yesterday, was arrested at his house in
Florida and is awaiting arraignment in Jacksonville, Fla., on charges
of identity theft, credit fraud and money laundering, the authorities
said. During his arrest, prosecutors said, he admitted taking the
database when he worked at Prudential's Jacksonville office in
2000. During a search of his house, investigators seized a computer, a
shotgun with a silencer and fake federal identification.
Mr. Walden, head of the Eastern District's computer crimes and
intellectual property section, said he expected Mr. McNeese to be
brought to Brooklyn and prosecuted. If convicted, Mr. McNeese could
face 45 years in prison and ordered to pay a $750,000 fine and
restitution to his victims.
On July 21, 2000, the complaint alleges, Mr. McNeese posted a message
soliciting bidders: "Does anyone think this kind of info would be
valuable enough to sell or trade for card numbers? If so, what kind of
price would be fair? Consider that there may be thousands of records
ready for sale."
A detective from the New York Electronic Crimes Task Force replied to
Mr. McNeese by e-mail and indicated that he was interested in buying
the identities for $50 each, the complaint says.
In later messages, the detective wrote that he could arrange a scam in
which fraudulent credit cards were created from stolen identities and
used to transfer money, the complaint says. Mr. McNeese then provided
more identities and a transfer was arranged, according to the
complaint.
In other instances, prosecutors said, Mr. McNeese posted the personal
information of former colleagues on the Internet, free for anyone to
use. One employee had more than $2,000 charged to his credit card,
the complaint alleges. And later, investigators said, the suspect
posted the Visa card number of a former supervisor and about $300 was
stolen.
At the same time, Mr. McNeese created false e-mail addresses and sent
harassing messages to former colleagues, according to the
complaint. At one point, prosecutors believe, Mr. McNeese composed an
incriminating message and made it appear to have been written by his
former boss.
"All this highlights the good and bad of such a free medium like the
Internet," said Mr. Walden, who added that he hoped that this case
would put pressure on Internet companies to shut down sites devoted to
criminal activity.
Robert DeFillippo, a Prudential spokesman, would not discuss
Mr. McNeese's work history at the company. "We've been cooperating
fully in a very active way," Mr. DeFillippo said. "The welfare of our
employees, and that includes their privacy, is of the utmost
importance to us."
Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: Re: Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
posted to internet-payments@xxxxxxxx
anders.rundgren@xxxxxxxx on 3/2/2002 6.56 am wrote:
Hum,
I thought this list was down!
May I take the opportunity to introduce www.orbiscom.com who claim
that they have the solution to secure Internet payments. Orbiscom is
supported by major banks in the Nordics and achieves security without
requiring any changes in the current infrastructure! No cryptography,
or fancy merchant SW needed. In the US, First Data seems to support
them as well. The basic concept is to issue short-lived,
value-restricted, one-time credit-cards which means that web-sites
"leaking" credit-card info will be much less harmful.
Regarding 3D Secure, I feel that is flawed as it introduces a brand
-directory in the middle that is redundant, and make the system rigid.
The very same idea (delegated signing), but using Web Services, could
easily have supported all brands, local account-to-account schemes,
etc.
An associated problem is that the banking-industry has failed to
introduce an organizational-level PKI which is extremely needed for
their client organizations for everything from acquiring credit card
money, to sending invoices to their customers' Internet-banks.
W.o. such a scheme, most of these new efforts will just be too hard to
become ubiquitous. SET was extreme in requiring merchants to be a
part of a credit-card-brand-PKI which is (in retrospect), simply
ridiculous, as a merchant may support many brands, roles, and
activities with respect to FIs.
BTW, using 3D Secure principles (not the current draft), there is no
requirement for clients to have an EMV-resource, but (preferably) a
PKI-resource identifying the client rather than his/her account. If
EMV has no clear use on the net, will it ever make it in the physical
world? I doubt it.
So maybe Orbiscom will really take this market although I remain
skeptic as the winner may very well be status quo. As usual :-(.
cheers,
Anders Rundgren
----- Original Message -----
From: Brent Clark
To: internet-payments@xxxxxxxx
Sent: Saturday, March 02, 2002 06:07
Subject: Visa 3-D Secure vs MasterCard SPA Whitepaper
GPayments' has just been released its latest whitepaper entitled:
"Visa 3-D Secure vs MasterCard SPA: A Comparison of online
authentication standards"
Visa 3-D Secure ("Verified by Visa") and MasterCard SPA are two new
online authentication standards from Visa and MasterCard designed to
protect online payment transactions with a password/PIN. These
initiatives are aimed at reducing the incidence of online credit card
fraud.
This whitepaper compare the standards head to head examining them from
the perspectives of cardholders, issuers, merchants and acquirers. It
also compares the standards from both a general architecture and a
security architecture perspective. The whitepaper can be accessed at
http://www.gpayments.com/pdfs/GPayments_3-D_vs_SPA_Whitepaper.pdf
GPayments is focused on authentication and payment solutions for
Internet transactions. GPayments has a full ePayments product suite
including issuer authentication systems, cardholder applets, internet
payment gateways and merchant authentication plug-ins. GPayments is a
founding member of the Visa 3-D Secure Forum and a licensed MasterCard
SPA implementer.
Regards,
Brent Clark
VP Business Strategy
GPayments Pty Ltd
www.GPayments.com
PO Box 1622
Warriewood NSW 2102 AUSTRALIA
Telephone: +61 2 9913 3088
Facsimile: +61 2 9913 3077
FC: European Commission considers mandatory digital rights management
From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: FC: European Commission considers mandatory digital rights management
Date: Sat, 2 Mar 2002 12:23:13 -0500
From: Declan McCullagh <declan@xxxxxxxx>
To: politech@xxxxxxxx
Subject: FC: European Commission considers mandatory digital rights management
As the U.S. Congress weighs mandatory digital rights management, the
European Commission is also looking into the topic. A 43-page EC
study of digital rights management gives a nod to fair use and privacy
-- and then says DRM schemes are not only inevitable but a fabulous idea.
A key excerpt from the study says the EC "should continue to encourage
all players to develop operational, open and interoperable DRM
solutions and to deploy them rapidly." (Apparently the EC has been
funding such schemes for the last decade.)
I've placed the EC study here in PDF form (thanks, Michael):
http://www.politechbot.com/docs/european.commission.drm.030202.pdf
-Declan
----- Forwarded message from Michael Kleinhenz <kleinhenz@xxxxxxxx>
From: Michael Kleinhenz <kleinhenz@xxxxxxxx>
Subject: European Commission enforces DRM systems
To: declan@xxxxxxxx
Date: Sat, 02 Mar 2002 10:33:59 -0500
Hi Declan,
maybe something for your list:
Yesterday I was at a workshop of the European Commision on Digital
Rights Management Systems. I held a talk about the weaknesses of DRMs
and the chances of Open Content like business models. Most of the
about 100 people attending the workshop were representatives of the
content industry or manufacturers of DRM systems. Therefore my talk
was not really liked by them (the usual "Open Source is like stealing"
stuff).
More interesting is, that my impression of this workshop is,
that
1. The EC will continue to support the use and implementation of DRM
systems on a broad scale.
2. Their recent directive on that topic (2001/29/EC) that has to be
implemented by the member states by the end of the year will result
in a SSSCA like legislation.
3. From the proceedings and my personal conversation
with some of the participants, I believe that most of the content
providers have not realized the facts: many people at the
workshop have talked about systems like Napster, but I think too few
people had the actual technological advancement in mind when talking
of such services. I was the only one to emphasize the implications
from things like Freenet which I think is unstoppable, no matter
what..
In result, I was scared by two things: how the workshop was compiled
by the EC (95% content industry, 5% consumer rights organizations) and
the fact that many people there were so naive in terms of DRMs, their
implications and their implementations. Example: everyone was talking
about a common standard for DRM systems to support many platforms, but
no one was talking about the implications of (software)patents on it.
Attached you can find a Commission staff working paper on Digital
Rights that may be interesting as well...
Thanks,
Michael
--
Michael Kleinhenz LinuxTag 2002 - Europes largest Linux Expo
kleinhenz@xxxxxxxx http://www.linuxtag.org/
Misc. payment, security, fraud, & authentication GAO reports (long posting)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 04:22 PM
To: epay@xxxxxxxx
Subject: Misc. payment, security, fraud, & authentication GAO reports (long posting)
* Payment Systems: Central Bank Roles Vary, but Goals Are the
Same. GAO-02-303 February 25, 2002
* Check Relay: Controls in Place Comply With Federal Reserve
Guidelines. GAO-02-19 December 12, 2001
* Federal Reserve Banks: Areas for Improvement in Computer
Controls. GAO-02-266R December 10, 2001
* Anti-Money Laundering: Efforts in the Securities
Industry. GAO-02-111 October 10, 2001
* Internal Controls: Federal Disbursement Controls Can Be
Strengthened. GAO-01-910R August 13, 2001
* Purchase Cards: Control Weaknesses Leave Two Navy Units Vulnerable
to Fraud and Abuse. GAO-01-995T July 30, 2001
* Financial Services Regulators: Better Information Sharing Could
Reduce Fraud. GAO-01-478T March 6, 2001
* Information Security: Advances and Remaining Challenges to Adoption
of Public Key Infrastructure Technology. GAO-01-277 February 26, 2001
* Bank Regulators' Evaluation of Electronic Signature
Systems. GAO-01-129R November 8, 2000
Abstracts:
Payment Systems: Central Bank Roles Vary, but Goals Are the
Same. GAO-02-303 February 25, 2002
The central banks of major industrialized countries have agreed on
common policy objectives and presented them in the Core Principles for
Systematically Important Payment Systems. Intended to help promote
safer and more efficient payment systems worldwide, the Core
Principles outline specific policy recommendations for systematically
important payment systems and describe the responsibilities of the
central banks. All of the central banks GAO studied seek to ensure
that their wholesale payment systems operate smoothly and minimize
systemic risk. All of the central banks provide settlement services
for their countries' wholesale payment systems. Some central banks
also provide wholesale clearing services. Other central banks own the
system but have little operational involvement in clearing, while
others participate in partnerships with the private sector. All of the
central banks GAO studied provide settlement for some retail payment
systems. Some, but not all, central banks exercise regulatory
authority over retail payment systems in their countries. Central
banks also tend to have less operational involvement in countries
where there is a relatively concentrated banking industry. In some
cases, laws governing payments and the structure of the financial
services industry direct the involvement of central banks in retail
payment systems.
Check Relay: Controls in Place Comply With Federal Reserve
Guidelines. GAO-02-19 December 12, 2001
This report discusses the management of the air transportation network
used to move checks from one Federal Reserve office to another. GAO
studied the propriety of practices for bidding, awarding, and
monitoring contracts and the adequacy of controls to monitor fuel and
other payments to vendors. The network was moved to the Federal
Reserve Bank of Atlanta (FRB Atlanta) in September 1998 and renamed
Check Relay. Check Relay's internal controls are designed to ensure
that each step of the contract evaluation and approval process
conforms to FRB Atlanta and Federal Reserve System policies and that
appropriate senior officials review and approve contract terms. Check
Relay also ensures that all payments to vendors conform to contract
terms. Another set of controls verifies that the amount of fuel used
by Check Relay's vendors is consistent with expected levels and that
fuel is provided only to the appropriate recipients. Check Relay is
managed as a unit of the Retail Payments Office, which is managed out
of FRB Atlanta. The Board's Division of Reserve Bank Operations and
Payment Systems also has oversight responsibility over Check
Relay. GAO found no evidence with which to question FRB Atlanta's
conclusions that Check Relay's internal controls are effectively
designed and implemented.
Federal Reserve Banks: Areas for Improvement in Computer
Controls. GAO-02-266R December 10, 2001
As part of its audit of the U.S. government's fiscal year 2000
financial statements, GAO reviewed computer controls over key
financial systems maintained and operated by the Federal Reserve Banks
(FRB) on behalf of the Department of the Treasury's Financial
Management Service (FMS) and the Bureau of the Public Debt (BPD). GAO
identified opportunities to improve general controls related to access
at two data centers; access, system software, and service continuity
at a third data center; and access and system software at a fourth
data center. GAO also identified opportunities to improve
authorization controls over four key applications and accuracy
controls over one of these key applications. FRB had corrected or
mitigated the risks associated with all vulnerabilities discussed in
earlier GAO reports. Although the general and application controls
identified do not pose significant risks to the FMS and BPD financial
systems, they warrant action to decrease the risk of inappropriate
disclosure and modification of sensitive data and programs, misuse of
or damage to computer resources, and disruption of critical
operations.
Anti-Money Laundering: Efforts in the Securities Industry. GAO- 02-111
October 10, 2001
To disguise illegally obtained funds, money launderers have
traditionally targeted banks, which accept cash and arrange domestic
and international fund transfers. However, criminals seeking to hide
illicit funds may also be targeting the U.S. securities
markets. Although few documented cases exist of broker-dealer or
mutual fund accounts being used to launder money, law enforcement
agencies are concerned that criminals may increasingly try to use the
securities industry for that purpose. Most broker-dealers or firms
that process customer payments for mutual funds are subject to
U.S. anti-money laundering requirements. However, unlike banks, most
of these firms are not required to report suspicious activities. The
Treasury Department is now developing a rule requiring broker-dealers
to report suspicious activities. Treasury expects that the rule will
be issued for public comment by the end of this year. Various
intergovernmental groups, such as the Financial Action Task Force,
have been working on recommendations that call for member nations to
take various steps to combat money laundering through their financial
institutions, including requiring securities firms to report
suspicious activities. Although many members countries report that
they have issued all or many of these recommendations and have applied
them to their securities firms, it is difficult to determine how well
the measures are being implemented and enforced.
Internal Controls: Federal Disbursement Controls Can Be
Strengthened. GAO-01-910R August 13, 2001
GAO tested certain internal controls over federal disbursements
processed by the Department of the Treasury's Financial Management
Service (FMS) in fiscal year 2000. With some exceptions, FMS makes
disbursements for all federal agencies through its Regional Financial
Centers and Debt Management Operations Center. For fiscal year 2000,
FMS reported processing approximately 890 million disbursements
totaling more than $1.2 trillion. The centers disburse funds by check,
electronic funds transfer (EFT), or Fedwire. FMS reported that these
disbursements for fiscal year 2000 included approximately 265 million
checks amounting to more than $265 billion, approximately 625 million
EFTs amounting to more than $720 billion, and approximately 47,000
Fedwires amounting to more than $275 billion. The centers also process
Automated Standard Application for Payments (ASAP) system
enrollments. FMS reported the federal agencies authorized payments of
over $254 billion in fiscal year 2000 using the ASAP system. This
report reviews the results of GAO's (1) follow-up work on previously
recommended improvements and corrective actions taken to address such
recommendations and (2) fiscal year 2000 testing and related
recommendations for improving controls over safeguarding assets and
processing and documenting delegation and designation of agency
certifying officers. GAO found that FMS' and the centers' corrective
actions resolved weaknesses reported for fiscal year 1999 relating to
(1) controls over checks awaiting destruction and returned checks, (2)
segregation of duties for the ASAP system, (3) documenting agency
certifying officer's signature verification, (4) authorized signature
for return of canceled Fedwire disbursements, and (5) reconciling
courtesy disbursements. Similar to fiscal year 1999, FMS had internal
control weaknesses in personnel screening, inventory control, audit
procedures, and reporting requirements.
Purchase Cards: Control Weaknesses Leave Two Navy Units Vulnerable to
Fraud and Abuse. GAO-01-995T July 30, 2001
This testimony discusses internal controls weaknesses that left two
Navy units in San Diego, California, vulnerable to purchase card fraud
and abuse. GAO found a proliferation of purchase cards at the two
units in San Diego--the Space and Naval Warfare Systems Command and
the Navy Public Works. In the end, more than 1,700 cardholders
essentially had the authority to make their own purchase decisions. A
serious breakdown in internal controls over the receipt of government
property and the certification of monthly statements, coupled with
flawed or nonexistent policies and procedures and the failure of Navy
employees to adhere to valid policies and procedures, led to (1) the
loss, theft, and misuse of government property; (2) the potential
abuse of purchase cards; and (3) payments of potentially fraudulent
charges. Five fraud cases have already been identified, and the
government remains extremely vulnerable to fraud, waste, and abuse
arising from the purchase card program at the two Navy units. This
testimony summarized the November report, GAO-02-32.
Financial Services Regulators: Better Information Sharing Could Reduce
Fraud. GAO-01-478T March 6, 2001
The sharing of regulatory and criminal history data among financial
services regulators can reduce fraudulent activities. GAO recently
reported on several instances in which unscrupulous brokers moved from
one financial industry to another. This testimony focuses on (1)
systems used by financial regulators for tracking regulatory history
data, (2) regulatory history data needed to help prevent rogue
migration and limit fraud, (3) criminal history data needs among
financial regulators, and (4) challenges and considerations for
implementing an information-sharing system among financial regulators.
Information Security: Advances and Remaining Challenges to Adoption of
Public Key Infrastructure Technology. GAO-01-277 February 26, 2001
The federal government must overcome several major challenges before
public key infrastructure (PKI) technology can be widely and
effectively used. These challenges include providing interoperability
among agency PKIs, ensuring that PKI implementations can support a
potential large scale of users, reducing the cost of building PKI
systems, setting policies to maintain trust levels among agencies, and
establishing training programs for users at all levels. Although such
challenges are difficult to overcome in the near term, the federal
government can take steps to better assist agencies develop and
implement PKIs that may eventually be interconnected into a federal
governmentwide system. The recent effort to develop a Federal Bridge
Certification Authority (FBCA) is an excellent first step in this
direction, but this effort lacks the context of a well-defined program
plan for the government as well as key policy and technical
standards. Establishing a federal PKI management framework could
facilitate and accelerate participation in the FBCA as well as overall
federal adoption of key technology for enabling electronic government.
Bank Regulators' Evaluation of Electronic Signature
Systems. GAO-01-129R November 8, 2000
This report discusses bank regulators' evaluation of electronic
signature systems. Financial institutions use signature systems to
verify or authenticate the identity of customers conducting financial
and nonfinancial transactions over the Internet and other open
electronic networks. Officials at the Office of the Comptroller of the
Currency (OCC) and the Federal Reserve told GAO that they are
developing an examination strategy for Identrus LLC, which is an
entity that provides services to financial institutions to
authenticate electronic signatures. OCC officials have not determined
what role they will play in assessing Identrus' operations, but they
believe that financial institutions should take an active role in
assessing the risks associated with electronic signatures.
Security Proportional to Risk (was: IBM Mainframe at home)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/04/2002 04:58 PM
To: epay@xxxxxxxx
Subject: Security Proportional to Risk (was: IBM Mainframe at home)
Anne & Lynn Wheeler writes:
After that, things still continued on the seven year cycle ... but
there were two teams, working in parallel producing products
offset. The 3081 was the "158" team ... the 3090 was the "168" team.
above from "ibm mainframe at home" thread in a.f.c
http://www.garlic.com/~lynn/2002d.html#7
with OT thread drift to security proportional to risk thread
(somewhat e-commerce):
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
in the early 70s there was a trade-secret document theft case
regarding disk technology. The assertions was that the "disk clone"
business took 12 to 18 months to reverse engineer, duplicate and bring
product to market (after initial introduction of new product). The
assertion was that the document thefts would potentially allow a clone
manufactur to bring a product to market six months earlier
... representing possibly several tens of billions of dollars in
revenue.
somewhere along the way, the judge supposedly raised the "swimming
pool attractive hazard" issue (aka pool owner is responsible for bad
things that happen in their pool unless they can demonstrate fences
and other security measures proportional to determination of
trespassers that might find the pool attractive); aka for legal
remedy, have to demonstrate security measures proportional to the
value of the trade-secret.
For actual disk hardware this was a secure compound with perimeter
fence and guards at the gates, patrols inside the compound, secure
building with door badge readers, enforced & audited policies about
tail-gating, 2nd floor (above ground) machine room with even more
restricted badge reader acces. Within the machine room, devices were
housed in a "test cell" ... basically a small heavy steel wire mesh
cage (maybe 5x5x7, reinforce steel floor, heavy steel wire mesh sides
& top). Door to cage had combination lock and each cage had unique
combination. Lots of audit procedures and patrols to assure that
security was being followed. This is somewhat analogous to safe
deposit boxes but with more layers of security and constant auditing
procedures.
Documents were "candy-stripe" covers with registered confidential
classification. Each copy of a document was numbered. Each page of a
candy-stripe document had the document copy number embossed in large
print on every page (basically faint background but the number was
large print essentially filling the whole page) with legend
"registered confidential, do not copy/reproduce" on every page (either
3800 background flash or special paper from secure printer).
Each copy was signed out to specific person and that person had to
follow a lot of processes protecting the document which were also
audited on regular basis. A person having registered confidential
documents also had special secure file cabinat for storing the
documents, their offices had sporadic audits after hours and there
were periodic audits to verify that the person still had possesion of
the document. Registered confidential document copies tended to number
in the tens or at most few hundres.
For the 3081 there were a whole file drawer of "811" documents (from
the date nov. 1978) that were registered confidential and had to
demonstrate that every copy of every 811 document was managed with the
highest/appropriate security processes. Even at that, there was some
leakage and a fairly well publiciszed industrial espionage case
related to 811 documents.
bringing back to merchant e-commerce sites thread ... would an
attractive hazard be a defense with regard to hacking e-commerce
servers that had insufficient security?
random registered confidential refs:
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was
What specifications will the standard year 2001 PC have?)
random attractive hazard refs:
http://www.garlic.com/~lynn/aadsmore.htm#2527a RFC 2527 Physical Security
Controls Question
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
random disk test cell ref:
http://www.garlic.com/~lynn/94.html#15 cp disk story
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#18 IBM 4381 (finger-check)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/99.html#31 Old Computers
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still
have a meaning?
http://www.garlic.com/~lynn/2000c.html#72 Does the word "mainframe" still
have a meaning?
http://www.garlic.com/~lynn/2001h.html#19 checking some myths.
http://www.garlic.com/~lynn/2001l.html#13 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting
Was: Movies with source code
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions
(was Re: Did Intel Bite Off MoreThan It Can Chew?)
random 811/3081 references:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out
the Door
http://www.garlic.com/~lynn/94.html#00 Big I/O or Kicking the Mainframe out
the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and
other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to
Today's Micros?
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the
past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was
Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was
Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was:
Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it
again
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language
for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries
workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries
workstation?
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#62 z/Architecture I-cache
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly
off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly
off topic)
http://www.garlic.com/~lynn/2001c.html#53 Varian (was Re: UNIVAC - Help
??)
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that
ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re:
Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard
Disk?
http://www.garlic.com/~lynn/2001n.html#9 NCP
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's
Anymore
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit
processor
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
random security proportional to risk refs:
http://www.garlic.com/~lynn/aadsmore.htm#2527a RFC 2527 Physical Security
Controls Question
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server
security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror5 [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#rhose17 [Fwd: Re: when a fraud is a
sale, Re: Rubber hose attack]
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe??
... security proportional to risk
http://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on
netbanking & e-commerce security
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment
standards ... finger slip
http://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations
on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card
help online shopper to feel more secure?
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean
Anything?
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything?
http://www.garlic.com/~lynn/2001k.html#55 I-net banking security
http://www.garlic.com/~lynn/2001l.html#2 Why is UNIX semi-immune to viral
infection?
Regarding SPKI delegation certificate format (frowaded)
From: Lynn Wheeler
Date: 03/05/2002 02:26 PM
To: epay@xxxxxxxx
Subject: Re: Regarding SPKI delegation certificate format (frowaded)
forwarded from SPKI mailing list (note authentication, spki, & aads
masther thesis reference)
Pornthep Narula on 3/5/2002 5:47 am wrote:
On Mon, 4 Mar 2002, Carl Ellison wrote:
> I don't see a problem with delegating 10 of my 20 units to someone
> else. This is the same as writing a check. As long as you and I both
> have accounts in this bank, I should be able to transfer units to you
> at will -- and receive them as well. I can also convert real currency
> to these units. It's up to the bank if I can convert units back to
> real currency.
>
> Right?
right, iff you treat `transfer', `delegate' and `grant' as same. but
are they?
an excerpt from Oxford Advanced Learner's Dictionary, 6th Edition:
delegate (v) to give part of your work, power or authority to sb in a
lower position than you.
grant (v) to agree to give sb what they ask for, especially formal or
legal permission to do sth.
transfer (v) to officially arrange for sth to belong to sb else or for
sb else to control sth.
as far as these traditional definitions go, SPKI doesn't deal with
transfer at all, and is rather ambiguous when it comes to delegation
vs grant. in fact, the three words have often been used
interchangebly in SPKI-related RFCs, drafts, papers, and
discussions. this, IMHO, is rather confusing and counter-productive.
i've been working on an authorization management framework, based on
SPKI and AADS, that treats these three acts differently. a master's
thesis is expected to be finalised and available for peer reviews
later this year.
--
Regards,
Pornthep (tep) Narula
PKI: An Insider's View
From: Lynn Wheeler
Date: 03/06/2002 01:18 PM
To: epay@xxxxxxxx
Subject: PKI: An Insider's View
random other refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius
http://www.garlic.com/~lynn/x959.html#aads
http://www.garlic.com/~lynn/subtopic.html#privacy
====================================================================
http://www.infosecuritymag.com/articles/october01/columns_logoff.shtml
SECURITY STRATEGIES FOR E-COMPANIES
PKI: AN INSIDER'S VIEW
Bad karma and a multitude of technical issues have kept the technology
from taking off.
BY BEN ROTHKE
It's been a recurring theme the past few Januarys: "This is the year
of PKI." Such aspirations of hitting a grand-slam homerun weren't
overly optimistic since public key infrastructure addressed many of
the emerging Internet threats and operating necessities of e-commerce.
PKI vendors spent billions in product development and corporate
acquisitions to position themselves for this potential
market. However, the PKI game has essentially turned into a no
hitter. I know; I was a player for one of the biggest PKI
teams--Baltimore Technologies (www.baltimore.com).
With evaporating revenues and plunging stock prices, PKI vendors--such
as Baltimore, Entrust (www.entrust.com) and VeriSign
(www.verisign.com)--have dramatically scaled back their
infrastructure, laid off employees (myself included) and rushed to
refocus their offerings in more marketable sectors. Few still embrace
their PKI roots, instead promoting new market strategies--data
protection, infrastructure assurance, etc.
Where did PKI go wrong? There are many answers to explain why PKI (at
least to date) has struck out. After spending years in the space, I've
identified the following reasons.
Lousy name. For people without a background in security and
cryptography (in other words, the majority), the term PKI is utterly
nebulous. You've lost your potential customer by the time you explain
what PKI means. Many say digital certificate infrastructure would have
been a better name, but neither term rolls off the tongue like
firewall or antivirus.
Security ignorance. The oft-quoted security dictum states: "If you
think cryptography will solve the problem, then you don't understand
cryptography and you don't understand your problem." This was also
true of many who rushed to implement PKI simply because it was a cool
technology promoted by IT prognosticators. Though PKI has many
benefits, an organization without a clearly defined business need for
it has no reason to implement it.
The "I" of PKI. The single biggest problem with PKI is that most
people forgot the "infrastructure." PKI is a huge infrastructure
project, unlike the preferred plug 'n' play solutions. While it's not
rocket science, PKI is challenging because it's about reengineering a
business infrastructure with an entirely new security
architecture. PKI is 10 percent technology and 90 percent policies and
procedures. Many early adopters didn't realize that enabling an
enterprise to work with the certificates issued by a PKI server can
take considerable time--months and even years.
PKI is new. Though the fundamentals of PKI were created in the 1970s,
the implementation of PKI and the emergence of commercial PKI vendors
didn't begin until the late 1990s. Many deployment and management
problems occurred because the technology was as new to the vendors as
it was to the customers.
Methodology. When discussing PKI deployment plans and methodologies,
many customers were clueless. While CIOs aren't expected to know the
minutiae of a PKI rollout, they need to know the
fundamentals. Unfortunately, many CIOs didn't have a strategy for
dealing with the multitude of non-PKI compliant in-house
applications. They often wanted to roll out PKI deployments so badly
that they lost sight of the big picture.
Liability issues. Infosecurity is about risk management, part of which
is delineating liability for a specific course of action. With PKI
rollouts, there was often a huge gap between who was liable for what
in the event of a false positive or false negative.
Interoperability and lack of standards. Interoperability issues have
long been a problem between users and PKI vendors. Interoperability
led to the creation of the PKI Forum in early 2000, but it hasn't
created many PKI standards. Without a common specification, users are
left without a ubiquitous system for using digital certificates.
Legacy systems. While vendors constantly refine and improve
applications, legacy systems continue to dominate many IT environments
and often have zero PKI interoperability. Retrofitting is an option,
but it's expensive and time consuming.
PKI is about establishing and maintaining a level of trust in the
digital world. In the real world, trust is built through complex
social, legal, national, international and business interactions that
often take years or decades to develop. Unfortunately, establishing
that same level of trust in cyberspace through technology is much
harder. With Internet time being what it is, analysts demanding
profits by quarter's end and digital trust meaning myriad different
things to different people, PKI has been unable to escape its bad
karma.
(Extensible Markup Language) XML-Signature Syntax and Processing
From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: (Extensible Markup Language) XML-Signature Syntax and Processing
also see ref for RFC index at:
http://www.garlic.com/~lynn/rfcietff.htm
A new Request for Comments is now available in online RFC libraries.
RFC 3275
Title: (Extensible Markup Language) XML-Signature Syntax
and Processing
Author(s): D. Eastlake 3rd, J. Reagle, D. Solo
Status: Standards Track
Date: March 2002
Mailbox: Donald.Eastlake@xxxxxxxx, reagle@xxxxxxxx,
dsolo@xxxxxxxx
Pages: 73
Characters: 164198
Obsoletes: 3075
I-D Tag: draft-ietf-xmldsig-core-2-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3275.txt
This document specifies XML (Extensible Markup Language) digital
signature processing rules and syntax. XML Signatures provide
integrity, message authentication, and/or signer authentication
services for data of any type, whether located within the XML that
includes the signature or elsewhere.
This document is a product of the XML Digital Signatures Working Group
of the IETF.
This is now a Draft Standard Protocol.
Slashdot reports RSA keys under 2k insecure
From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: Re: Slashdot reports RSA keys under 2k insecure
following is posting that Bernstein made to sci.crypt today ....
I've sent the following comments to the reporter:
: My paper demonstrates that extremely long keys need to be made
: approximately 3.009 times longer for the same factoring cost. There's no
: ``might'' about this; it's a straightforward mathematical fact.
:
: My paper repeatedly emphasizes that the situation for short keys is much
: more difficult to analyze. It _asks_ what the practical situation is. It
: _asks_ whether 1536-bit keys can be factored at reasonable cost.
:
: Your comments about ``claimed speed improvements in practice'' and
: ``implying that encryption keys as long as 2048 bits can now be broken''
: are blatant misrepresentations of what my paper actually says.
:
: My paper is a grant proposal. It explains the huge improvement for long
: keys, and outlines a plan for carrying out the short-key analysis. The
: results of the short-key analysis will not be known for a few years.
:
: Making claims about what those results will be, before the analysis has
: been done, is scientifically irresponsible. I despise such behavior; I
: resent being accused of it; I expect you to post a correction.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
t.c.jones@xxxxxxxx on 3/11/2002 6:15 pm wrote:
I talked to some cryptographers to see if this had any
meaning for crypto practitioners.
As far as I can tell there is no example of any RSA key
of 700 bits length being cracked (ie factored.)
If we assume that Bernstein can reducde the effort by
1,000,000 times, that is still only 20 bits.
If we assume that it will become 1,000,000 time easier
to factor every year, that is 20 bits per year, or 15
years before 1000 bit RSA keys are at risk.
To be safe I tell people who want keys to last for 10
years to use 2048 bit keys. For the rest of us, 1024
bits should last for a long time.
..tom
> http://slashdot.org/articles/02/02/26/179206.shtml?tid=93
Definese Dept Criticised on Internal Credit Card Fraud
From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: Definese Dept Criticised on Internal Credit Card Fraud
reference to the GAO report was posted here couple weeks ago
http://www.garlic.com/~lynn/aepay10.htm#19
http://www.thebankingchannel.com/printarticle.html?id=TBCWGCDL8UC<x-html>
Defense Dept. Criticized on Internal Credit Card Fraud From
AmericanBanker
Federal investigators testified before a House Governmental Affairs
subcommittee Wednesday that the Defense Department's efforts to curb
credit card fraud by employees have been ineffective.
Commanding officers from the Navy Public Works Center and the Space
and Naval Warfare Systems Center, which were investigated by the
General Accounting Office from November to February, also appeared at
the hearing to pledge further reform. But the vows were met by stern
words from skeptical lawmakers.
"We are now going to be considering a budget that requests an
unprecedented increase in the defense budget, and I think it is
appropriate to scrutinize every dollar, every million dollars, every
billion dollars," said Janice D. Schakowsky, D-Ill.
Definese Dept Criticised on Internal Credit Card Fraud
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 03/17/2002 01:23 PM
To: epay@xxxxxxxx
Subject: RE: Definese Dept Criticised on Internal Credit Card Fraud
(possible resend?? ... I'm getting solid database corrupt, unable to
allocate space error message when attempting to transfer this to the
corporate server)
oh well, little finger fumble. i'm well known (infamous) for it (even 20 years ago).
there was a researcher in the early '80s that sat in the back of my
office, went to me with meetings, got copies of all my email and logs
of instant messages for a 9 month period. A detailed analysis turned
into PhD sort of in CMC (computer mediated communication) ... joint
between the language dept & computer AI dept at stanford (analysis of
face-to-face, telephone, meeting, one-on-one, email, mailing lists,
newsgroups, instant messages, etc ... compared & contrasted). Part of
it including early computer conferencing with early mailing list
technolgies (various precursors to current listserv &
majordomo). There was also some subsequent books and papers published
involving some of the same material (aka Knowledge Machines, Language
and Information in a Technoligical Society).
random listserv/majordomo:
http://www.garlic.com/~lynn/99.html#225 BBSs vs. The Internet
http://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
http://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
http://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001c.html#19 What is "IBM-MAIN"
http://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
misc. refs to stanford phd:
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
http://www.garlic.com/~lynn/99.html#205 Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2001j.html#29 Title Inflation
http://www.garlic.com/~lynn/2001k.html#64 Programming in School (was: Re: Common uses...)
http://www.garlic.com/~lynn/2002b.html#51 "Have to make your bones" mentality
http://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc
slightly related:
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001j.html#31 Title Inflation
http://www.garlic.com/~lynn/2002e.html#10 Deleting files and emails at Arthur Andersen and Enron
tlewis@xxxxxxxx on 3/15/2002 7.04 pm wrote:
Definise Dept.? Is that the government deparment responsible for removing
finesse from government publications? If so, they do their job extremely
well.
Tony
-----Original Message-----
From: Lynn Wheeler [mailto:lynn.wheeler@xxxxxxxx]
Sent: Thursday, March 14, 2002 9:09 PM
To: Lewis, Tony
Subject: Definese Dept Criticised on Internal Credit Card Fraud
[dgc.chat] XML/X - part I
From: Lynn Wheeler
Date: 04/07/2002 07:41 PM
To: epay@xxxxxxxx
Subject: Re: [dgc.chat] XML/X - part I
or get really wierd and start talking about TPC ACID properties.
Atomicity
Either the transaction completes, or nothing happens at all. When a
transaction fails in the middle of operation, the operations that
have taken place should be rolled back.
Consistency
A transaction must begin in a consistent state and leave the system in
a consistent state.
Isolation
No other participants are allowed to access the intermediate
results. All intermediate operations are performed in
isolation. Outside participants are only allowed access once a
consistent state has been reached.
Durability
Once a server has committed to a transaction, it completes the
transaction even if it suffers a system failure.
ref: The Benchmark Handbook for Database and Transaction Processing
Systems, Jim Gray, ed, Morgan Kaufmann.
random refs:
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2001.html#6 Disk drive behavior
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001k.html#15 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002d.html#5 IBM Mainframe at home
t.c.jones@xxxxxxxx on 3/27/2002 6:54 pm wrote:
Idempotency - whoa!
the same idea is included in ANSI X9.59 - it is call a
LUID there. See the following snippet of XML that i
proposed to implement it. ..tom
<?xml version="1.0" encoding="UTF-8" ?>
<!-- ANSI X9.59 secure payment object definitions -->
<!DOCTYPE X9Adocument (View Source for full doctype...)>
<XAdocument>
<PAYREQ version="1">
<Merchant name="Frank's Fraudulent Flea Market">1,5879156</Merchant>
<Transaction payCode="x" LUID="113" startDate=""
endDate="20010628" merchantTrac="123-4567890">79541USD</Transaction>
<Consumer>2,6652827</Consumer>
</PAYREQ>
<Result Action="Accept">200 OK</Result>
<TOKSIG>2938d77e8a5f827</TOKSIG>
<APPSIG>098d7a855f822b1</APPSIG>
</XAdocument>
> Date: Mon, 25 Mar 2002 23:03:13 -0500 (EST)
> From: Ian Grigg <iang@xxxxxxxx>
> To: xml-api@xxxxxxxx
> Subject: [dgc.chat] XML/X - part I
> Cc: dbs@xxxxxxxx, dgcchat@xxxxxxxx
> Sender: owner-dgcchat@xxxxxxxx
> Reply-To: dgcchat@xxxxxxxx
>
> It is with some satisfaction that we announce the first
> public demonstration of a new project that we've been
> working on for the last six months.
>
> This demonstration is taking place at Java 1 this week,
> by Erwin Van der Koogh, a programmer with Sun's XML group
> in Dublin. He's also a WebFunds programmer, having been
> primarily responsible for the current generation.
>
> You can check out a scratch home page for the project at:
>
> http://www.webfunds.org/guide/xml/
>
> We were looking some time ago at the difficulty faced
> by the various merchants in implementing access to the
> current money providers. As no merchant could really
> predict where the good money was, so to speak, it was
> pretty obvious that being able to implement a range of
> gold-based units was much less risky.
>
> But it was also rather impossible. The transfer methods
> for the systems ranged from pretending to be a browser,
> to accessing partially complete protocols to .. nothing.
> None of the systems in place seem to appeal as none of
> them have actually been thought out from the point of
> view of what we know about protocols and networks.
>
> It behoved us to come up with our own spend system. We
> were in the throes of developing our own web-based system,
> and we wanted that bit right. After all, a lot of demand
> comes from the support of the merchant class (a group we
> christened as Matildas, but that's a story for another
> day).
>
> Others, such as Intertrader, were still smarting at the
> cost of having developed access for different systems,
> and not having been able to efficiently deploy it because
> of the system bugs imposed on them. And, yet others
> simply didn't know where to start.
>
> It all begged for a standard. We sat down and drew one
> up. Now, because standards committees tend to be noisy,
> rumbunctious, and ultimately unproductive, unless they
> have a very solid mission to draw from, we decided not
> to make this a publicity thing in the beginning. That
> is, we decided to write it first, then open it up.
>
> All well and good, and of course, we chose to do our
> transfer interface in XML. We called it XML/X as a
> quick code name for the project, being transactions in
> XML. The results will be open source, the documentation
> will be readily available, and no fees will be levied on
> joining or using. Even though this project is about
> money, it makes more monetary sense to impose no barriers
> on its widespread adoption.
>
> A quick example might clarify what all this hyperbole is
> about. Imagine you have some accounts at a standard DGC
> such as e-gold, goldmoney, or one of those other systems
> such as PayPal. As a merchant, you want to initiate a
> transaction from your automated web system to pay out a
> customer. Or vice versa.
>
> So, you open up a connection to the money server and
> send down a stream of commands to cause it to happen.
> Here's how you would do it in today's XML/X:
>
> <TransferRequest>
> <Transfer>
> <ClientID> P9348235 </ClientID>
> <Payee> E3491 </Payee>
> <Payer> 34201-543 </Payer>
> <Amount> 45.23 </Amount>
> <Currency> Platinum </Currency>
> <Memo> Slicker than Slick </Memo>
> </Transfer>
>
> <Auth>
> <Username> iang </Username>
> &