[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pki-tc] B2B & Transaction PKI
Anders, Perhaps it is my interpretation of B2B that is inconsistent with yours. Let me define my interpretation so we can be assured we're talking about the same thing. B2B in my interpretation, is: non-GUI software products, transacting programmatically with each other, without human interaction. An inventory control module in SAP that automatically sends out a Purchase Order to a suppliers' Oracle server over some protocol; money transfers between banks and the Fed/Treasury; tax information from PeopleSoft Payroll to the IRS (in the US); etc. An employee of a bank, ordering office supplies from the corporate stationery supplier, using the web interface supplied by the supplier is not a B2B transaction in my interpretaion. A corporate travel agent making reservations on an airline for a traveling executive, using the airline's website is not a B2B transaction. The corporate tax accountant filing quarterly tax returns at the IRS website using the web interface provided by the IRS is not a B2B transaction. I veiw them as variants of B2C/G2C transactions, even though the two parties in the transactions are businesses. So, when I said that we don't need to address B2B, I meant that this SC does not need to address the security requirements for non-GUI software modules communicating with others, as XML Signature and XML Encryption address those requirements, as does WSS (for XML type data structures). Businesses have always had the ability to add message level security for "B2B" transactions using other forms of security in the past - S/MIME (as Dale pointed out yesterday); Secure RPC; PKCS#7 (using whatever transport you desired) - or just plain vanilla VPN's if message-level security was not critical. So, to clarify, the Transaction PKI effort will specifically focus on Browser-to-Application security. If this is inconsistent with the expectations of the TC and the Steering Commitee, I trust that members of this alias will correct me. Arshad Noor StrongAuth, Inc. Anders Rundgren wrote: > Arshad, > Your response created a myriad of questions but since nobody has the > time to read those I will focus on a single item. > > You wrote: > /I don't believe we need to address B2B, since that is acheivable today > either through XML Signature & XML Encryption directly (reference > implementation available from Apache at > //http://xml.apache.org/security///) or indirectly through OASIS-WSS - > which uses XML Signature and XML Encryption. A reference implementation > of XWSS is also available from Sun at > //http://java.sun.com/webservices/downloads/webservicespack.html//. > Businesses just need to start using these API's now to secure their > applications./ > // > This answer leaves me with two possible interpretations: * > **1*) The Transaction PKI project is /unrelated/ to B2B. It is in this > context worth noting that the majority of /current/ B2B transactions are > indeed invoked by web-browser-based applications. * > 2*) The Transaction PKI project aims to /remove/ (implied by > the end-to-end encryption scheme) /SAP and similar business systems from > the B2B process/. > > /Note of these interpretations look particularly attractive in my opinion./ > > Since the Application Guidelines SC has not produced any documentation > regarding how Transaction PKI is to be applied to B2B (or to anything > else either for that matter), I will post a minimal specification ASAP, > hopefully bringing up some interesting questions on the table. > > Regards > Anders > /
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]