OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pki-guidelines message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pki-tc] B2B & Transaction PKI


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]