camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: XML Signature DataFormat
Date Wed, 21 Aug 2013 09:43:36 GMT
Hi

Yeah the components gives more flexibility. And a component can also
do the same work as a data format would do, its just how its
represented in the DSL.

If there is a need for a data format for the signer, then we could add
that as a new data format, as Franz pointed out, it has different
configuration options.

Also a data format can be added later if/when needed.

On Wed, Aug 21, 2013 at 7:39 AM, Franz Paul Forsthofer
<emc2fpf@googlemail.com> 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@apache.org>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@gmail.com>
>> 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@apache.org> 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@redhat.com
>> > 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
>>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message