FYI...please send feedback to [EMAIL PROTECTED]
thanks,
dims
-- Forwarded message --
From: Granqvist, Hans [EMAIL PROTECTED]
Date: May 17, 2005 6:10 PM
Subject: [PROPOSAL] Apache TSIK
To: general@incubator.apache.org
Proposal
This is a proposal to submit the Trust Services Integration
Toolkit (TSIK) to ASF. TSIK is a Java toolkit that VeriSign
has been developing since 2001, and it is the basis of several
products developed by VeriSign.
The intent with Apache TSIK is to create a web services project
to implement standards as defined by W3C, OASIS, and others:
* Basic XML security standards (XML signature, XML encryption)
* WS-* standards, and
* Other related standards (for example XKMS and SAML)
A full list of standards can be found at the end of the email.
Emphasis has so far been placed on security-related standards.
TSIK is a toolkit that is suitable for implementing client as
well as server side components. Several commercial products built
using TSIK are in current use.
Rationale
-
It is easy to misunderstand the sometimes complex XML security
standards. We have found that improper use of APIs inadvertently
cause most security issues.
TSIK was therefore designed to be simple and easy to use. Rather
than trying to implement 100% of a specific standard, we wanted to
provide simplified APIs that would make sense in most use cases.
However, what's implemented will always be to specification.
VeriSign believes the slow pace of adoption of Web Services can be
attributed partly to the lack of open source toolkits. We believe
that making a toolkit like TISK available to the community will
increase the momentum.
Currently Apache offers two projects related to Web Services
security:
a. The XML security project, which implements basic XML signature
and XML encryption, and
b. The WS-FX project, which aims at implementing existing WS*
standards.
The WS-FX project is an umbrella for several sub projects. The
composability of WS standards means that a division into a
subproject structure is reasonable. WS-FX's main emphasis, though
not the only way of deployment, is by way of Axis filters.
We propose TSIK as a separate project, somewhat competitive to
WS-FX, but focused more on a toolkit usage model. Within the ASF,
there are already examples of more or less competing projects
(e.g., XML parsers). There is a belief that such internal
competition is healthy.
There are a number of Java Community Process JSR's in various stages
of development. These JSR APIs will probably end up in ASF projects,
some sooner than later. For example, JSR-105 (XML digital signature)
is already in the final stages and its APIs will likely in time
supplant or complement the current Apache XML security suite.
Other JSR's of interest include JSR-106 (XML encryption) and JSR-183
(WS-Security), which will also migrate to a set of APIs that will find
their way into Apache.
The JSR APIs often strive to completely implement each specification.
While this is sometimes valuable, few applications use more than the
most common functions. Again, TSIK is designed to simplify security
usage as much as possible.
The long term goal of TSIK could be to use existing underlying
Apache projects, such as XML security suite.
The initial implementation will be in Java, with support for J2SE
1.3 and up.
As a main author of many WS standards, VeriSign will also work to
resolve the IP issues regarding some WS* standards.
Scope
--
TSIK will implement the WS-* stack of standards. To do this, basic
XML security standards need to be implemented, as discussed above
in the introduction. Most of this functionality already exists in
TSIK.
Our initial plan is to implement support for the following
specifications in this order: WS-Security, WS-Trust,
WS-SecureConversation (WS-Addressing), WS-SecurityPolicy (WS-Policy),
WS-Reliable-Messaging, WS-Federation (Liberty) and SAML 2.0., but
what gets implemented will in the end be decided by the community
process.
TSIK should also make it easy to conform to WS-I profiles, for
instance, the Basic Security Profile.
We believe in an active participation in interop events. There will
be APIs for use cases as defined by interop events in OASIS, W3C,
etc., as well as profiles issues discussed via WS-I.
Interoperability is paramount and the TSIK test suites shall strive
to always interoperate with other implementations.
Known risks
---Orphaned products
TSIK has always been distributed in binary form. Many customers have
requested access to the source to add functionality to the TSIK code
base.
---Commercial interest
The current commercial products built on TSIK have been found to
have no claims on the source code. VeriSign does not plan to develop
parallel in-house versions of TSIK, but spend all efforts on the ASF
TSIK project.
---Inexperience with Open Source
Some TSIK developers are already in OS-based businesses. However,
VeriSign
