You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Granqvist, Hans" <hg...@verisign.com> on 2005/05/18 00:10:10 UTC
[PROPOSAL] Apache TSIK
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 has limited experience working on open source projects, but
has extensive experience in creating many open WS* standards, and hope
this will aid in the transition to the open source community.
---Initial Reliance on Salaried Workers
It is believed that, initially, most TSIK development will be done by
salaried workers. They will not necessarily be employed by VeriSign,
though. As mentioned above, VeriSign partners and customers have
expressed interest in taking part in developing TSIK.
---Licensing, Patents, Miscellaneous Legal
The IP rights surrounding some WS-* standards can be difficult to
understand. As a co-author of many WS-* standards, VeriSign will work
with Apache to make sure those issues are resolved in the community.
Initial source
--------------
TSIK has been in development since around 2001 and has an active user
base (currently over 200 members in the user group). As mentioned
above, it is the basis of several products developed by VeriSign.
TSIK contains implementations of the XML signature, XML encryption
standards, XKMS and SAML, and WS-Security, etc. It also contains
utility classes to make DOM and XPath easier to use, constructing and
parsing SOAP messages, etc.
The current Java source code uses Apache libraries and tools (for
example ant, xerces, xalan, log4j). It also uses JUnit for test
coverage. The build processes builds complete documentation (including
javadocs) and contains sample source code to describe usage patterns.
Source submission plan
-----------------------
The following Java packages will be submitted:
Package name Purpose
------------------------------------------------------
org.apache.tsik.crl CRL handling
org.apache.tsik.datatypes Passive data types of general utility
org.apache.tsik.domutil A simplified interface to DOM
org.apache.tsik.messaging XML messaging framework
org.apache.tsik.resource Basic XML facilities (e.g., parsing)
org.apache.tsik.xmlenc XML encryption
org.apache.tsik.xmlsig XML decryption
org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
org.apache.tsik.xpath XPath implementation
org.apache.tsik.wss WS-Security implementation (*)
org.apache.tsik.wst WS-Trust implementation (*)
org.apache.tsik.wsa WS-Addressing (*)
org.apache.tsik.verifier Assess trust of public keys and
certificates
org.apache.tsik.test.* JUnit test suites for all packages
(*) The WS-* implementations are in various levels of completion.
There are more packages in TSIK. We want to keep the initial
submission as small as possible to increase its chances of adoption.
As TSIK is being incubated, we plan to propose adding the following
packages. Our plan is to accomplish this within three months of the
original submission, if there is interest in the group:
Package name Purpose
----------------------------------------------------------
org.apache.tsik.xkms.client Client XKMS APIs
org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
org.apache.tsik.util.failover For failsafe implementation
org.apache.schema XML Schema validation
org.apache.tsik.saml SAML 1.0 implementation
org.apache.tsik.cryptostream Streaming crypto framework
org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
renew, revoke, etc., operations.)
org.apache.tsik.dime Implementation of DIME (*)
(*) This package should be updated to comply with latest binary
attachment standard, e.g., SwA.
Resources
----------
We foresee only standard Apache developer resources to be created,
such as cvs/subversion, developer mailing lists, etc.
Documentation
-------------
TSIK is today available for download (binary code only) from
http://www.verisign.com/developer/xml/ .
The developer community mailing list is hosted by yahoo on
http://groups.yahoo.com/group/tsik/
Initial committers
------------------
Hans Granqvist (hgranqvist@verisign.com)
Mark Hayes (mark@sleepycat.com)
Apache sponsor/champion
---------------------------
Davanum Srinivas (dims@yahoo.com)
List of implemented XML standards
----------------------------------
These are XML standards implemented in TSIK.
XPath http://www.w3.org/TR/xpath
Encryption http://www.w3.org/TR/xmlenc-core/
Signature http://www.w3.org/TR/xmldsig-core/
Canonicalization http://www.w3.org/TR/xml-c14n
Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
XKMS http://www.w3.org/TR/xkms/
WS-Addressing http://www.w3.org/Submission/ws-addressing/
WS-Security 1.0 (March 15, 2004)
http://docs.oasis-open.org/wss/2004/01/\
oasis-200401-wss-soap-message-security-1.0.pdf
WS-Trust (February 2005 draft)
ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
Contact
-------
Hans Granqvist, Web Services Architect
VeriSign, Inc.
487 East Middlefield Road
M/S MV6-2-1
Mountain View, CA 94043
Email: hgranqvist@verisign.com
Phone: +1-650-426-5232
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Sat, 21 May 2005, Phil Steitz wrote:
> +1
+1 - and would be happy to help mentoring this if needed. My main worries
are the overlap with existing xml sig/sec work and existing WS work along
with the various licensing, patents and what not issues. Seeing Dim's on
board alleviates most of the first set of concerns.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Phil Steitz <ps...@apache.org>.
+1
Phil
Granqvist, Hans wrote:
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 23 May 2005, Sanjiva Weerawarana wrote:
> Um, sure .. that's one way to make sure my concerns are addressed before
> they're let off the hook ;-).
Good - that increases the likelyhood of survival a lot.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Um, sure .. that's one way to make sure my concerns are addressed before
they're let off the hook ;-).
Sanjiva.
On Mon, 2005-05-23 at 11:04 -0400, Davanum Srinivas wrote:
> Sanjiva,
>
> Yep. That is the role of a mentor to guide the new project and "build
> meaningful ties". Do you want to sign up? :)
>
> thanks,
> dims
>
> On 5/23/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > On Mon, 2005-05-23 at 20:05 +1000, Berin Lautenbach wrote:
> > > > - If yes, I am concerned having a permanent split is not the most
> > > > healthy thing for the Apache developer community.
> > >
> > > Is there anything intrinsically wrong with a different implementation of
> > > the same stuff in the ASF?
> >
> > At the core of that question, of course not.
> >
> > > One of the things that *might* be interesting, would be to look at each
> > > component and see where we can merge things together to come up with an
> > > even better whole.
> >
> > This is a tautological kind of position that I possibly cannot argue
> > against :-).
> >
> > However ...
> >
> > *If* there was some cross participation in the projects of the people
> > coming in, then I agree this would be the expected outcome. However,
> > when you take an existing, active, Apache project (area) and inject a
> > brand new parallel path with two committers who appear to be new to
> > Apache and have no experience in the Apache codebase(s) (of necessity as
> > they had to do a cleanroom impl for their org I'll bet), then IMO its
> > not a healthy thing for our community.
> >
> > I guess it depends on how you define community - to me its *first* the
> > current community and 2nd the people injecting some code into ASF.
> >
> > I would prefer to see us put a requirement that during incubation the
> > project must build meaningful ties into the other WS projects - via
> > cross committers and interdependency. That requires the marriage that
> > you envision (and which I, of course, agree with) to occur before the
> > project can be considered to have passed incubation.
> >
> > Sanjiva.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Sanjiva,
Yep. That is the role of a mentor to guide the new project and "build
meaningful ties". Do you want to sign up? :)
thanks,
dims
On 5/23/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2005-05-23 at 20:05 +1000, Berin Lautenbach wrote:
> > > - If yes, I am concerned having a permanent split is not the most
> > > healthy thing for the Apache developer community.
> >
> > Is there anything intrinsically wrong with a different implementation of
> > the same stuff in the ASF?
>
> At the core of that question, of course not.
>
> > One of the things that *might* be interesting, would be to look at each
> > component and see where we can merge things together to come up with an
> > even better whole.
>
> This is a tautological kind of position that I possibly cannot argue
> against :-).
>
> However ...
>
> *If* there was some cross participation in the projects of the people
> coming in, then I agree this would be the expected outcome. However,
> when you take an existing, active, Apache project (area) and inject a
> brand new parallel path with two committers who appear to be new to
> Apache and have no experience in the Apache codebase(s) (of necessity as
> they had to do a cleanroom impl for their org I'll bet), then IMO its
> not a healthy thing for our community.
>
> I guess it depends on how you define community - to me its *first* the
> current community and 2nd the people injecting some code into ASF.
>
> I would prefer to see us put a requirement that during incubation the
> project must build meaningful ties into the other WS projects - via
> cross committers and interdependency. That requires the marriage that
> you envision (and which I, of course, agree with) to occur before the
> project can be considered to have passed incubation.
>
> Sanjiva.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2005-05-23 at 20:05 +1000, Berin Lautenbach wrote:
> > - If yes, I am concerned having a permanent split is not the most
> > healthy thing for the Apache developer community.
>
> Is there anything intrinsically wrong with a different implementation of
> the same stuff in the ASF?
At the core of that question, of course not.
> One of the things that *might* be interesting, would be to look at each
> component and see where we can merge things together to come up with an
> even better whole.
This is a tautological kind of position that I possibly cannot argue
against :-).
However ...
*If* there was some cross participation in the projects of the people
coming in, then I agree this would be the expected outcome. However,
when you take an existing, active, Apache project (area) and inject a
brand new parallel path with two committers who appear to be new to
Apache and have no experience in the Apache codebase(s) (of necessity as
they had to do a cleanroom impl for their org I'll bet), then IMO its
not a healthy thing for our community.
I guess it depends on how you define community - to me its *first* the
current community and 2nd the people injecting some code into ASF.
I would prefer to see us put a requirement that during incubation the
project must build meaningful ties into the other WS projects - via
cross committers and interdependency. That requires the marriage that
you envision (and which I, of course, agree with) to occur before the
project can be considered to have passed incubation.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Berin,
Yep. +1.
-- dims
On 5/23/05, Berin Lautenbach <be...@wingsofhermes.org> wrote:
> Sanjiva Weerawarana wrote:
>
> > Do I understand correctly that this is a basically complete package that
> > is being donated to Apache? Does it have its own SOAP stack ..
> > o.a.tsik.messaging? If not how does this stuff plug into say Axis?
> >
> > So my concerns are:
> > - does it use Axis? If not what's the connection to anything we
> > currently have?
> > - it appears to have its own addressing impl too?
> > - same concerns for xml-security stuff - is this just a competitor (==>
> > split community in my mind)
> > - is there any roadmap with Axis2? Otherwise is it a permanent alternate
> > path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
> > - If yes, I am concerned having a permanent split is not the most
> > healthy thing for the Apache developer community.
>
> Is there anything intrinsically wrong with a different implementation of
> the same stuff in the ASF?
>
> One of the things that *might* be interesting, would be to look at each
> component and see where we can merge things together to come up with an
> even better whole.
>
> Cheers,
> Berin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Sanjiva Weerawarana wrote:
> Do I understand correctly that this is a basically complete package that
> is being donated to Apache? Does it have its own SOAP stack ..
> o.a.tsik.messaging? If not how does this stuff plug into say Axis?
>
> So my concerns are:
> - does it use Axis? If not what's the connection to anything we
> currently have?
> - it appears to have its own addressing impl too?
> - same concerns for xml-security stuff - is this just a competitor (==>
> split community in my mind)
> - is there any roadmap with Axis2? Otherwise is it a permanent alternate
> path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
> - If yes, I am concerned having a permanent split is not the most
> healthy thing for the Apache developer community.
Is there anything intrinsically wrong with a different implementation of
the same stuff in the ASF?
One of the things that *might* be interesting, would be to look at each
component and see where we can merge things together to come up with an
even better whole.
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Do I understand correctly that this is a basically complete package that
is being donated to Apache? Does it have its own SOAP stack ..
o.a.tsik.messaging? If not how does this stuff plug into say Axis?
So my concerns are:
- does it use Axis? If not what's the connection to anything we
currently have?
- it appears to have its own addressing impl too?
- same concerns for xml-security stuff - is this just a competitor (==>
split community in my mind)
- is there any roadmap with Axis2? Otherwise is it a permanent alternate
path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
- If yes, I am concerned having a permanent split is not the most
healthy thing for the Apache developer community.
Also, only two developers for all this code?? There's a *lot* of work in
the codebase for 2 people to properly develop a community around isn't
it? (XPath, XML encryption, XML signature, messaging, addressing, ...)
I'd like to see some answers before saying +1.
Sanjiva.
On Sat, 2005-05-21 at 11:50 -0400, Davanum Srinivas wrote:
> FYI...please send feedback to general@incubator.
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Granqvist, Hans <hg...@verisign.com>
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Do I understand correctly that this is a basically complete package that
is being donated to Apache? Does it have its own SOAP stack ..
o.a.tsik.messaging? If not how does this stuff plug into say Axis?
So my concerns are:
- does it use Axis? If not what's the connection to anything we
currently have?
- it appears to have its own addressing impl too?
- same concerns for xml-security stuff - is this just a competitor (==>
split community in my mind)
- is there any roadmap with Axis2? Otherwise is it a permanent alternate
path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
- If yes, I am concerned having a permanent split is not the most
healthy thing for the Apache developer community.
Also, only two developers for all this code?? There's a *lot* of work in
the codebase for 2 people to properly develop a community around isn't
it? (XPath, XML encryption, XML signature, messaging, addressing, ...)
I'd like to see some answers before saying +1.
Sanjiva.
On Sat, 2005-05-21 at 11:50 -0400, Davanum Srinivas wrote:
> FYI...please send feedback to general@incubator.
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Granqvist, Hans <hg...@verisign.com>
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Do I understand correctly that this is a basically complete package that
is being donated to Apache? Does it have its own SOAP stack ..
o.a.tsik.messaging? If not how does this stuff plug into say Axis?
So my concerns are:
- does it use Axis? If not what's the connection to anything we
currently have?
- it appears to have its own addressing impl too?
- same concerns for xml-security stuff - is this just a competitor (==>
split community in my mind)
- is there any roadmap with Axis2? Otherwise is it a permanent alternate
path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
- If yes, I am concerned having a permanent split is not the most
healthy thing for the Apache developer community.
Also, only two developers for all this code?? There's a *lot* of work in
the codebase for 2 people to properly develop a community around isn't
it? (XPath, XML encryption, XML signature, messaging, addressing, ...)
I'd like to see some answers before saying +1.
Sanjiva.
On Sat, 2005-05-21 at 11:50 -0400, Davanum Srinivas wrote:
> FYI...please send feedback to general@incubator.
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Granqvist, Hans <hg...@verisign.com>
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
Re: Fwd: [PROPOSAL] Apache TSIK
Posted by Anil Saldhana <an...@yahoo.com>.
Dims,
this is a very good proposal. Should be part of
Apache WS.
Cheers,
Anil
--- Davanum Srinivas <da...@gmail.com> wrote:
> FYI...please send feedback to general@incubator.
>
> thanks,
> dims
>
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Fwd: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
FYI...please send feedback to general@incubator.
thanks,
dims
---------- Forwarded message ----------
From: Granqvist, Hans <hg...@verisign.com>
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 has limited experience working on open source projects, but
has extensive experience in creating many open WS* standards, and hope
this will aid in the transition to the open source community.
---Initial Reliance on Salaried Workers
It is believed that, initially, most TSIK development will be done by
salaried workers. They will not necessarily be employed by VeriSign,
though. As mentioned above, VeriSign partners and customers have
expressed interest in taking part in developing TSIK.
---Licensing, Patents, Miscellaneous Legal
The IP rights surrounding some WS-* standards can be difficult to
understand. As a co-author of many WS-* standards, VeriSign will work
with Apache to make sure those issues are resolved in the community.
Initial source
--------------
TSIK has been in development since around 2001 and has an active user
base (currently over 200 members in the user group). As mentioned
above, it is the basis of several products developed by VeriSign.
TSIK contains implementations of the XML signature, XML encryption
standards, XKMS and SAML, and WS-Security, etc. It also contains
utility classes to make DOM and XPath easier to use, constructing and
parsing SOAP messages, etc.
The current Java source code uses Apache libraries and tools (for
example ant, xerces, xalan, log4j). It also uses JUnit for test
coverage. The build processes builds complete documentation (including
javadocs) and contains sample source code to describe usage patterns.
Source submission plan
-----------------------
The following Java packages will be submitted:
Package name Purpose
------------------------------------------------------
org.apache.tsik.crl CRL handling
org.apache.tsik.datatypes Passive data types of general utility
org.apache.tsik.domutil A simplified interface to DOM
org.apache.tsik.messaging XML messaging framework
org.apache.tsik.resource Basic XML facilities (e.g., parsing)
org.apache.tsik.xmlenc XML encryption
org.apache.tsik.xmlsig XML decryption
org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
org.apache.tsik.xpath XPath implementation
org.apache.tsik.wss WS-Security implementation (*)
org.apache.tsik.wst WS-Trust implementation (*)
org.apache.tsik.wsa WS-Addressing (*)
org.apache.tsik.verifier Assess trust of public keys and
certificates
org.apache.tsik.test.* JUnit test suites for all packages
(*) The WS-* implementations are in various levels of completion.
There are more packages in TSIK. We want to keep the initial
submission as small as possible to increase its chances of adoption.
As TSIK is being incubated, we plan to propose adding the following
packages. Our plan is to accomplish this within three months of the
original submission, if there is interest in the group:
Package name Purpose
----------------------------------------------------------
org.apache.tsik.xkms.client Client XKMS APIs
org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
org.apache.tsik.util.failover For failsafe implementation
org.apache.schema XML Schema validation
org.apache.tsik.saml SAML 1.0 implementation
org.apache.tsik.cryptostream Streaming crypto framework
org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
renew, revoke, etc., operations.)
org.apache.tsik.dime Implementation of DIME (*)
(*) This package should be updated to comply with latest binary
attachment standard, e.g., SwA.
Resources
----------
We foresee only standard Apache developer resources to be created,
such as cvs/subversion, developer mailing lists, etc.
Documentation
-------------
TSIK is today available for download (binary code only) from
http://www.verisign.com/developer/xml/ .
The developer community mailing list is hosted by yahoo on
http://groups.yahoo.com/group/tsik/
Initial committers
------------------
Hans Granqvist (hgranqvist@verisign.com)
Mark Hayes (mark@sleepycat.com)
Apache sponsor/champion
---------------------------
Davanum Srinivas (dims@yahoo.com)
List of implemented XML standards
----------------------------------
These are XML standards implemented in TSIK.
XPath http://www.w3.org/TR/xpath
Encryption http://www.w3.org/TR/xmlenc-core/
Signature http://www.w3.org/TR/xmldsig-core/
Canonicalization http://www.w3.org/TR/xml-c14n
Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
XKMS http://www.w3.org/TR/xkms/
WS-Addressing http://www.w3.org/Submission/ws-addressing/
WS-Security 1.0 (March 15, 2004)
http://docs.oasis-open.org/wss/2004/01/\
oasis-200401-wss-soap-message-security-1.0.pdf
WS-Trust (February 2005 draft)
ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
Contact
-------
Hans Granqvist, Web Services Architect
VeriSign, Inc.
487 East Middlefield Road
M/S MV6-2-1
Mountain View, CA 94043
Email: hgranqvist@verisign.com
Phone: +1-650-426-5232
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Fwd: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
FYI...please send feedback to general@incubator.
thanks,
dims
---------- Forwarded message ----------
From: Granqvist, Hans <hg...@verisign.com>
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 has limited experience working on open source projects, but
has extensive experience in creating many open WS* standards, and hope
this will aid in the transition to the open source community.
---Initial Reliance on Salaried Workers
It is believed that, initially, most TSIK development will be done by
salaried workers. They will not necessarily be employed by VeriSign,
though. As mentioned above, VeriSign partners and customers have
expressed interest in taking part in developing TSIK.
---Licensing, Patents, Miscellaneous Legal
The IP rights surrounding some WS-* standards can be difficult to
understand. As a co-author of many WS-* standards, VeriSign will work
with Apache to make sure those issues are resolved in the community.
Initial source
--------------
TSIK has been in development since around 2001 and has an active user
base (currently over 200 members in the user group). As mentioned
above, it is the basis of several products developed by VeriSign.
TSIK contains implementations of the XML signature, XML encryption
standards, XKMS and SAML, and WS-Security, etc. It also contains
utility classes to make DOM and XPath easier to use, constructing and
parsing SOAP messages, etc.
The current Java source code uses Apache libraries and tools (for
example ant, xerces, xalan, log4j). It also uses JUnit for test
coverage. The build processes builds complete documentation (including
javadocs) and contains sample source code to describe usage patterns.
Source submission plan
-----------------------
The following Java packages will be submitted:
Package name Purpose
------------------------------------------------------
org.apache.tsik.crl CRL handling
org.apache.tsik.datatypes Passive data types of general utility
org.apache.tsik.domutil A simplified interface to DOM
org.apache.tsik.messaging XML messaging framework
org.apache.tsik.resource Basic XML facilities (e.g., parsing)
org.apache.tsik.xmlenc XML encryption
org.apache.tsik.xmlsig XML decryption
org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
org.apache.tsik.xpath XPath implementation
org.apache.tsik.wss WS-Security implementation (*)
org.apache.tsik.wst WS-Trust implementation (*)
org.apache.tsik.wsa WS-Addressing (*)
org.apache.tsik.verifier Assess trust of public keys and
certificates
org.apache.tsik.test.* JUnit test suites for all packages
(*) The WS-* implementations are in various levels of completion.
There are more packages in TSIK. We want to keep the initial
submission as small as possible to increase its chances of adoption.
As TSIK is being incubated, we plan to propose adding the following
packages. Our plan is to accomplish this within three months of the
original submission, if there is interest in the group:
Package name Purpose
----------------------------------------------------------
org.apache.tsik.xkms.client Client XKMS APIs
org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
org.apache.tsik.util.failover For failsafe implementation
org.apache.schema XML Schema validation
org.apache.tsik.saml SAML 1.0 implementation
org.apache.tsik.cryptostream Streaming crypto framework
org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
renew, revoke, etc., operations.)
org.apache.tsik.dime Implementation of DIME (*)
(*) This package should be updated to comply with latest binary
attachment standard, e.g., SwA.
Resources
----------
We foresee only standard Apache developer resources to be created,
such as cvs/subversion, developer mailing lists, etc.
Documentation
-------------
TSIK is today available for download (binary code only) from
http://www.verisign.com/developer/xml/ .
The developer community mailing list is hosted by yahoo on
http://groups.yahoo.com/group/tsik/
Initial committers
------------------
Hans Granqvist (hgranqvist@verisign.com)
Mark Hayes (mark@sleepycat.com)
Apache sponsor/champion
---------------------------
Davanum Srinivas (dims@yahoo.com)
List of implemented XML standards
----------------------------------
These are XML standards implemented in TSIK.
XPath http://www.w3.org/TR/xpath
Encryption http://www.w3.org/TR/xmlenc-core/
Signature http://www.w3.org/TR/xmldsig-core/
Canonicalization http://www.w3.org/TR/xml-c14n
Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
XKMS http://www.w3.org/TR/xkms/
WS-Addressing http://www.w3.org/Submission/ws-addressing/
WS-Security 1.0 (March 15, 2004)
http://docs.oasis-open.org/wss/2004/01/\
oasis-200401-wss-soap-message-security-1.0.pdf
WS-Trust (February 2005 draft)
ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
Contact
-------
Hans Granqvist, Web Services Architect
VeriSign, Inc.
487 East Middlefield Road
M/S MV6-2-1
Mountain View, CA 94043
Email: hgranqvist@verisign.com
Phone: +1-650-426-5232
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [PROPOSAL] Apache TSIK
Posted by Anne Thomas Manes <at...@gmail.com>.
I assume that
--> org.apache.tsik.xmlsig XML decryption
is meant to be this:
--> org.apache.tsik.xmlsig XML signature
I think it's a great idea.
Anne
On 5/20/05, Davanum Srinivas <da...@gmail.com> wrote:
> Hi all,
>
> please send feedback directly on general@incubator.apache.org.
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Granqvist, Hans <hg...@verisign.com>
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
Re: [PROPOSAL] Apache TSIK
Posted by Anne Thomas Manes <at...@gmail.com>.
I assume that
--> org.apache.tsik.xmlsig XML decryption
is meant to be this:
--> org.apache.tsik.xmlsig XML signature
I think it's a great idea.
Anne
On 5/20/05, Davanum Srinivas <da...@gmail.com> wrote:
> Hi all,
>
> please send feedback directly on general@incubator.apache.org.
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Granqvist, Hans <hg...@verisign.com>
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Hi all,
please send feedback directly on general@incubator.apache.org.
thanks,
dims
---------- Forwarded message ----------
From: Granqvist, Hans <hg...@verisign.com>
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 has limited experience working on open source projects, but
has extensive experience in creating many open WS* standards, and hope
this will aid in the transition to the open source community.
---Initial Reliance on Salaried Workers
It is believed that, initially, most TSIK development will be done by
salaried workers. They will not necessarily be employed by VeriSign,
though. As mentioned above, VeriSign partners and customers have
expressed interest in taking part in developing TSIK.
---Licensing, Patents, Miscellaneous Legal
The IP rights surrounding some WS-* standards can be difficult to
understand. As a co-author of many WS-* standards, VeriSign will work
with Apache to make sure those issues are resolved in the community.
Initial source
--------------
TSIK has been in development since around 2001 and has an active user
base (currently over 200 members in the user group). As mentioned
above, it is the basis of several products developed by VeriSign.
TSIK contains implementations of the XML signature, XML encryption
standards, XKMS and SAML, and WS-Security, etc. It also contains
utility classes to make DOM and XPath easier to use, constructing and
parsing SOAP messages, etc.
The current Java source code uses Apache libraries and tools (for
example ant, xerces, xalan, log4j). It also uses JUnit for test
coverage. The build processes builds complete documentation (including
javadocs) and contains sample source code to describe usage patterns.
Source submission plan
-----------------------
The following Java packages will be submitted:
Package name Purpose
------------------------------------------------------
org.apache.tsik.crl CRL handling
org.apache.tsik.datatypes Passive data types of general utility
org.apache.tsik.domutil A simplified interface to DOM
org.apache.tsik.messaging XML messaging framework
org.apache.tsik.resource Basic XML facilities (e.g., parsing)
org.apache.tsik.xmlenc XML encryption
org.apache.tsik.xmlsig XML decryption
org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
org.apache.tsik.xpath XPath implementation
org.apache.tsik.wss WS-Security implementation (*)
org.apache.tsik.wst WS-Trust implementation (*)
org.apache.tsik.wsa WS-Addressing (*)
org.apache.tsik.verifier Assess trust of public keys and
certificates
org.apache.tsik.test.* JUnit test suites for all packages
(*) The WS-* implementations are in various levels of completion.
There are more packages in TSIK. We want to keep the initial
submission as small as possible to increase its chances of adoption.
As TSIK is being incubated, we plan to propose adding the following
packages. Our plan is to accomplish this within three months of the
original submission, if there is interest in the group:
Package name Purpose
----------------------------------------------------------
org.apache.tsik.xkms.client Client XKMS APIs
org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
org.apache.tsik.util.failover For failsafe implementation
org.apache.schema XML Schema validation
org.apache.tsik.saml SAML 1.0 implementation
org.apache.tsik.cryptostream Streaming crypto framework
org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
renew, revoke, etc., operations.)
org.apache.tsik.dime Implementation of DIME (*)
(*) This package should be updated to comply with latest binary
attachment standard, e.g., SwA.
Resources
----------
We foresee only standard Apache developer resources to be created,
such as cvs/subversion, developer mailing lists, etc.
Documentation
-------------
TSIK is today available for download (binary code only) from
http://www.verisign.com/developer/xml/ .
The developer community mailing list is hosted by yahoo on
http://groups.yahoo.com/group/tsik/
Initial committers
------------------
Hans Granqvist (hgranqvist@verisign.com)
Mark Hayes (mark@sleepycat.com)
Apache sponsor/champion
---------------------------
Davanum Srinivas (dims@yahoo.com)
List of implemented XML standards
----------------------------------
These are XML standards implemented in TSIK.
XPath http://www.w3.org/TR/xpath
Encryption http://www.w3.org/TR/xmlenc-core/
Signature http://www.w3.org/TR/xmldsig-core/
Canonicalization http://www.w3.org/TR/xml-c14n
Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
XKMS http://www.w3.org/TR/xkms/
WS-Addressing http://www.w3.org/Submission/ws-addressing/
WS-Security 1.0 (March 15, 2004)
http://docs.oasis-open.org/wss/2004/01/\
oasis-200401-wss-soap-message-security-1.0.pdf
WS-Trust (February 2005 draft)
ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
Contact
-------
Hans Granqvist, Web Services Architect
VeriSign, Inc.
487 East Middlefield Road
M/S MV6-2-1
Mountain View, CA 94043
Email: hgranqvist@verisign.com
Phone: +1-650-426-5232
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Yep. 3 eyes are better than one :) I will get the ball rolling.
-- dims
On 5/31/05, Noel J. Bergman <no...@devtech.com> wrote:
> Davanum Srinivas wrote:
>
> > The WS-PMC has VOTE'd to accept the project.
>
> Excellent. As Dw indicated, having you and the WS PMC on-board will
> alleviate any concerns over collaboration with other parts of the ASF
> working in this space. I do note concerns raised by Sanjiva, which should
> be addressed as possible during incubation.
>
> Please make sure to setup the status page, and line up the mentors. I
> expect that you (dims) are planning to do it. Sanjiva also indicated a
> desire to be a mentor, and Dw indicated a willingness if necessary.
>
> --- Noel
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Apache TSIK
Posted by "Noel J. Bergman" <no...@devtech.com>.
Davanum Srinivas wrote:
> The WS-PMC has VOTE'd to accept the project.
Excellent. As Dw indicated, having you and the WS PMC on-board will
alleviate any concerns over collaboration with other parts of the ASF
working in this space. I do note concerns raised by Sanjiva, which should
be addressed as possible during incubation.
Please make sure to setup the status page, and line up the mentors. I
expect that you (dims) are planning to do it. Sanjiva also indicated a
desire to be a mentor, and Dw indicated a willingness if necessary.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Hans,
The WS-PMC has VOTE'd to accept the project. Please send in the
required documents including your individual CLA (iCLA) as mentioned
here - http://www.apache.org/licenses/. I will start the
infrastructure process(es) like mailing list, JIRA, SVN etc.
thanks,
dims
On 5/17/05, Granqvist, Hans <hg...@verisign.com> wrote:
> 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 has limited experience working on open source projects, but
> has extensive experience in creating many open WS* standards, and hope
> this will aid in the transition to the open source community.
>
> ---Initial Reliance on Salaried Workers
> It is believed that, initially, most TSIK development will be done by
> salaried workers. They will not necessarily be employed by VeriSign,
> though. As mentioned above, VeriSign partners and customers have
> expressed interest in taking part in developing TSIK.
>
> ---Licensing, Patents, Miscellaneous Legal
> The IP rights surrounding some WS-* standards can be difficult to
> understand. As a co-author of many WS-* standards, VeriSign will work
> with Apache to make sure those issues are resolved in the community.
>
>
> Initial source
> --------------
> TSIK has been in development since around 2001 and has an active user
> base (currently over 200 members in the user group). As mentioned
> above, it is the basis of several products developed by VeriSign.
>
> TSIK contains implementations of the XML signature, XML encryption
> standards, XKMS and SAML, and WS-Security, etc. It also contains
> utility classes to make DOM and XPath easier to use, constructing and
> parsing SOAP messages, etc.
>
> The current Java source code uses Apache libraries and tools (for
> example ant, xerces, xalan, log4j). It also uses JUnit for test
> coverage. The build processes builds complete documentation (including
> javadocs) and contains sample source code to describe usage patterns.
>
>
> Source submission plan
> -----------------------
> The following Java packages will be submitted:
>
> Package name Purpose
> ------------------------------------------------------
> org.apache.tsik.crl CRL handling
> org.apache.tsik.datatypes Passive data types of general utility
> org.apache.tsik.domutil A simplified interface to DOM
> org.apache.tsik.messaging XML messaging framework
> org.apache.tsik.resource Basic XML facilities (e.g., parsing)
> org.apache.tsik.xmlenc XML encryption
> org.apache.tsik.xmlsig XML decryption
> org.apache.tsik.xmlsig.tools Pkcs#12, #8, JCA/JCE utilities
> org.apache.tsik.xpath XPath implementation
> org.apache.tsik.wss WS-Security implementation (*)
> org.apache.tsik.wst WS-Trust implementation (*)
> org.apache.tsik.wsa WS-Addressing (*)
> org.apache.tsik.verifier Assess trust of public keys and
> certificates
> org.apache.tsik.test.* JUnit test suites for all packages
>
> (*) The WS-* implementations are in various levels of completion.
>
> There are more packages in TSIK. We want to keep the initial
> submission as small as possible to increase its chances of adoption.
>
> As TSIK is being incubated, we plan to propose adding the following
> packages. Our plan is to accomplish this within three months of the
> original submission, if there is interest in the group:
>
> Package name Purpose
> ----------------------------------------------------------
> org.apache.tsik.xkms.client Client XKMS APIs
> org.apache.tsik.xkms.tools Tools, such as XKMS-aware keystores
> org.apache.tsik.util.failover For failsafe implementation
> org.apache.schema XML Schema validation
> org.apache.tsik.saml SAML 1.0 implementation
> org.apache.tsik.cryptostream Streaming crypto framework
> org.apache.tsik.cryptostream.pkcs7 Pkcs #7 streams
> org.apache.tsik.pki.client PKI lifecycle (certificate enroll,
> renew, revoke, etc., operations.)
> org.apache.tsik.dime Implementation of DIME (*)
>
> (*) This package should be updated to comply with latest binary
> attachment standard, e.g., SwA.
>
>
> Resources
> ----------
> We foresee only standard Apache developer resources to be created,
> such as cvs/subversion, developer mailing lists, etc.
>
>
> Documentation
> -------------
> TSIK is today available for download (binary code only) from
> http://www.verisign.com/developer/xml/ .
>
> The developer community mailing list is hosted by yahoo on
> http://groups.yahoo.com/group/tsik/
>
>
> Initial committers
> ------------------
> Hans Granqvist (hgranqvist@verisign.com)
> Mark Hayes (mark@sleepycat.com)
>
> Apache sponsor/champion
> ---------------------------
> Davanum Srinivas (dims@yahoo.com)
>
> List of implemented XML standards
> ----------------------------------
> These are XML standards implemented in TSIK.
>
> XPath http://www.w3.org/TR/xpath
> Encryption http://www.w3.org/TR/xmlenc-core/
> Signature http://www.w3.org/TR/xmldsig-core/
> Canonicalization http://www.w3.org/TR/xml-c14n
> Exclusive c14n http://www.w3.org/TR/xml-exc-c14n/
> XKMS http://www.w3.org/TR/xkms/
>
> WS-Addressing http://www.w3.org/Submission/ws-addressing/
>
> WS-Security 1.0 (March 15, 2004)
> http://docs.oasis-open.org/wss/2004/01/\
> oasis-200401-wss-soap-message-security-1.0.pdf
>
> WS-Trust (February 2005 draft)
> ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf
>
>
> Contact
> -------
> Hans Granqvist, Web Services Architect
> VeriSign, Inc.
> 487 East Middlefield Road
> M/S MV6-2-1
> Mountain View, CA 94043
>
> Email: hgranqvist@verisign.com
> Phone: +1-650-426-5232
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Davanum Srinivas <da...@gmail.com>.
Noel,
will ask the WS-PMC.
thanks,
dims
On 5/21/05, Noel J. Bergman <no...@devtech.com> wrote:
> This looks alright, but I have some questions. First, why isn't the WS PMC
> sponsoring this as WS-TSIK?
>
> There is a proposed "PGP" package being discussed in Jakarta Commons. Would
> there be any overlap at lower levels (not at the WS layer) between them,
> providing for some collaboration?
>
> > The intent with Apache TSIK is to create a web services project
> > to implement standards as defined by W3C, OASIS, and others:
>
> > 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.
>
> So this only works if the standard permits a subset implementation?
>
> > 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.
>
> > 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.
>
> So would the TSIK be implementing these capabilities and then be leveraged
> by other API providing projects? Or is the primary issue here that:
>
> > 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.
>
> And therefore, the TSIK would not be the implementation, but would be a
> simplified API on top of a fuller implementation?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Noel J. Bergman wrote:
> Dims raised the same issue to me, so there is a common thread there. Would
> this also help to resurrect JuiCE? And, again, be aware of the proposed PGP
> package for Jakarta Commons, targeting package signing.
Just having sorted out the *&^% CLA issue may help JuiCE along. As Ben
indicated - the OpenPGP package is somewhat of a different ballgame, if
only because everything else we are talking about is XML based. But
hey, happy to throw anything in to the mix :>.
>
> Are you also suggesting that we have some existing XML Security committers
> who would be interested in joining?
Well, at least one :>. One of the things I'm looking at at the moment
is XKMS (albeit in the C++ space), and having another toolkit to work
with in that space would be most interesting indeed.
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Apache TSIK
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin Lautenbach wrote:
> I'm +1 on this (with the concomitant committment to help out -
> I'll even mentor if necessary
That'd probably be helpful.
> The XML Security team probably an equivalent level of overlap to the WS
> project. The proposal discusses xml-sig/xml-enc and XKMS, all of which
> are worked on in xml-security. But looking at the amount of stuff in
> there, I'd almost suggest this might be the catalyst for creating the
> broader XML security project - which I know I have talked about on and
> off for a while :>.
Dims raised the same issue to me, so there is a common thread there. Would
this also help to resurrect JuiCE? And, again, be aware of the proposed PGP
package for Jakarta Commons, targeting package signing.
Are you also suggesting that we have some existing XML Security committers
who would be interested in joining?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
First - I'm +1 on this (with the concomitant committment to help out -
I'll even mentor if necessary, although my time is often limited at the
moment).
Noel J. Bergman wrote:
> This looks alright, but I have some questions. First, why isn't the WS PMC
> sponsoring this as WS-TSIK?
The XML Security team probably an equivalent level of overlap to the WS
project. The proposal discusses xml-sig/xml-enc and XKMS, all of which
are worked on in xml-security. But looking at the amount of stuff in
there, I'd almost suggest this might be the catalyst for creating the
broader XML security project - which I know I have talked about on and
off for a while :>.
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
> Ben Laurie wrote:
>
>>>This strikes me as orthogonal, but it might be of interest that I'm
>>>currently working on a to-be-BSD-licensed (or equivalent) PGP C library.
>>>BTW, its properly called OpenPGP.
>
>
> Mm, seems to me that's an encumbered name.. I've got an OpenPGP plugin
> here in my Mozilla, from the enigmail project at mozdev.
OpenPGP is the name of the IETF standard. That makes it the opposite of
encumbered.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Ben Laurie wrote:
>
> This strikes me as orthogonal, but it might be of interest that I'm
> currently working on a to-be-BSD-licensed (or equivalent) PGP C library.
> BTW, its properly called OpenPGP.
Mm, seems to me that's an encumbered name.. I've got an OpenPGP plugin
here in my Mozilla, from the enigmail project at mozdev.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQpMhC5rNPMCpn3XdAQFekAQAiMpPrEgzbQsxDgbIkYuw4K6Ae+0kFhEC
XAraTXITsb34QIT2JEFKLswjtYtX/uX8hfjH0vB4yq3wVRtozOO7/lDBwhcbcI+v
LJMC8VvDR1xk1x+7SnQHfCJ6oa5gS/t2uCsAISwzWrGcGFQiF+nId/YfH+D1M0kS
0oxRYAotwuY=
=rizQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 22 May 2005, Ben Laurie <be...@algroup.co.uk> wrote:
> Noel J. Bergman wrote:
>> There is a proposed "PGP" package being discussed in Jakarta
>> Commons. Would there be any overlap at lower levels (not at the WS
>> layer) between them, providing for some collaboration?
>
> This strikes me as orthogonal,
Same here.
> but it might be of interest that I'm currently working on a
> to-be-BSD-licensed (or equivalent) PGP C library.
Interesting, yes.
The goal of the commons component is to provide an easier API for the
"simple" task of signing a stream or verifying the signature. This is
what the Maven and Ant build tools would need today. En-/Decryprion
may come later as well.
There already exist at least two "license compatible" Java libraries
that provide OpenPGP functionality (bouncycastle.org and cryptix.org)
so the component is also going to provide an implementation agnostic
interface. Bindings to command line invocations of OpenPGP compatible
toolkits or JNI bindings to a C-library would certainly be possible as
well.
> BTW, its properly called OpenPGP.
We started with PGP (based on ignorance, mainly 8-) but have made up
our mind already and will call it commons-openpgp. Unless we broaden
the scope even more so it would become commons-crypto - in which case
there'd be more overlap with XML security or TSIK.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: OpenPGP C Library, WAS: Re: [PROPOSAL] Apache TSIK
Posted by Ben Laurie <be...@algroup.co.uk>.
Sander Striker wrote:
> Ben Laurie wrote:
>
>> Noel J. Bergman wrote:
>>
>>> There is a proposed "PGP" package being discussed in Jakarta
>>> Commons. Would
>>> there be any overlap at lower levels (not at the WS layer) between them,
>>> providing for some collaboration?
>>
>>
>>
>> This strikes me as orthogonal, but it might be of interest that I'm
>> currently working on a to-be-BSD-licensed (or equivalent) PGP C library.
>> BTW, its properly called OpenPGP.
Since I answered these questions in IRC, I'll do so again here:
> Ah, interesting... any chance you are going to propose that to be housed
> at the ASF?
If there's sufficient interest, I am certainly permitted to.
> Are you currently developing somewhere I can follow along?
No :-)
Well, seriously, if individuals want to play, I can grant them access to
the SVN repo. I don't want to get into full-blown project maintenance
until we have something a little more useful laid down.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
OpenPGP C Library, WAS: Re: [PROPOSAL] Apache TSIK
Posted by Sander Striker <s....@striker.nl>.
Ben Laurie wrote:
> Noel J. Bergman wrote:
>
>>There is a proposed "PGP" package being discussed in Jakarta Commons. Would
>>there be any overlap at lower levels (not at the WS layer) between them,
>>providing for some collaboration?
>
>
> This strikes me as orthogonal, but it might be of interest that I'm
> currently working on a to-be-BSD-licensed (or equivalent) PGP C library.
> BTW, its properly called OpenPGP.
Ah, interesting... any chance you are going to propose that to be housed
at the ASF? Are you currently developing somewhere I can follow along?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Apache TSIK
Posted by Ben Laurie <be...@algroup.co.uk>.
Noel J. Bergman wrote:
> There is a proposed "PGP" package being discussed in Jakarta Commons. Would
> there be any overlap at lower levels (not at the WS layer) between them,
> providing for some collaboration?
This strikes me as orthogonal, but it might be of interest that I'm
currently working on a to-be-BSD-licensed (or equivalent) PGP C library.
BTW, its properly called OpenPGP.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] Apache TSIK
Posted by "Noel J. Bergman" <no...@devtech.com>.
This looks alright, but I have some questions. First, why isn't the WS PMC
sponsoring this as WS-TSIK?
There is a proposed "PGP" package being discussed in Jakarta Commons. Would
there be any overlap at lower levels (not at the WS layer) between them,
providing for some collaboration?
> The intent with Apache TSIK is to create a web services project
> to implement standards as defined by W3C, OASIS, and others:
> 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.
So this only works if the standard permits a subset implementation?
> 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.
> 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.
So would the TSIK be implementing these capabilities and then be leveraged
by other API providing projects? Or is the primary issue here that:
> 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.
And therefore, the TSIK would not be the implementation, but would be a
simplified API on top of a fuller implementation?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org