[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Your issue DSSX-13: TransformedDocuments
Hi Juan Carlos, happy new year! As the holidays are over I'm about to solve all the remaining open issues that stacked up in the DSS-X issue tracker. Here I found the item DSSX-13 (https://issues.oasis-open.org/browse/DSSX-13) filed by you. Here is subject: 2. RequestTransformedDocument. DSS Core 1.0. This element does not seem to work in the case that the request contains more than one XML (XAdES) signatures. It only contains one attribute for identifying the number of a ds:Reference. And the text only speaks about "the" XML signature. If the text is changed to make it clear that the integer i value in the attribute corresponds to that ds:Reference that occupies the ith position once the request has been serialized, then this could work. You pointed out a quite relevant topic! While considering the impact of multi-signature input we stumbled about this topic, too. Here are my concerns regarding (Return)TransformedDocument: - The optional input 'ReturnTransformedDocument' refers to transformations only, not to signatures. A SignaturePtr is missing here. - The optional output 'TransformedDocument' refers to transformations only, not to signatures. A SignaturePtr is missing here. -The byte zone selection mechanism of PDF signatures can be considered to be a transformation, too. So it should be represented by TransformedDocument. The element 'WhichReference' of optional output 'TransformedDocument' is mandatory what's not matching the PDF case. Solving these requirements adds additional complexity to the core. This leads to the questions 'What does the user get in return'? I'm not quite sure about the use case of the TransformedDocument mechanism at all. Is it a debug feature to track down failed validations? Wouldn't it also be useful to request partial transformations? What client is able to interporet the different transformation elements within a XMLDSig and take advantage of the transformed documents _but_ cannot transform on its own? What about confidentiality? A decryption transformation applied may reveal secret information. As you pointed out these shortcomings are in place since DSS 1.0 and no one ever complained. So I would assume that this feature is of no/low practical use! My proposal is to drop the 'transformed' feature from the core as the detail level of the output is a better match for the validation protocol. What's your view? Greetings, Andreas -- Andreas KÃhne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]