W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2009

ACTION-127: Tade-offs between different extensibility mechanisms

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 17 Aug 2009 13:33:44 +0200
Message-Id: <9DD68014-E447-4730-94D5-DABF6308391B@w3.org>
To: XMLSec WG Public List <public-xmlsec@w3.org>
Cc: Thomas Roessler <tlr@w3.org>
I propose adding the following text above section 2.1.2, under Best  
Practice 3 ("Consider avoiding XSLT Transforms"):

> Instead of using the XML Signature XSLT transform, deployments can  
> define a named transform of their own, by simply coining a URI in  
> their own domain that can be used as the Algorithm.  How that  
> transform is implemented is then out of scope for the signature  
> protocol -- a named transform can very well be built in XSLT.

> In deciding whether to pursue this avenue - instead of embedding  
> XSLT transforms in-line with the signature - considerations will  
> involve the ease of deployment and flexibility:  When the XSLT  
> transform mechanism is used to transmit transforms inline, then the  
> signer can change the untransformed data format and the  
> transformation without having to synchronize with the verifier, as  
> long as the result of the transformation meets the verifier's  
> assumptions.  In some use cases, this flexibility may prove  
> valuable.  Deployment of a named transform will require that signer,  
> verifier, and any intermediaries that need to process the transform  
> output, be aware of the identifier and the meaning of that transform.

I don't know if there's much more we'd want to say about this; input  
welcome.

FWIW, I consider my action item closed.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>
Received on Monday, 17 August 2009 11:33:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:59 GMT