ISSUE-67: Revise XSLT transform; it's currently octet-stream to node-set.
Revise XSLT transform; it's currently octet-stream to node-set.
- State:
- CLOSED
- Product:
- Raised by:
- Raul Benito
- Opened on:
- 2008-10-21
- Description:
- Related Actions Items:
- No related actions
- Related emails:
- Draft minutes for Jul 28 (from cantor.2@osu.edu on 2009-07-28)
- Propose we close the following issues (from frederick.hirsch@nokia.com on 2009-07-24)
- Agenda: Distributed Meeting 2009-04-21 (from frederick.hirsch@nokia.com on 2009-04-17)
- Agenda: Distributed Meeting 2009-04-07 v2 (from frederick.hirsch@nokia.com on 2009-04-06)
- ISSUE-67: xslt transform revision? (from tlr@w3.org on 2009-04-06)
- revised F2F minutes 21-October 2008 for approval (v2) (from frederick.hirsch@nokia.com on 2008-11-04)
- Fw: xmlsec minutes from 21 October (from brich@us.ibm.com on 2008-11-03)
Related notes:
norm...XProc pipeline would output nodeset...would not make sense to have c14n...as that would output octet stream
<klanz2> All this XML == XML' ? Is allover the place in XML and causes so many headaches ... http://www.w3.org/TR/xslt#strip
<klanz2> and many more places and so on ...
frederick...these two requirements are linked...looks like must do both
<fhirsch3> removing the requirement to allow transforms to move from octet stream to nodeset and back as well as enabling c14n only has pre-hash signing step could greatly improve performance, simplification
<fhirsch3> can not do both!
<tlr> Konrad is unfortunately right about XSLT
<tlr> http://www.w3.org/TR/xmldsig-core/#sec-XSLT
<tlr> ISSUE: Revise XSLT transform; it's currently octet-stream to node-set.
<trackbot> Created ISSUE-67 - Revise XSLT transform; it's currently octet-stream to node-set. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/67/edit .
frederick...not arguing against "sign-what-you-see" but did we make this more complicated than what was needed?
bal...whole reason for xform chains was for document subsets
<klanz2> Document subsets is XPointer
frederick...do we really need the transform chain mechanism?
<klanz2> Imagine Database A and Database B ....
bal...do you need to have subselection of URI-addressable parts?
<klanz2> and you send a detached signature from A to B ...
<klanz2> and the transforms dereference data from those data bases and the signature shall verify without actually transferring the data#
<klanz2> so would could make this a NON use case
<klanz2> but currently these things are used ...
tlr...XSLT transform requirement will constrain us...unless dealt with somehow
Subtopic: XProc futures
norm...going to CR the end of this week
norm...may get uptake early next year
norm...if case that dsig is atomic operation with few options, could argue that is part of XProc
norm...seems more complicated, would be compound steps, more than can be added to XProc
rdmiller...some work has already gone into this dsig+Xproc step/steps, will share later
<klanz2> is an XProc chain delivering the same output if executed on different processors ...
<klanz2> I mean if you stuck it into a digest will it deliver the same digest
<klanz2> maybe that is an interesting idea and then all other specs would have to assure that their output is canonical to some extend ..
konrad...if security is of concern to authors of XML apps, should have canonical form
tlr...most specs tell how to parse, not how to serialize, canonicalize
<klanz2> Security is inconvenient and costly, but is necessary to assure long term survival of any technology ...
Display change log