Re: [ebxml-dev] ebXML security

[Todd Boyle <tboyle@rosehill.net>]

At 03:37 PM 8/8/2002, Douglas Nelson wrote:
>I would like to start a thread of security issues to discuss what features 
>need to be included, interfaces, we would like to have and general 
>discusses of each of the primary features.

There is a well-known business need among all types of users
(Enterprise, SMEs and Individuals) to determine the bonafides of
potential customers before shipping on account, and suppliers
before getting involved in purchases.

Historically, parties have relied on the major credit agencies,
casual checking of references, and other procedures which
are expensive, consume time, and are not reliable or predictive.

Considering the encryption and other features already included
in ebXML or implied in the list below, a reputation framework
is reasonably achievable.

Any electronic interaction enables objective, empirical facts and
statistics to be stored, about commitments made and the fidelity
of performance over time.  This can be done by a trusted
host or federation of providers.  It can also be done using
signatures and other cryptographic algorithms that provide
parties with the independent capability to strongly prove their
past performance in great detail.

Algorithms exist which also enable unveiling only statistics and
partial views that prove a general point without disclosure of the
complete detail of parties, products or business strategy. The
most simple of these for example might involve both parties
signing any arbitrary fact such as their 2nd quarter total
dollar volume, in order to prove that to creditors or auditors
without immediately revealing the details.

Algorithms exist that give either party an independent ability
to prove certain kinds of derived facts, like total sales by
owning the encryption key to each of N separate sales,
without the assistance of any B2B hub, or the other party.

Algorithms exist that enable "nymous" commerce-- operating
partially or totally anonymously.  Total anonymity is of little
commercial value outside of near realtime, e-gold, STP,
RTGS, etc.

But partial anonymity provides a decent level of veiling
comparable to physical buy/sell in a retail store, etc.
while still nailing down, totally, those facts necessary, or
required, by either of the sovereign parties.  The Identity
data surrounding purchase, therefore becomes part of the
consideration in contract.

My impression is, these capabilities are achieved at the
level of the collaboration or the transaction rather than at
the TPA or messaging layer.  However, it might be possible
to use some of the infrastructure of the lower layers to reach
these goals.

eBay illustrates the potential benefits of even a weak
reputation framework.  eBay is nothin' compared with these
potential possibilities of long term, persistent empirical
reputation owned by parties to transactions without the
loss of privacy or risks of control or rent collecting by
central hosts.   You have to understand, we have today,
absolutely zero independent capability for credit and
reputation.  This spawns the requirement for cash
and bank infrastructures which are so costly.  With a
framework for permanent, P2P identity and reputation,
things would be much different.  All the people who
have gone their whole life behaving honestly and
paying their debts would, in the aggregate form a whole
parallel economy with much lower costs, higher
productivity, and lower crime, generally requiring no
support or supervision by governments, lawyers, etc.

Electronic reputation gives technological manifestation
to the highest impulses of western civilization,

Todd Boyle CPA

At 03:37 PM 8/8/2002, Douglas Nelson wrote:
>I would like to start a thread of security issues to discuss what features 
>need to be included, interfaces, we would like to have and general 
>discusses of each of the primary features. I am thinking the features 
>should be available as web service and as an API possible an addition to 
>the java core api's for web services. I would be interested in what you 
>guys have thinking about security.  This first cut at the primary 
>features,  you guys come up with any more, might include the following:
>    * Administration – An administrator shall have all the tools necessary 
> to define and maintain roles, monitor all security aspects of the 
> framework and to perform maintenance on any of the security modules.
>    * Auditing – The administrator shall be able to return the framework 
> to any previous state on any given day, view logs and to track changes to 
> the system by other authorized users and administrators.
>    * Authorization – The framework shall provide a mechanism that will 
> allow an administrator to define roles to access confidential data and 
> resources.
>    * Authentication – The framework will uniquely identify a user by user 
> id and password or the acceptance credential information from a federated 
> third party server.
>    * Certificate Management – The administrator will have the ability to 
> accept, delete, track certificates submitted from a trusted third party 
> on behalf of all users registered to the framework.
>    * Encryption – The framework will provide API (Application Program 
> Interface) to support encryption of all or part of an XML (eXtensible 
> Markup Language) message document.
>    * Monitoring – The framework will monitor and issue alerts to 
> administrators and support personal when errors, exceptions or general 
> failures occurs.
>    * Planning for Evolution – The framework will be architected in a 
> object oriented modular fashion to allow new open standards to be 
> introduced without have to effect the pre- established API’s or web services.
>    * Privacy – The framework will provide a mechanism that will allow 
> documents to be classified and encrypted so that the document may only be 
> view by those to whom the document was intended.
>    * Redundancy – The framework will have the ability to be load balance 
> and fail over to additional servers.
>    * Single Sign On - User will have the ability to log on to any of the 
> trusted federated server and be authorized to access data and services by 
> user id and password or any additional federated servers providing the 
> appropriate credentials.
>    * Time Stamping – The framework will have the ability to sync its 
> internal clock to government run time sync servers to maintain accurate 
> logging and saving of documents for non-repudiation.
>Thanks Doug
>