B2B & Transaction PKI

["Anders Rundgren" <anders.rundgren@telia.com>]

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

----- Original Message -----

From: "Arshad Noor" <arshad.noor@strongauth.com>

To: "PKI TC" <pki-tc@lists.oasis-open.org>

Sent: Friday, December 16, 2005 01:49

Subject: Re: [pki-tc] Re: Transaction PKI. Was:PKI-TC@PKI Workshop

No, not an e-mail system, but an end-to-end encryption system, 
along
with a signing system.

There is a business requirement in some 
industries - financial & health
care - to encrypt data from the moment it 
is captured in a form.  While
today's specific requirements can be met 
with back-end encryption, I
anticipate that those requirements will encompass 
end-to-end encryption.

If we are going to attempt an effort to define 
something for the web
browser for signing, then why not address encryption 
too at the same
time.  The effort is identical for the browser vendor 
(in terms of
exposing an API that allows web applications to access the 
key-store)
regardless of whether its signing or encryption.

The 
capability in the browser is intended to be interactive.

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.

Arshad Noor
StrongAuth, 
Inc.


Anders Rundgren wrote:
> You seem to actually acknowledge 
that you are trying to create an
> e-mail-like system instead of an 
interactive signature scheme for web?
> 
> As interactive services 
made Google the biggest star in the IT-world in
> a decade, I think 
skipping interactivity is a considerably bigger issue
> than skipping XML 
encryption.
> 
> I think it would be wise to list the applications 
the AG SC are targeting
> to shed some more light on these issues.  I 
also think that a B2B use-case
> needs a description, or is B2B out of 
scope?
> 
> Regarding the ill fate of secure e-mail, I agree, but do 
not believe that
> this has much to do with limitations in the S/MIME 
format vs. XML.
> 
> thanx
> Anders
>