Re: [wss] Issue 104: Signature Transform

[Peter Dapkus <pdapkus@bea.com>]

I'm confused by what is meant by "binary-encoded".  Do you mean base64
encoded?  It seems like you don't since you're explicitly excluding the
EncodingType attribute.

Do you mean the un-encoded binary form (e.g. the raw ASN.1 bytes of an
X509 certificate)?  This may not produce valid xml.  Since we're going
to process the result as XML (by canonicalizing it) this seems
problematic.  

-Pete

On Tue, 2003-07-01 at 07:28, merlin wrote:
> Here's rough text of my proposed dereferencing transform:
> 
> . Transform Algorithm URI:
> 
> The algorithm is identified by the URI: &foo;dereference
> 
> . Transform Input:
> 
> The input is a node set. If the input is an octet stream, then
> it is automatically parsed; cf. dsig.
> 
> . Transform Output: 
> 
> The output is an octet steam. 
> 
> . Syntax:
> 
> The transform takes a single mandatory parameter, a
> ds:CanonicalizationMethod, which is used to serialize the input
> node set. Note, however, that the output may not be strictly in
> canonical form, per the canonicalization algorithm; however, the output
> is canonical, in the sense that it is unambiguous.
> 
> . Processing Rules:
> 
> Let N be the input node set.
> 
> Let R be the set of all wsse:SecurityTokenReference elements
> in N.
> 
> For each Ri in R, let Di be the result of dereferencing Ri.
> 
>   If Di cannot be determined, then the transform MUST
>   signal a failure.
> 
>   If Di is an XML security token, then let Ri' be Di.
> 
>   Otherwise, Di is a binary security token. In this case, let
>   Ri' be a node set consisting of a wsse:BinarySecurityToken
>   element, utilizing the same namespace prefix as the
>   wsse:SecurityTokenReference element Ri, with no EncodingType
>   attribute, a ValueType attribute identifying the content
>   of the security token, and text content consisting
>   of the binary-encoded security token, with no whitespace.
>   The ValueType QName MUST use the same namespace prefix as
>   the BinarySecurityToken element if the QName has the same
>   namespace URI. Otherwise, it MUST use the namespace prefix
>   x. If no appropriate ValueType QName is known, then the
>   transform MUST signal a failure.
> 
> Finally, employ the canonicalization method specified as a
> parameter to the transform to serialize N to produce the
> octet stream output of this transform; but, in place of any
> dereferenced wsse:SecurityTokenReference element Ri and
> its descendants, process the dereferenced node set Ri'
> instead. During this step, canonicalization of the replacement
> node-set MUST be augmented as follows:
> 
> * A namespace declaration xmlns="" MUST be emitted with every
>   apex element that has no namespace node declaring a value
>   for the default namespace; cf. XML Decryption Transform.
> 
> * If the canonicalization algorithm is inclusive XML canonicalization
>   and a node-set is replacing an element from N whose parent
>   element is not in N, then its apex elements MUST inherit
>   attributes associated with the XML namespace from the parent
>   element., such as xml:base, xml:lang and xml:space.
> 
> ----------------
> 
> 
> -----------------------------------------------------------------------------
> The information contained in this message is confidential and is intended
> for the addressee(s) only.  If you have received this message in error or
> there are any problems please notify the originator immediately.  The 
> unauthorised use, disclosure, copying or alteration of this message is 
> strictly forbidden. Baltimore Technologies plc will not be liable for
> direct, special, indirect or consequential damages arising from alteration
> of the contents of this message by a third party or as a result of any 
> virus being passed on.
> 
> This footnote confirms that this email message has been swept for Content
> Security threats, including computer viruses.
> http://www.baltimore.com
> 
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
-- 
Peter Dapkus <pdapkus@bea.com>