incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Granqvist, Hans" <hgranqv...@verisign.com>
Subject RE: Fwd: [PROPOSAL] Apache TSIK
Date Mon, 23 May 2005 16:33:53 GMT
Hi Sanjiva, see inline

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

It is a complete package that has its own Soap stack. It uses
the basic java.net packages.  Tsik was created as a stand-alone
package.

> So my concerns are:
> - does it use Axis? If not what's the connection to anything 
> we currently have?

See above.  The TSIK DOM APIs are quite close to (a subset of)
the Axis2/OM APIs.  

> - it appears to have its own addressing impl too?

Do you mean WS-Adressing?  That implementation is minimal in 
TSIK as of today, and can easily be changed.

> - same concerns for xml-security stuff - is this just a 
> competitor (==> split community in my mind)

I understand this concern, but I don't see that it necessarily have
to "split a community" -- care to elaborate? 

> - 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?)

There is no such roadmap, but it's not a conscious decision.  You 
have to at least attribute some ignorance to us ;)  Axis 2 looks 
very interesting.

> - 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, ...)

Quite a few developers worked on the source code since around 2000,
and a lot of the TSIK code is stable, e.g., the xkms, xpath, xml 
signature and encryption, verifier, crl, and messaging handling.

I agree two developers are too few.  But I only listed the proposed
committers.  As the proposal states, there are others who'd be 
interested in developing, but not initially as committers.

My thoughts were that, of course, if we were to go into incubation
and attract little interest in the community, we'd of course bow 
out, quietly, into the night . . .

> 
> 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 <hgranqvist@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


Mime
View raw message