[ https://issues.apache.org/jira/browse/WSS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-242. ------------------------------------- Resolution: Fixed > Signing EncryptedData or EncryptedKey elements creates extraneous Id > attributes > ------------------------------------------------------------------------------- > > Key: WSS-242 > URL: https://issues.apache.org/jira/browse/WSS-242 > Project: WSS4J > Issue Type: Bug > Components: WSS4J Core > Affects Versions: 1.5.9 > Reporter: David Valeri > Assignee: Colm O hEigeartaigh > Fix For: 1.5.9, 1.6 > > Attachments: WSS-242-1_5_x.patch, WSS-242-trunk.patch > > > If the action order on the outbound side is encrypt then sign and the > signature parts include the XML Encryption elements by name and namespace, > the signature action introduces a namespaced (wsu) Id attribute on the signed > XML Encryption elements. > <xenc:EncryptedData xmlns:xenc="..." Id="EncDataId-659" > Type="http://www.w3.org/2001/04/xmlenc#Element"> > becomes > <xenc:EncryptedData xmlns:wsu="..." xmlns:xenc="..." Id="EncDataId-659" > Type="http://www.w3.org/2001/04/xmlenc#Element" wsu:Id="id-663"> > The signature is created with the reference to the wsu:Id attribute. The > second attribute is not schema valid per the XML Encryption spec data > structure [1]. As the XML Encryption spec already defines an Id attribute on > the appropriate data structures, WSS4J should leverage this preexisting > attribute when creating signatures that reference the primary structures from > XML Encryption. > As the XPointer definition requires that the attribute referenced is a schema > defined ID [2], the preexisting Id attribute meets this requirement. While > it could be considered a slippery slope to alter the signature code to > accommodate the specific structure of arbitrary elements to be signed, the > XML Encryption elements are well know structures and are deeply ingrained in > WSS4J. Therefore, I feel that this change has a place in WSS4J. A more > complete solution would include a pluggable strategy for allowing users to > inject/reuse IDs on a per element basis; however, this issue and its patches > are meant to resolve the immediate need related only to XML Encryption > elements. > [1] http://www.w3.org/TR/xmlenc-core/#sec-EncryptedType > [2] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#shorthand -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org For additional commands, e-mail: wss4j-dev-h...@ws.apache.org