[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Issue 104: Signature Transform
Hi Peter, Sorry - that was a typo. I mean base 64 encoded; I excluded the EncodingType attribute because I believe that the default, in the absence of the attribute, is base 64. If that's not the case, then I'll just make the attribute explicit. Merlin r/pdapkus@bea.com/2003.07.01/14:34:46 >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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]