NACHA. Was: The FI e-standardization blues
Title: Message Hi Mike, Still tuned on this channel :-) I have been notified by another list subscriber regarding these new developments. I still find it a bit puzzling that the specification is nowhere to find. I assume that this is a variation of VISA's 3D Secure which is a good system. In fact I believe the basic principle will one day replace EMV when the "card" has morphed into "phone". Why is that? Because such a scheme would also support local B2B payments without having to distribute purchasing cards; the "right to buy" would just be a check-box in the buying organization's purchasing system. There is simply no end to the things you can achieve by using a "home base" asa TTP in on-line transactions! Regards Anders Rundgren - Original Message - From: Peter Yeatrakas To: Versace, Michael ; [EMAIL PROTECTED] ; internet-payments Sent: Saturday, April 01, 2006 03:39 Subject: RE: The FI e-standardization blues Mike, Project Action is getting new legs; looks like a pilot before long, according to NACHA. Wonder if this email address is going to fly since its been two years. -Original Message-From: Versace, Michael [mailto:[EMAIL PROTECTED] Sent: Saturday, March 06, 2004 12:49 PMTo: [EMAIL PROTECTED]; internet-paymentsSubject: RE: The FI e-standardization blues Having built the original prospectus for Project Action, I can say that a contributing reason for its demise was investments in debit card solutions at the time, and a the lack ofinterestin credit transfer alternative in the US ACH network. Regarding standards, most financial institutions participate in standards with a defensive, not offensive posture. A current day example of thiscan be seen if you look atBizTalk, RosettaNet, Swift, and IST integrations being prepared. Michael Versace Financial Services NEC Solutions America -Original Message- From: Allen Weinberg [mailto:[EMAIL PROTECTED] Sent: Sat 3/6/2004 2:14 PM To: 'internet-payments' Cc: Subject: RE: The FI e-standardization blues Anders,I agree with the premise on standards. One small point about ProjectACTION. It wasn't killed by the banks due to anything related tostandards or the public domain. It was killed because the banks didn'twant to invest in a system which, while desparately needed, wouldthreaten the higher revenue streams from existing payments.Best regards,Allen= = = = = = = = = = = = = = = = = = = = =Try our new site: www.PaymentsNews.comAllen WeinbergGlenbrook PartnersTrusted Advisors in Financial Services(415) 305-6660www.glenbrook.com-----Original Message-From: Anders Rundgren [mailto:[EMAIL PROTECTED]]Sent: Saturday, March 06, 2004 7:49 AMTo: internet-paymentsSubject: The FI e-standardization bluesThe FI e-standardization blues---Have you seen the movie "A beautiful mind"? In caseyou have not it is about a Nobel-prize winner (disturbedbut brilliant at the same time), who's primary thesis isan game optimization theory that goes as follows:"You gain more by doing something that your entire groupgains by, than by doing something that only benefits yourself"I believe this applies extremely well the establishment ofinfrastructure standards.An industry which seems completely unaffected by this theory aswell as by the virtual cemetery of earlier failed proprietary efforts,is the financial sector. Even in a very small country like Swedenthe FI sector (only comprising of 4-5 major banks) havemanaged to not unite on:- Electronic invoices (3 different) [1]- On-line payment systems (4-5 different)- Citizen electronic ID software/system (3-4 different)A recent US example is NACHA's Project ACTION, werethe members preferred shelving the entire project rather thanputting it in the public domain where it might have spurred thecreation of a highly needed on-line payment system standard.It is also interesting to note that banks in spite of their heavyuse of IT, are virtually invisible in general standardizationefforts and that they in their own standardization efforts,often charge huge member fees excluding a lot of potentiallyuseful people and organizations.I believe it is time for the financial industry to [re]enter the21st century with an open mind instead of unmotivated fear.Anders Rundgren1] After 5 years(!) of unsuccessful operation, they have finallyconcluded that the customers' apparently have no interests insupporting three invoicing "standards" that essentially do thesame thing.
3D Secure and EMV status?
Anybody with some information on this? In Sweden no issuing bank (including Nordea who claims to be the biggest on-link bank provider in World), have to date implemented 3D Secure. EMV cards have been purchased in large quantities but rollout is still fairly limited. SEB currently opts to stay away from EMV as they claim that the frauds on the Internet are much worse than in the traditional market. Anders R
3D Secure failed in Sweden
3D Secure failed in Sweden === Although not an official truth, this is the de-facto situation. I can't say I know the global situation but I doubt that 3D Secure is a smash hit, in spite of the fact that we really need a new payment system on the Internet. The reason why 3D Secure failed is that the Swedish banks already had developed 3D Secure-like payment systems when 3D Secure was launched. These systems all have one thing in common that 3D Secure lacks: A way to use the system also for local debit using the same PAN, hereby bypassing the VISA/MC networks and associated additional fees. The culprit is the 3D architecture itself and it reliance on central brand directories. These directories does not only limit dual-use PANs, but also makes it impossible to redirect payment requests to a buying organization that in turn speak with the issuer, which would eliminate the monstrosity known as P-Cards. If DNS had been used (like specifying mybank.com or mycompany.com instead of a credit-card number), 3D could have been the killer payment system. Using DNS, adding one-time PANs like Orbiscom's would also be a (user transparent) no-brainer, not requiring the usage of a specific proxy PAN for which there is no card. Currently, 3D represents just another more or less failed attempt by banks to create vital infrastructure. EMV is though likely to eclipse the 3D Secure debacle with a huge margin but that is another story... Anders Rundgren e-Security Architect etc.
Motorola trials NFC payments with MasterCard
http://www.motorola.com/mediacenter/news/detail/0,,4762_4058_23,00.html EMV? It will likely be the biggest fiasco of the financial sector ever. However, it is still possible to call off the EMV project, with (completely true) statements such as: Recent technological advances indicate that it is time for reconsideration The biggest problems with the credit card system is actually on the Internet, something EMV was not designed to handle on a wide scale My 0.2 cents
One-time PAN-codes, another usage
If I understand things correctly, the major point with one-time PAN-codes is that they should limit fraud performed by merchants. It seems that one-time PAN-codes could also be used to more or less anonymize the customers with respect to the merchant. This though requires that the payment scheme is on-line based like 3D Secure rather than using static schemes like HW tokens. Comments?
Re: EMV cards as identity cards
Exactly what are you addressing here??? 1. That EMV is a bad idea since it (optionally) uses PKI? Could very well be so but EMV is also an off-line thing as the EMV founders incorrectly thought that not many countries could afford broadband! Regardless how right of wrong this assumption may be, those who actually are prepared to convert to accepting chip-cards, probably have broadband as well. That is, a core EMV idea is indeed ill-founded! 2. That ID certificates are redundant? As ID certificates is an FI add-on service to be used by thousands of independent e-gov relying parties using a common national identity scheme, there is no viable alternative to PKI except using a gateway approach which is fairly much the same trust wise. The difference is that some people do not believe that gateways can sign but schemes running in Norway shows that this is piece of cake. At least technically! Anders - Original Message - From: [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: internet-payments [EMAIL PROTECTED]; Safecode [EMAIL PROTECTED] Sent: Monday, September 20, 2004 22:11 Subject: Re: EMV cards as identity cards on of the issues in the account/identity fraud scenarios is that just knowing the PAN allows fraudulent transactions to be performed. you start to see things like harvesting of merchant transaction files that provide PANs for fraudulent transactions. recent studies have indicated that possible at least 77 percent of such harvesting involves insiders. part of the scenario is the security versus risk discussed in this posting about merchant transaction file harvesting ans security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61 on of the requirements given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. the resulting x9.59 standard http://www.garlic.com/~lynn/index.html#x959 uses digital signature to authenticate retail transactions (regardless of kind, including iso 8583 payment transactions) but doesn't mandate the horrendous payload bloat of attaching a redundant and superfulous relying-party-only certificate. x9.59 also specifies that account numbers that are used in x9.59 transactions can not be used in non-authenticated transactions. the result is that it is no longer possible to perform fraudulent payment transactions just by learning an account number. the scenario then is that if it is no longer possible to perform fraudulent transactions by harvesting (x9.59) account numbers from merchant transaction files then it is no longer necessary to maintain such high security infrastructures to prevent crooks from acquiring knowledge of account numbers. we've referred to this being privacy or identity agnostic as opposed to truely anonymous. there is still an account number floating around ... but typically has no other identifying information ... unless somebody gets a court order to acquire the information from your financial institution. misc references to privacy, identity, x9.59, etc http://www.garlic.com/~lynn/subpubkey.html#privacy misc. past postings mentioning privacy/identity agnostic: http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF WG on anonymous IPSec at 9/18/2004 11:32 pm anders wrote: Paulo I may have lost the safecode stuff. I have no detailed description of EMV but that is probably easy to get on the net. But I essentially described a multi-application smart card which could hold a credit-card function, a purse and in this case also an identity function using PKI. Since the card does not have a display or keyboard etc. there is no way to select what resource the card reading app is to use. It is therefore assumed that this is hardcoded into applications or that applications offer this selection. However, you cannot do a selection without having parts of the available resources accessible. In the case of the ID-application it is actually your full identity! To allow any merchant to monitor a card holder's identity is in to some extent already possible due to the PAN code, but to *extend* this feature seems to clearly be a step in the wrong direction. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Re: [ijccr] Re: DELL ships CryptoPDA
Richard, I don't really see devices with specifications such as described in this URL as being any more suited for financial cryptography than the average virus-infected Windows PC - more part of an untrusted Internet over which secure messages can be transmitted given an appropriate Public Key Infrastructure than secure end devices suitable for generating or decrypting and verifying said messages. The actual device shown is probably as you describe. But PXA270 is a part of the Trusted Computing Platform concept and will *when implemented* seriously challenge secure end devices not only feature-wise but also from a security perspective. From a session I will hold at the Wireless Connectivity Word in Amsterdam RAI the 8:th of June 2004 I take this PPT picture: Wireless - Eliminates card skimming as there is no direct contact between phone and receiver Display - Alerts the user in a uniform way when a secure operation is to be performed Keyboard - PIN-codes never leave the mobile device Crypto - Intel's PXA270 shows the way ahead Usage - Typically always carried around by the user who regard their mobile devices as ever more valuable This is FINREAD but in a much more useful format. Anders
DELL ships CryptoPDA
http://www.aximsite.com/x30review Intel's PXA270 contains full support for cryptographic operations and storage of secret keys. Anders
Intel killed the smart ID-card
From a recent Intel pressrelease: The Intel PXA27x family of processors, formerly code-named "Bulverde," adds a number of new technologies to address the needs of cell phone and PDA users. It is the first product to integrate the Intel Wireless MMX technology, providing additional performance for 3-D games and advanced video while improving battery-life. The new chip also utilizes Wireless Intel SpeedStep technology, enabling significant power savings by intelligently managing voltage and frequency changes similar to the technology used in the company´s notebook processors. Also for the first time, Intel has integrated important security features through its Intel Wireless Trusted Platform to provide services such as trusted boot, secure storage of private information and cryptographic keys, and support for common security protocols. If you have a device that you already use extensivelyfor other purposes, that can connect to various services including to local PCsusing WLAN, and this device has a processor of the type above, why would you ever want a smart ID card that only supports a fraction of the other device's ID-related use-cases?
Re: VS: On-line signature standards
given the foundation for strong demonstration of authentication and strong demonstration of intention and non-repudiation then one might consider certificates as mechanism for trust propogation for the benefit of relying party strangers (assuming an unconnected, offline infrastructure where the relying party stranger has no prior knowledge of the signing entity and/or no recourse for contacting the certifying authority) This is not how it works in real life. Thousands of relying parties representing various e-government authorities do not consider citizens as strangers and hopefully not the reverse either. These authorities all share a common citizen-ID but may or may not exchange citizen information with other authorities belonging to the same domain (country). but the existing certificates do little or nothing to address the level of trust in the authentication mechanism and/or the level of trust in the non-repudiation mechanism. No, they work as a convenient handle to both the citizen and to the issuers using various revocation mechanisms. To have a unique relation with thousands of authorities is impossible from an economic point of view no matter how good it may be. But there is indeed a certain redundancy in certificates! It would be technically enough that a signature contained 1) the public key 2) a claimed ID (account number= 3) a link to the issuer 4) the signature itself But this reduction of data would not have such a dramatic impact as far as I can see. Well, it would delay the introduction of e-government services a few years of course. a few past threads related to 3-factor authentication: http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM? a few past threads specifically related to non-repudiation: http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm [EMAIL PROTECTED] on 10/31/2003 2:18 am wrote: http://www.fineid.fi/default.asp?todo=setlanglang=uk this is a link to an interesting multimedia presentation on the Finnish government - banks - telcos joint project on using the government produced certificate on bank and telco issued cards. Pekka Honkanen -Alkuperäinen viesti- Lähettäjä: Anders Rundgren [mailto:[EMAIL PROTECTED] Lähetetty: 30. lokakuuta 2003 23:46 Vastaanottaja: internet-payments Aihe: On-line signature standards Here is some information related to Internet payment gathered from a poll made to the IETF-PKIX, IETF-SMIME, and the OASIS PKI-TC lists regarding the current state of on-line signature standards = There are apparently no standards and nothing in the works either with respect to signing on-line data on the web using Internet browsers. = Since web-signing is today [*] used by many, many, more people and organizations than there are users of signed e-email, I remain puzzled. Is the PKI community really just a bunch of nerds, mostly out of touch with the needs of the market? And what good is a legal framework like the EU signature directive, intended to address legal interoperability if there is no interoperability in the technical solutions? The truth is [still] out there to travesty a famous TV series. However, my request spurred quite a lot of interest, so I believe that web- signing really is a thing that finally will be standardized. The question is more by who, as the major interest is really coming from the public sector, not from commercial entities like banks, that rather protect their investments in proprietary solutions. I personally plan to pusue such a task in W3C or in OASIS in case somebody is interested. *] Like Scandinavian banks having 0.5M of users. All current systems rely on entirely proprietary mechanisms
Re: VS: On-line signature standards
Lynn, To convert everything into a payment system is not a good way to discuss things. Identity Payment. So an issuer in the ID-world has no reason to ever get client signatures as the only thing an issuer of IDs can vouch for is the binding between a name (a.k.a. account number) and a public key. That means that in an ID-world using TTPs the transferal of the user's public key as a part of a transaction is indeed necessary. To use account numbers for issuer lookup does not work in an ID-world either as the very same account number (citizen name) may be issued. That is, my name is not Anders Rundgren, cid=4545454, @bigca, only Anders Rundgren, cid=4545454. To have the issuer sign this information like in a certificate is as you say redundant as this is what an on-line status service more or less already do. But I guess you can't accept the TTP-model at all as it builds on a model that does not work well for payments. But it does work fine for identities as identities don't go bankrupt, they only occasionally get revoked for some reason like a dropped card or a even case of identity fraud. Anders - Original Message - From: [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: 'internet-payments' [EMAIL PROTECTED]; pekka honkanen Welho [EMAIL PROTECTED] Sent: Sunday, November 02, 2003 16:03 Subject: Re: VS: On-line signature standards But the only business purpose for certificates is for trust propogation associated with offline operations (where the relying party has no access to the real and timely information and therefor must make do with stale, static copies). In the payment card scenario the merchant 1) doesn't need the public key since it relies on the issuer for an online authentication authorization 2) the account number is already part of the transaction 3) the account number already routes to the issuer 4) doesn't need the issuer's signature on a ceritifcate since it doesn't need the contents of the certificate and therefor doesn't need a signature on something that it doesn't need the merchant needs what's defined in X9.59 ... i.e. the data elements of the transaction and the customer's signature on the transaction ... all for forwarding to the issuer. http://www.garlic.com/~lynn/index.html#x959 so that is the 3rd party scenario. also, as previously outlined the issuer doesn't need a copy of the issuer's certificate since the issuer already has the original and therefor it is redundant and superfluous for the customer to send a copy of something back to the issuer where the issuer has the original. If you prefer, the description of of how to handle zero byte certificates; http://www.garlic.com/~lynn/aepay2.htm#position also how it is redundant and superfluous to transmit relying-party-only certificates back to the relying-party (i.e. since the issuing institution already had the original) http://www.garlic.com/~lynn/subtopic.html#rpo however the original thrust of the postings was to do with the foundations of trust ... as opposed to the foundations of trust propogation certificates are a method of popogating trust which is a separate business issue from establishing trust with regard to the validaty of electronic signatures. A digital signature can be viewed as part of a business process for establishing the basis for the business process of electronic signatures, specifically the authentication part of establishing electronic signatures. Legal electronic signatures require (at least) things like * authentication * non-repudiation * demonstration of intent and/or agreement Authentication can be thought of in the context of three factor authentication: * something you have * something you know * something you are So an electronic signature trust taxonomy * authentication - something you have - something you know - something you are * non-repudation * demonatration of intent and/or agreement Now I see no play where certificates play in the above trust taxonomy. Assuming the basis for electronic signature trust operation can be established then in business process that need trust progation in an offline environment where the relying-party has no other recourse, then one could conjecture the business process need for a stale, static credential like a certificate. previous posting http://www.garlic.com/~lynn/aadsm15.htm#32 As per above it is pssobile to establish a digital signature infrastructure which can be used to infer something you have (like an encrypted private key software file or a private key hardware token) and possibly something you know (an PIN to access the private key that performs the digital signature). There is even a possibility for digital signature infrastructure that can be used to inferr something you are (i.e. a certified hardware token that does digital signatures, but requires biometric input). Again there is no concept of a certificate and trust propogation associated with the use
Re: VS: On-line signature standards
Lynn. The problem in my opinion is that your ideas regarding the non-utility of certoficates is maybe another discussion than the legality of signatures. To the latter I have a fairly basic comment: Before the advent of signatures, legality in the e-world was not a major issue. To require three- factor authentication is fine but unlikely to work very as the basis for legal actions as you cannot trace the DNA of signer in the signature, sort of. Biometric have one possibly good application and that is as a protection against misuse of a signature device. Like featured on some of the more advanced HP PDAs. It may also work in bank vaults etc. However, as a over- the-net mechanism I believe biometrics is no good. Anders - Original Message - From: [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: 'internet-payments' [EMAIL PROTECTED]; pekka honkanen Welho [EMAIL PROTECTED] Sent: Sunday, November 02, 2003 18:11 Subject: Re: VS: On-line signature standards [EMAIL PROTECTED] on 11/2/2003 9:29 am wrote: Lynn, To convert everything into a payment system is not a good way to discuss things. Identity Payment. So an issuer in the ID-world has no reason to ever get client signatures as the only thing an issuer of IDs can vouch for is the binding between a name (a.k.a. account number) and a public key. That means that in an ID-world using TTPs the transferal of the user's public key as a part of a transaction is indeed necessary. To use account numbers for issuer lookup does not work in an ID-world either as the very same account number (citizen name) may be issued. That is, my name is not Anders Rundgren, cid=4545454, @bigca, only Anders Rundgren, cid=4545454. hum, lets see, what is the mailing list ... hum, it seems to be internet-payments? to the extent the previous posts had a discussion of a specific payment related scenario it was in response to a specific example you gave regarding possible compression of information in certificates. the original post and the majority of the subsequent posts was discussing http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda) basis for valid acceptable electronic signature. as mentioned before I outline previously there was a discussion of authentication specifically a commonly acceptable taxonomy for authentication, namely three-factor authentication: * something you have * something you know * something you are within the context of a acceptable legal electronic signature having to do with * authentication * non-repudiation * proving intent and/or agreement so I strongly assert that * authentication - something you have - something you know - something you are * non-repudiation * proving intent and/or agreement is not converting everyting into a payment system. It is trying to establish the basis for discussing, valid, legal electronic signatures. I possibly mistakenly assumed that with the subject line of on-line signature standards that just plausably there was some room for discussing valid, legal, electronic signatures. Futhermore, given that this particular mailing list is specifically titled internet-payments it wouldn't be completely unacceptable to include a single example of electronic signatures within the context of a payment system? The subject of identity is yet to come up? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
On-line signature standards
Here is some information related to Internet payment gathered from a poll made to the IETF-PKIX, IETF-SMIME, and the OASIS PKI-TC lists regarding the current state of on-line signature standards = There are apparently no standards and nothing in the works either with respect to signing on-line data on the web using Internet browsers. = Since web-signing is today [*] used by many, many, more people and organizations than there are users of signed e-email, I remain puzzled. Is the PKI community really just a bunch of nerds, mostly out of touch with the needs of the market? And what good is a legal framework like the EU signature directive, intended to address legal interoperability if there is no interoperability in the technical solutions? The truth is [still] out there to travesty a famous TV series. However, my request spurred quite a lot of interest, so I believe that web- signing really is a thing that finally will be standardized. The question is more by who, as the major interest is really coming from the public sector, not from commercial entities like banks, that rather protect their investments in proprietary solutions. I personally plan to pusue such a task in W3C or in OASIS in case somebody is interested. *] Like Scandinavian banks having 0.5M of users. All current systems rely on entirely proprietary mechanisms. Most of the vendors even require NDAs for getting the documentation. Anders Rundgren
Re: Four Corner model. Was: Confusing Authentication andIdentiification? (addenda)
"The four corner model is a valid business model with all four parties filling a valid business role totally independent of whether the delivery vehicle involves offline, stale, static certificates." On the contrary. If the TTP (credential issuer) is a part of a rust-network, the fourth corner (acquirer) is redundant as there is nothing a fourth party can add but costs[1]. That is, if we talk about authentication, and not about the transferal ofmoney. 1] Including: - Subscription fees, - Transaction fees, - Proprietary trust network software, - Relying party credential issuance and configuration - Trust network arbitration software I claim that the Four Corner model is the single most hampering thing to wide-scale PKI-deployment because it makes receivers' possibly pay for messages that they maybe did not even wanted! In paper-based messaging (excluding all kinds of payment systems), the "sender" typicallyputs on a stamp on a letter to get it distributed. This makes sense, four-corner does not. By confusing payments with authentication, the finical industry have shot themselves in the foot. Have anybody heard about a receiver-financed authentication trust network that actually makes money? Or have you recently SWIFT TrustActed? I don't think so. May I end this letter citing an interview with Bill Gates? Q: In 1995, you wrote in your book, "The Road Ahead," that IT will realize friction-free capitalism by excluding middlemen and directly connecting buyers and sellers. Do you still believe in the idea?A: Oh absolutely. I believe there should be no markup in any area of the B2B marketplace. If you want to buy and sell from anyone in the world, you should just get very inexpensive software. They'll let you see every seller and let you do complex transactions without anybody marking up the cost of what you're buying. XML Web services are needed for that, and that's what we're doing. It's a key building block of friction-free capitalism. Anders
Re: Confusing business process, payment,authentication and identification
I believe we are in agreement with what the fourth corner does in a trust network, it is like the relying party's insurance, link to the law, etc. A problem as I see it is what the fourth corner (or TPP CA) is prepared to vouch for in an non-payment situation. It can surely not make any warranties (in contrast to payments) about the value and credibility of the client, only that it has performed an RA and certification process according to some written practice statements. Does the RP need a business relation with the trust network in order to be able to sue a misbehaving client who is repudiating its actions? Some people claim that, I don't. If the signature can be technically derived to the client's key, the client is toast. Is the fourth corner is supposed to protect the RP from client key misuse/theft? I would say that this would be a very bad idea as the key may have been used to open information banks of incredible value that no insurance will cover and is not possible to rollback either. Authentication Payments! But if the faulty operation is due to certification errors, probably due to identity fraud? Then we enter the real CA liability scene. RP contracts have the same function as US SW licenses: To make you aware that nothing is really guaranteed, it is sold as is. Is this acceptable? This is hard to say, it is rather depending on how frequent errors are and the consequences of those. A problem is that a fourth corner can do nothing about identity fraud which in my opinion makes it less viable regardless of its possible legal value. So of course it is good to have business relations between parties in a trust network, but don't expect to get compensation when things go REALLY wrong. It is also rather hard to run court trials regarding information theft as it is hard to put a value on copied information. Due to these problems I believe the fourth corner is something that bank-operated trust networks should not take for granted. Particularly if it causes business parties to pay for received messages rather than (or in addition to) for sending messages. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 28, 2003 22:30 Subject: Confusing business process, payment, authentication and identification You may be absolutely correct that the Four Corner model is the single biggest inhibitor to the wide-scale deployment of PKI. The Four Corner model actually requires a legally binding chain of trust (somewhat analogous to chain of evidence in legal proceedings) as the fundamental basis for a real live, sound business-based, trust network. The majority of the PKIs are technical descriptions that wave their hands about trust networks but absolutely fail to provide any legally binding and/our sound business basis for trust operations and contractual recourse. Having a valid, real-live sound business trust network as a counter-example to some artifact that just waves its hands about being a trust network (w/o any sound business basis) is probably a real downer. Before continuing the description, I wonder if we can come to an agreement that we arent't talking about authentication and payment as purely academic, theoritic concepts totally unrelated to any useful purpose? Furthermore, can we agree that the majority of the people in the world aren't going out every day, entering retail establishments and performing random acts of payment and/or random acts of authentication unrelated to any useful business activity (aka they aren't at the retail establish to obtain goods or services, they are purely there to perform random acts of payment and authentication). That the payment and authentication constructs being discussed are occuring within the context of some business operation or purpose (nominally some exchange of value is occuring aka somebody buys something as opposed to giving away money for no reason what so ever). Furthermore, the traditional four corner model is slightly more than the guy trying to sell the brooklyn bridge and saying trust me, there are financially responsible parties for both the consumer and merchant with contracts and legal recourse (w/o the N times M scaleup problem requiring 120 billion independent contracts). The four corner model isn't trivial payment system for the enjoyment of people wanted to perform random acts of payment. As outlined in the original post, the merchant financial institution is the legally liable party for the merchant and the consumer/issuer financial institution is the legally liable party for the consumer. There are specific contractual and business relationships based on exchange of value that are the basis for this relationships. Asserting that the fourth party does nothing but add cost is like saying that the insurance business process does nothing but add cost. The four corner model is providing contractual legal recourse trust operating in both directions
Account Numbers. Was: Confusing Authentication and Identiification?(addenda)
A problem in this area is the all-over-the-map representation of entities when you go outside of the original (bank) account number. Well, even these show some variances, don't they? So when Lynn claims that the account number is redudant in for example certificates as it is already in the transaction payload, this is by no means a universal truth if you extend transactions outside of the financial area. In order to actually eliminate certficates or just be able to match the account number (the entity's identity) as expressed in a certificate with transaction payloads we need to have a universal naming method. Currently we don't have that. Even major B2B efforts like ebXML still have not solved this in an non-ambigous way. I.e, it is hard for many people to leave (or rather reduce the importance of) the attribute style of describing an entity's identity like: Locality, Common Name, Phone number etc. That hardly any business system in the world uses anything but a customer ID (account number) is still not generally recognized. I'm am plotting with an Internet Draft which defines a universal globally unique account number consisting of a 2-dimensional structure like the following: NameSpace : LocalID NameSpace is a Universal Resource Identifier (URI) that identifies the owner of the namespace. Samples: urn:visa:cc http://xmlns.ibm.com/employees LocalID is just a string that is guaranteed to uniquely identify the entity in the associated NameSpace. Samples matching the previous sample: 4656677756766 35467 For X.509 certificates there is a specific extension in preparation that enables the inclusion of such account numbers without disrupting the current use of Subject DN: /\ | CA | Naming Domain: http://sample-registry.org/members \/ PI Attribute: serialNumber / \ /\ / _\__ | /\ || EE | Subject: CN=John Doe, serialNumber=43155, C=US | \/ _|__ /\ | EE | Subject: CN=Marion Anderson, serialNumber=43566, C=US \/ That is, Marion's ID could using PI be expressed like: http://sample-registry.org/members; : 43566 As an option the permanent identifier descriptor MAY declare a separate PI naming domain.
Re: Largest Overhaul Of Check Processing In 50 Years In Sight
Did I read this correctly? Transferring _images_ of paper-checks? The US banking industry must be one of the most under-developed areas of the entire e-universe! Anders - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 16:31 Subject: Largest Overhaul Of Check Processing In 50 Years In Sight http://www.informationweek.com/story/showArticle.jhtml;jsessionid=BBDO3RNRETRB0QSNDBCSKHSCJUMEIJVN?articleID=10300733 Largest Overhaul Of Check Processing In 50 Years In Sight June 10, 2003 Congress is expected to pass legislation that would expand the use of electronic images of checks, saving banks billions of dollars. By Steven Marlin The process by which banks clear and settle billions of checks is about to get its biggest overhaul in 50 years, thanks to legislation making its way through Congress. The Check Clearing for the 21st Century Act, Check 21 for short, would expand banks' ability to exchange electronic images of checks instead of the paper originals, saving them billions in transportation and related costs. Today, banks can only exchange check images through bilateral or multilateral agreements. Check 21 eliminates the need for such agreements, freeing banks to transmit images at will. .. snip .. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
FINREAD was. Authentication white paper
regarding the references to FINREAD I believe the vision as represented by the following document http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html has little foundation in reality. I.e. reading current king-sized smart credit cards in mobile phones or PDAs seems like a rather complex idea taking in consideration the proliferation in the card sector. AR - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 08, 2003 21:23 Subject: Authentication white paper I'm in the process of finishing up an authentication white paper for an international financial best practices security book. Much of it reflects the various deliberations that went on in the x9a10 committee for the x9.59 standard (requirement given the x9a10 committee to preserve the integrity of the financial infrastructure for ALL electronic retail payments; aka ALL as in not just internet, not just point-of-sale, not just credit, not just ACH, etc). Some specific issues related to the X9A10 committee work: A taxonomy for security is PAIN P ... privacy A ... authentication I ... identification N ... non-repudiation A taxonomy for authentication is 3-factor authentication. something you have (aka hardware token) something you know (either shared-secret or non-shared secret) something you are (biometrics, again either shared-secret or non-shared secret) While x9.59 primarily deals with strong authentication for financial transactions, the original chair (Tom Jones) of X9A10, put a lot of early work into non-repudiation for financial transactions. This effectively took the form of cosigning the early X9.59 work went on contemporary with the fstc/echeck work on people authentication cosigning (and FSML encoding, a lot of which has been folded into XML digital signature work). While neither kind of cosigning actually show up in the x9.59 standard, the standard was carefully written in such a way as to not preclude either form of cosigning. The concept behind Tom's work on consigning is synergistic with the EU FINREAD (financial reader) standard. In the past, there had been quite a bit of confusion generated somewhat assuming that non-repudication and authentication could possibly be equivalent. This was possibly something of semantic confusion with the term digital signature somehow taken to be the equivalent of a human physical signature and all that it implies with respect to intention, agreement and non-repudiation. The FINREAD standard has a token acceptor device that is certified to display the value of the financial transactions followed by the entry of the hardware token PIN/Password (prior to the token performing authentication; as well as guaranteeing the value displayed is what is sent to the token for authentication). The simple design of a two-factor authentication system involves a PIN/Password that activates a hardware token performing a digital signature for authentication. The hardware token has been certified to not perform a signature unless the correct PIN has been entered. The existence of a digital signature then demonstrates possession of something you have token and implies that the correct something you know PIN was entered. However, just because two-factor authentication was demonstrated, it hasn't demonstrated that a person has read and agreed with something. Intention and non-repudiation becomes a process that includes some human interaction. The EU FINREAD standard certifies a token acceptor device that implements a process that provides some degree of assurance that the process for non-repudiation/intention has been met, aka the correct amount was presented on the display, followed by explicit human interaction (typing the correct PIN on the pad immediately below the display), and that the value presented to the token for signing matched what was on the display. In the case of a certified token, two-factor authentication can be inferred because the token will not have been performed w/o the correct PIN having been entered. In the case of certified FINREAD terminal, non-repudiation process can be inferred because the FINREAD terminal requires the PIN to be entered after the transaction has been displayed, and the FINREAD terminal guarantees what was sent to the token for signing is what is displayed and is sent after then PIN has been entered. The big difference between the current EU FINREAD standard (certified terminal attempting to establish the basis for inferring intention and/or non-repudiation) and the early X9A10 work by Tom Jones, was that Tom wanted the certified terminal/environment to cosign the transaction thereby proving that the signing actually took place using a certified terminal/environment. The existing FINREAD standard establishes the criteria for a certified signing environment/terminal (required for inferring intention/non-repudiation) but doesn't (yet) require proof that the
Re: EMV: Likely to be DOA
Dave, The new Chip and Pin schemes address security in the real world while 3-D Secure goes some of the way to address security in the on-line world. I have yet to see a cost effective solution for both environments. This is the interesting part. In what way is 3D secure more expensive to handle than EMV (assuming that on-line controls are performed)? An assumption: Broadband Internet access will be ubiquitous, cheap and reasonable reliable within 2-3 years from now. Regards Anders R
EMV: Likely to be DOA
EMV: Likely to be DOA == EMV = Europay MasterCard VISA standard for a payment card DOA= Dead On Arrival In an off-line world which was the foundation for the EMV specification, you essentially only can build a more secure locally verifiable payment system. Having an on-line world you can instead put the question: What do CUSTOMERS want to do, payment-wise? But the EMV consortium rather put the question: what do WE (as payment organizations), want to offer to the ISSUERS? I claim that large corporate customers have needs that no card- scheme support and will never be able to do either. Such as: - Virtual purchaser card distribution performed in-house - Local control of purchases and purchasers before the actual transaction is performed - A unified card system for local and on-line purchases Is this possible to achieve? Yes, trials will begin in selected areas in 18 months or so. The on-line paradigm changes [almost] everything. Sincerely Anders Rundgren
Re: Nordea: e-ID in the bank card
Scott, End of story? Well, banks have a problem: They have so far been unable to share RD efforts in a good way. That's the major reason they have failed to establish a standard PKI-card in spite of having used PKI since ages back. The banks will [have to] use the solutions that are available which in pretty short time will be the mobile phone. Even a small one will be sufficient for many operations. Note that not even the biggest Smart Card makers have made their software available for free. They are just waiting for their own marginalization! Also note: Keys will NOT be put in the SIM. http://www.arm.com/news/TrustZone270503 Another end of story :-) Anders - Original Message - From: Scott Guthery [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 02, 2003 18:18 Subject: RE: Nordea: e-ID in the bank card Anders: Make battery life 5 years. Give the SIMs 16 MB and 4096-bit private keys with sub-second signing. Provide secure PIN entry, a root certificate and touch screens in every handset. There is only one interesting question: Who do I sue when it doesn't work? Telia? Schlumberger? Nokia? Ericsson? You? It's not about technology. It's about accepting liability. Banks do it. Telcoms don't. End of story. Cheers, Scott == The Swedish branch of Nordea is planning to combine bank cards with electronic identity. Putting an electronic ID in a bank card To put an electronic ID (usually in the form of PKI) in a [smart] bank card has been mentioned quite often by bank-people as a great idea. The author of this letter is largely unconvinced of the merits of such a system. Below are some reasons for this. 1. An account is a shareable resource, while a personal ID is not, which makes such a resource mix principally rather dubious. 2. Having an on-line world and assuming that the user can be sufficiently authenticated, the distribution of static account resources like EMV becomes completely redundant. 3D Secure (et. al.) shows the way forward not only for payments but for many other usages. 3. Putting an ID in a mobile phone having extensive local and remote communication facilities eliminates the need for card readers completely, as well as supporting numerous usage scenarios that physical bank cards will never be able to do. A question arises; will this third thing ever happen? Progress has indeed been very limited. Due to things like battery capacity improvements, crypto hardware improvements, and deprecation of the operators' SIM-based solutions we should expect some major action in this area the coming 18-36 months. In addition, Microsoft's entrance in the mobile phone market, will also put pressure on the other players as Microsoft in their next update claims to have about the same PKI support in their two phone OSes, as has been available in Windows for years. Sincerely Anders Rundgren Project leader for one such mobile phone-based PKI project, occasionally referred to as the smart card killer. +46 70 - 627 74 37 --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Nordea: e-ID in the bank card
The Swedish branch of Nordea is planning to combine bank cards with electronic identity. Putting an electronic ID in a bank card To put an electronic ID (usually in the form of PKI) in a [smart] bank card has been mentioned quite often by bank-people as a great idea. The author of this letter is largely unconvinced of the merits of such a system. Below are some reasons for this. 1. An account is a shareable resource, while a personal ID is not, which makes such a resource mix principally rather dubious. 2. Having an on-line world and assuming that the user can be sufficiently authenticated, the distribution of static account resources like EMV becomes completely redundant. 3D Secure (et. al.) shows the way forward not only for payments but for many other usages. 3. Putting an ID in a mobile phone having extensive local and remote communication facilities eliminates the need for card readers completely, as well as supporting numerous usage scenarios that physical bank cards will never be able to do. A question arises; will this third thing ever happen? Progress has indeed been very limited. Due to things like battery capacity improvements, crypto hardware improvements, and deprecation of the operators' SIM-based solutions we should expect some major action in this area the coming 18-36 months. In addition, Microsoft's entrance in the mobile phone market, will also put pressure on the other players as Microsoft in their next update claims to have about the same PKI support in their two phone OSes, as has been available in Windows for years. Sincerely Anders Rundgren Project leader for one such mobile phone-based PKI project, occasionally referred to as the smart card killer. +46 70 - 627 74 37
Re: Solving the problem of micropayments
I have some objections and question to this. 1. Anonymity does not seem to be supported. Isn't that a key for any kind of petty-cash replacement? 2. Although Mr. Rivest probably have had great use of his share of the RSA IPR, times have changed and patents have become out-of-fashion, particularly in the Europe. Anders - Original Message - From: MacDougall, Alan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 19, 2003 22:20 Subject: RE: Solving the problem of micropayments It's a *very* nifty idea. I saw Ron Rivest's presentation on it at RSA 2002 - the powerpoint is here: http://theory.lcs.mit.edu/~rivest/MicaliRivest-MicropaymentsRevisited.ppt and the actual paper (a bit technical) is here: http://theory.lcs.mit.edu/~rivest/MicaliRivest-MicropaymentsRevisited.pdf later Alan -- Alan Macdougall, E-Commerce Strategy Team The National Bank of New Zealand Ltd http://www.nationalbank.co.nz -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Sent: Thursday, February 20, 2003 9:58 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Solving the problem of micropayments Great idea. It uses nothing more than what we all learned in high school math (except for the part about securing the coins). Alan This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you.
Re: CMS sets health care e-payment standards
I only read some of the executive-level information. It is hard to see that encrypted mail to clients/patients is the future. Besides the fact that the following has (hopefully questionable) US IPR attached to it, I propose other measures. DISTRIBUTING SENSITIVE INFORMATION TO INDIVIDUALS Here are some thoughts regarding how e-governments (and companies) could efficiently distribute confidential information to citizens (or employees). Note: The following discussion only applies to information from an (non-personal) authority to an individual. Claim --- In spite of being the foundation for many PKI-based ID-programs, I doubt that S/MIME will play any major role in e-government systems as these typically are built as on-line (web-based) services. The problem -- Now, in case a government authority is to send you confidential information, I believe they should not use encrypted mail as this will most likely lead to huge support problems with key- distribution, key-expiration, long-term storage etc. A simple remedy - e-Governments could preferably e-mail the recipient a web-link (or just a notification) that he or she uses to fetch the confidential information with. That is, after the recipient have authenticated to the on-line authority. This scheme is also aligned with an account-based authority where you may have tasks in various stages. The web-way allowed on-line banks to address the ordinary consumer and is proven to work on a major scale, while signed and encrypted mail is after more than ten years, still very sparsely used. My 2 cents. Anders Rundgren Consultant, PKI and secure e-business +46 70 - 627 74 37 - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 22, 2003 13:53 Subject: CMS sets health care e-payment standards http://www.computerworld.com/governmenttopics/government/policy/story/0,10801,78722,00.html CMS sets health care e- payment standards By Bob Brewin FEBRUARY 21, 2003 Content Type: Story Source: Computerworld The Centers for Medicare Medicaid Services (CMS) yesterday published its final rules for electronic health care payment transactions (download PDF), adding what vendors and consultants see as yet another burden to an industry scrambling to meet new privacy and electronic security requirements (see story). .. snip .. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Re: Intertrust, Can Victor Shear Bring Down Microsoft?
Being relatively uninterested in bringing down Microsoft, but extremely interested in the key to secure commerce, I wonder if someone can shed some more light on this fantastic technology that took more that 3 years to productify? http://www.intertrust.com/main/overview/trustcomputing.html Paying $400M for a 39-person company seems a bit steep these days but who knows Anders - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; internet-payments [EMAIL PROTECTED] Sent: Saturday, December 21, 2002 21:33 Subject: Intertrust, Can Victor Shear Bring Down Microsoft? http://www.fortune.com/fortune/print/0,15935,400412,00.html INTERTRUST Can Victor Shear Bring Down Microsoft? Maybe not. But his company's patent suit is the biggest legal threat to Microsoft since the antitrust case. FORTUNE Tuesday, December 17, 2002 By Roger Parloff Imagine you had a nickel for every compact disc that's ever been made. The patent holders of the CD technology do have nearly all those nickels. Sony Corp. of America and Royal Philips Electronics get 3 cents for every CD manufactured, plus 3% of the price of every CD player sold. .. snip ...
Re: EMV, 3D and MobeyForum
Arjeh, That would of course work. The reason I would not do like that is that it seems like an ID-certificate would be more useful in other contexts than a credit-card certificate. Anyway, this is a competition with time and market acceptance. Anders Rundgren - Original Message - From: Arjeh van Oijen [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED]; internet-payments [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 21:22 Subject: RE: EMV, 3D and MobeyForum Anders, Why not use EMV (implemented in a smart card or SIM) also for the identification/authentication of the wallet holder when 3D sheme is used ? Arjeh van Oijen. -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: maandag 9 december 2002 19:23 To: internet-payments Subject: EMV, 3D and MobeyForum According to MobeyForum EMV should be used for local payments and 3D Secure for remote payments. What is the point of having two entirely different ways to pay using a mobile phone? Using 3D, the banks need only issuing a single digital ID as the same ID can be used for on-line banking. /anders
Re: First Data Unit Says It's Untangling Authentication
Lynn, You must join the new OASIS PKI TC that is trying to address why PKI have failed. Note: I don't share your view that TTPs are useless, as entire societies are built on TTPs. I.e. governments. Hopefully CAs can do better than governments as the former's tasks are better defined and very limited. Note also that FirstData's system as well as AADS have a rather limited scope with respect to transactions. For B2B-messaging in general, AADS falls short as AADS in only suitable in a bilateral relation. That does not mean that FD or AADS is wrong, it is just the universality, I claim is a bit exaggerated. Anders - Original Message - From: [EMAIL PROTECTED] To: internet-payments [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, December 09, 2002 21:37 Subject: First Data Unit Says It's Untangling Authentication cross-post thread from another mailing list: http://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication and somewhat related thread in sci.crypt ng: http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
EMV, 3D and MobeyForum
According to MobeyForum EMV should be used for local payments and 3D Secure for remote payments. What is the point of having two entirely different ways to pay using a mobile phone? Using 3D, the banks need only issuing a single digital ID as the same ID can be used for on-line banking. /anders
Identification = Payment Transaction?
Survey regarding the future of PKI trust networks -- Traditionally certificates have been purchased (or just issued) for an entity by a party that is concerned that the entity can be properly identified in authentication- and signature-operations. For a relying party (RP) to check certificate-status has mostly been a public and free service. The financial industry however, have in several recent PKI-ventures shown that they intend to change this by treating lookup-services as equivalent to payment transactions, where the RP's bank is used as a trust clearing center communicating with the subscriber's bank that must be a member of the same trust network. To make it technically impossible for RPs to fully verify signatures without going through the trust network (and paying for the services), root-certificates are usually not published. I would be very happy to hear what the PKI community in general think about this scheme as the future for PKI. Off-list responses will be treated as CONFIDENTIAL information. Anders Rundgren
Re: Identification = Payment Transaction?
Ed, The PKI industry frequently uses the word trust to describe their services and products. From an academic point of view this may be wrong but actually even authentication and authorization are confused. I can live with that as well, as a signed purchase order is by common practice considered as being authorized if it is found to be authentic. Anyway, the question was really about the business model behind PKI which basically falls into four categories: - Private/local PKI. A cost model only. - Unilateral TTP. Subscriber-financed. - Trust-network. All members pay - RP-only TTP. The relying parties only pay for verifications Anders - Original Message - From: Ed Gerck [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: internet-payments [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 20:03 Subject: Re: Identification = Payment Transaction? Anders: PKI has nothing to with trust, and does not even define trust, so your title does not compute. Perhaps you mean PKI authorization networks? Quite often, when people talk about trust they really mean authorization -- but use trust because trust sounds better ;-) Cheers, Ed Gerck Anders Rundgren wrote: Survey regarding the future of PKI trust networks -- Traditionally certificates have been purchased (or just issued) for an entity by a party that is concerned that the entity can be properly identified in authentication- and signature-operations. For a relying party (RP) to check certificate-status has mostly been a public and free service. The financial industry however, have in several recent PKI-ventures shown that they intend to change this by treating lookup-services as equivalent to payment transactions, where the RP's bank is used as a trust clearing center communicating with the subscriber's bank that must be a member of the same trust network. To make it technically impossible for RPs to fully verify signatures without going through the trust network (and paying for the services), root-certificates are usually not published. I would be very happy to hear what the PKI community in general think about this scheme as the future for PKI. Off-list responses will be treated as CONFIDENTIAL information. Anders Rundgren
Re: [3d-secure] 3D Secure and EMV
Todd, Things tend to go in phases. Phase #1 is to create the technical foundation for a PTD and to exploit the current money architecture. If there is another way of using money, I see no problem for a PTD to use that as long as the basic technology is more or less the same. Which I think it ought to be. Note though that a PTD has many important functions outside the territory of payments. It is rather an intelligent key-ring that is the value proposition. The key-makers will be the next big camels using your terminology. It is either VeriSign or the banks. Anders - Original Message - From: Todd Boyle [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Internet-Payments' [EMAIL PROTECTED] Sent: Monday, July 29, 2002 00:02 Subject: Re: [3d-secure] 3D Secure and EMV But PTDs suffer from political problems of a magnitude that few understands the consequences of. Regardless of the politics within telecoms or banking industries none of their PTDs will succeed until it provides the owner with final, unquestionable privacy and sovereignty to exchange value *with other peers* with only the essential minimum of support by any central server. The MeT PTD for example, represents the noses of several rather large and smelly camels, entering the tent: telecom operators, RAs, software vendors, others. Individuals and SMEs feel that our tents are already crowded with Bank camels and Government camels in our beds (and collecting money from us). The tech. sector has tried 100 cheap tricks, with all kinds of transparent gimmicks which have all failed to entrap today's consumer. There are plenty of example that don't have the drawbacks of the cellphone operator implementing MeT PTD. Something like the gold-backed digital currencies, or webfunds together with an open source issuance server may eventually reach critical mass. Webfunds baked into a handheld device would be a sort of PTD isn't it? Or, if the GBCs agreed on a standard protocol there might be a standard GBC client in firmware. Would you regard that as a PTD? Respectfully, Todd www.gldialtone.com At 03:00 AM 7/28/2002, Anders Rundgren wrote: Amol, This is my absolute favorite tech-topic since 4 years back! Don't expect anyone important to say something on this as this is simply too hot to handle. The biggest problem is really that we still don't know when the PTD (Personal Trusted Device) will be ready. Such a device would kill the smart-card (in their current form) but not if it takes forever to them on the market. But PTDs suffer from political problems of a magnitude that few understands the consequences of. There are three players:TeleComOps, Banks and CreditCard networks. Originally TeleComOps thought this was their game (and so did the terminal makers), but I think it is more leaning towards the others today. Technically the question is really (using PTDs): Why bother with EMV when an ID does it all? Long-term it would mean that client-based credit-cards (all forms) would dissapear entirely. Rant But given the banks' inability to cooperate and work with open standards in _open_ foras, I suspect that solutions will (as now) be all over the map and cost customers a fortune. /Rant I.e. we will probably use 3D on the net, EMV in the shop etc. But in the US, EMV will never catch on which means that every shop must handle the current system until the PTD takes over. EMV on the Web? I would be very surprised if this happens as 3D is simply a much better idea. Using extensions like .PAY, no client-based credit-card solution even comes close. cheers, Anders - Original Message - From: Amol Natu [EMAIL PROTECTED] To: [EMAIL PROTECTED]; 'Internet-Payments' [EMAIL PROTECTED] Sent: Sunday, July 28, 2002 09:28 Subject: RE: [3d-secure] 3D Secure and EMV Hi Probably this topic posed by Anders got missed out ... I would like to understand the path that internet payments would take once EMV cards are rolled out. To my knowledge, banks implementing smart cards see no effect on internet payments at this point in time i.e these payments will continue to be non-authenticated and move to 3D secure in due course. Once there is a large mass of smart card holders, would banks go ahead with equipping them with readers ? How would this affect 3D ? Which authentication would prevail ? Any thoughts ... Is the PC industry moving towards having smart card readers as default hardware ... Cheers Amol P.S. can someone send me links to popular EMV related mailing lists ? -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 16 July, 2002 11:08 PM To: [EMAIL PROTECTED]; 'Internet-Payments' Subject: [3d-secure] 3D Secure and EMV It has been mentioned but I cannot find where that 3D Secure and EMV have a future together. Can anyone enlighten me how? In my opinion 3D Secure by using delegated signatures (in contrast to SET's direct signature approach
Re: 3D Secure Protocol Oddity
Thanx Lynn, But I don't understand if you are supporting my view or not :-) In case it was against, I think you should take a deep look on 3D to verify that it is as far from end-to-end that is technically possible. The widely used method I suggested, is definitely end-to-end in my opinion (although not in X9.59 that requires local signatures which is not a part of the 3D protocol). Anders - Original Message - From: [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: internet-payments [EMAIL PROTECTED] Sent: Tuesday, July 02, 2002 11:32 Subject: Re: 3D Secure Protocol Oddity I think one of the analysis done by the x9a10 comittee was about end-to-end security with flow thru transaction protocols effectively the current web, POS, non-web, etc message path sequence but with the transaction carrying end-to-end consumer authentication of the message (aka the x9.59 standard). I think that it is fairly standard fault, integrity and security analysis that an end-to-end flow-thru authenticated message is always significantly better than any multi-legged message protocol. Anders Rundgren anders.rundgren@ To: internet-payments telia.com[EMAIL PROTECTED] cc: 07/02/2002 02:38 Subject: 3D Secure Protocol Oddity AM List, An oddity in the 3D Secure protocol is in my opinion that the final and critical transaction is routed through the user's browser. Working for years with systems like OBI, Punchout, OCI where the final message is a purchase order, I note that these system are characterized by sending the final transaction server-to-server. This is based on the idea that your purchasing system (or in the case of 3D your bank) is a business system helping, and monitoring your business processes which means that it should now about problems before the you do (If a 3D transaction fails, your bank will know nothing, and since a failure can occurr anywhere, there are situations were no one will know what's happened). Interactivity is by no means hampered by this arrangement, it just means one [optional] step more communication-wise but with greatly improved tracibility. Cheers, Anders If you want, you can try out https://buyer.x-obi.com/BuyerASP/buyer and verify that ending a shopping-session in the business-system-end is not at all bad, rather the contrary. Takes some 10-15 minutes to perform.
