RE: Explanation of section 4.5 of transform note

Pratik Datta wrote on 2009-03-19:
> Trying to clarify section 4.5 of the transform note
> http://www.w3.org/2008/xmlsec/Drafts/transform-
> note/Overview.html#extensibility

Thanks, that helps, particularly since you still have this notion of
Transforms in the document, and I wasn't clear on how that related to the
two example WS Transforms you discussed.

> We are proposing a new transform model, which is a radical departure from
> the current model, and it doesn't have the current concept of a
"transform".
> (With the exception of XSLT and decrypt transform, that we reluctantly
added
> back).

I think this has to be determined, and if we're keeping the idea of
Transforms at all, that argues to me more for adapting your proposal to fit
into the *existing* syntax/model. In other words, either we're eliminating
generic transforms or we aren't. I'm of the opinion we should.

> With the current transform model, people are free to define new
transforms,
> and they have. In this section I have taken two such transforms from WS-
> Security spec and attempted to map them to the new transform model.  This
is
> just an exercise to validate the new model; the WS-* specs are frozen and
> not expected to change.

I think that's open to question. If WS-Security doesn't ever plan to support
XML Signature 2.0, its value to me at least goes somewhere close to zero.

I realize it's not our task to even debate that, but I would phrase this
more as "any subsequent change to the WS-* specs are ignored for the
purposes of this discussion".

> To map the STR-Transform to the new model, we need to split it up - part
of
> it will go into the <Selection> element, and part into the
> <Canonicalization> element. The Selection part can be represented by a new
> attribute (assuming we go with attribute extensibility)
> replaceSTwithSTR="true/false". The canonicalization part is standard.

For clarity, I think your proposal should tighten up the XML and make it
clear that with this approach, that's not replaceSTwithSTR, but
wss:replaceSTwithSTR (or whatever). It's an extension attribute in somebody
else's namespace and code would have to be added to an existing
implementation of your proposal to handle it. It wouldn't be baked in.

> This splitting up the STR-Transform gives a big benefit. One of the goals
of
> the new transform model is to accurately determine what is signed, and the
> current STR-Transform does not let you do that easily because it combines
> and replacement and canonicalization into one step, so it is very hard for
> an application to stop the STR-Transform in the middle and get the value
of
> the replaced tokens. But with the new model, an application can just
execute
> the <Selection> step and get the value of the replaced tokens, and check
the
> policy to determine if the tokens that were supposed to be signed, and
> really signed.

If the model is to add content to the Canonicalization or Selection
constructs you're defining to signal extensions, how would somebody plug in
their extension handling code to an implementation? Note that these
extensions could impact essentially any phase of the two processes. It's not
a pipeline, like the existing spec's Transforms model is, where you can
clearly plugin as needed.

Let's say you provided an implementation of your Selection construct, minus
the STR transform extension attribute (as you probably would do). How could
I plug into your code and somehow see that extension attribute and then
impact your processing to do the STR replacement?

Perhaps it would have to explicitly become event-driven/streamed, and I'd
have to handle all the events and some how inject pre/post processing on
your work?

> If this explanation makes is clearer, I can update the note with this
> content.

I think it's helpful, yes.

-- Scott

Received on Thursday, 19 March 2009 18:19:22 UTC