Hi Yeah we can for sure have both component and data format in the same Maven component. We do this for others as well.
I think you are on the right track with your ideas. Looking forward to your contributions. On Wed, Mar 13, 2013 at 9:46 AM, Franz Paul Forsthofer <emc2...@googlemail.com> wrote: > Hi, > > the API I want to use is also available in Java 6 (see > http://docs.oracle.com/javase/6/docs/technotes/guides/security/xmldsig/overview.html). > > I had a look at the project camel-xmlsecurity. The XML signature > feature will fit well into this project. > > The XML en/decryption feature is implemented as DataFormat. I would > prefer to implement the XML signature feature as camel component with > two endpoints one for signing and one for verifying. The component > implementation has the following advantages in comparison to the > DataFormat implementation: > - The signer and verifier endpoint can have different parameters > whereas the marshal and unmarshal method of the data formater have the > same parameters. For XML signature, the signer endpoint will have > more complex parameters than the verifier endpoint. For example, for > signing you can specify transformations like xslt(s) or xpath(s) which > must be executed before signing, whereas for verifying these > transformations are contained in the XML signature and must not be > specified during configuration time. > - The DataFormatClause contained in the core project will have > dependencies to the data format implementation. Whenever the data > format api is changed you have to adapt the DataFormatClause. > > What's your opinion on that? > > Regards Franz > > >> On Tue, Mar 12, 2013 at 12:317 PM, Claus Ibson >> <claus.ib...@gmail.com> wrote: >> Hi >> >> Welcome to the community. >> >> Mind that Apache Camel supports JDK6+ so we cannot have components >> currently that require JDK7+. >> In case that API you wanna use is only avail in JDK7 onwards. >> >> We have 2 crypto components >> >> http://camel.apache.org/crypto >> http://camel.apache.org/xmlsecurity-dataformat.html >> >> Isn't your component more alike the existing xmlsecurity component from >> Camel? >> Maybe that's the place where it fits the best? >> >> I suggest to take a second look >> >> >> On Tue, Mar 12, 2013 at 7:33 AM, Franz Paul Forsthofer >> <emc2...@googlemail.com> wrote: >>> Hello, >>> >>> I want to contribute a new component for XML Digital Signature. There >>> shall be two endpoints; the signer endpoint shall sign the body of the >>> in-message and create an XML digital signature in the out-message, the >>> verifier endpoint shall verify the XML signature contained in the body >>> of the in-message and return the signed content in the body of the >>> out-message. >>> >>> The implementation shall be based on the JRE API for XML Digital >>> Signature >>> (http://docs.oracle.com/javase/7/docs/technotes/guides/security/xmldsig/overview.html) >>> which fulfills the requirements of the XML signature specification >>> (http://www.w3.org/TR/xmldsig-core/). >>> >>> The first version shall support >>> >>> · RSA and DSA keys >>> · enveloping signatures >>> · X509Certificate element as children of the KeyInfo element >>> · the canonicalization algorithms >>> o http://www.w3.org/TR/2001/REC-xml-c14n-20010315 >>> o http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments >>> o http://www.w3.org/2001/10/xml-exc-c14n#"; (needs >>> inclusive namespace prefix list, we should not support this algorithm >>> in the first implementation) >>> o http://www.w3.org/2001/10/xml-exc-c14n#WithComments >>> · the transform algorithms >>> o <all cononicalization algorithms> >>> o http://www.w3.org/2000/09/xmldsig#base64 >>> >>> I have a few questions about the contribution: >>> · Schall I add the new code to the maven project with >>> <groupId>org.apache.camel</groupId> and >>> <artifactId>camel-crypto</artifactId>? >>> · There is already a crypto component for signing and verifying >>> non-XML messages >>> (http://camel.apache.org/crypto-digital-signatures.html). >>> o Shall I add the new endpoints to this component, like >>> § crypto:signxml://<name>?<parameters> >>> § crypto:verfyxml://<name>?<parameters> >>> o or shall I create a new component “cryptoxml”? >>> · Shall I add the classes to the package >>> org.apache.camel.component.crypto ? >>> >>> Regards Franz >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Email: cib...@redhat.com >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> >> -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
