B2B & Transaction PKI

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" <>

To: "PKI TC" <>

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
>