Hi I guess as this will be part of the upcoming 2.12.0 release, the users can make use of it as a component even if we stick to a data format implementation:
http://camel.apache.org/dataformat-component.html Babak Franz Paul Forsthofer wrote > Hi Colm, > > I made the proposal with the XML Signature component. I did not implement > it as Data Formater because I found out that the signer needs quite > different parameters than the verifier. For example, the signer needs as > input a signature algorithm, canonicalization methods, transformation > methods, whereas the verifier only needs a few input parameters like > public > key. A Data Formater would have the same paramerters for the marschaller > and unmarschaller available, whereas in a component the different > endpoints > (signer and verifier) can have different parameters. At least that's my > understanding. > > Regards Franz > > > On Tue, Aug 20, 2013 at 5:05 PM, Colm O hEigeartaigh < > coheigea@ > >wrote: > >> Hi Claus, >> >> I hadn't actually seen that JIRA when I wrote my original mail. An >> immediate question that comes to mind on looking at the patch is whether >> we >> care about roughly aligning the configuration of the new functionality >> with >> the existing "XML Security" DataFormat? >> >> For example, the supplied patch uses configuration that looks like >> "xmlsecurity:sign://enveloping?keyAccessor=#accessor", whereas the >> existing >> component uses ".marshal().secureXML(.....)". Should the new >> functionality >> be implemented as a DataFormat as well, or does this not matter? >> >> Colm. >> >> >> On Fri, Aug 16, 2013 at 2:52 PM, Claus Ibsen < > claus.ibsen@ > > >> wrote: >> >> > Hi >> > >> > There is this ticket. I assume its likely related to your proposal >> > https://issues.apache.org/jira/browse/CAMEL-6339 >> > >> > As it was a big patch and also we should double check that the source >> > code is fully ASF acceptable. I think there is some schema files or >> > whatnot copied from SUN/Oracle which may be a problem? Though haven't >> > had the time to dive in. >> > >> > Would be great if you had the time to check the patch on the ticket, >> > and maybe align with your work. >> > >> > >> > >> > On Fri, Aug 16, 2013 at 3:47 PM, Colm O hEigeartaigh >> > < > coheigea@ > > wrote: >> > > Would the Camel community be interested in a XML Signature >> DataFormat? >> It >> > > would be quite similar to the existing XML Security DataFormat, >> except >> > that >> > > it would offer XML Signature instead of XML Encryption. Both could be >> > used >> > > together to support "sign-before-encrypt" or "encrypt-before-sign" >> type >> > of >> > > functionality. >> > > >> > > I have implemented a prototype, but don't want to waste any more time >> in >> > > case there are any objections? >> > > >> > > Thanks, >> > > >> > > Colm. >> > > >> > > >> > > -- >> > > Colm O hEigeartaigh >> > > >> > > Talend Community Coder >> > > http://coders.talend.com >> > >> > >> > >> > -- >> > Claus Ibsen >> > ----------------- >> > Red Hat, Inc. >> > Email: > cibsen@ >> > Twitter: davsclaus >> > Blog: http://davsclaus.com >> > Author of Camel in Action: http://www.manning.com/ibsen >> > >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >> -- View this message in context: http://camel.465427.n5.nabble.com/XML-Signature-DataFormat-tp5737414p5737643.html Sent from the Camel Development mailing list archive at Nabble.com.
