[
https://issues.apache.org/jira/browse/WSS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Valeri updated WSS-242:
-----------------------------
Summary: Signing EncryptedData or EncryptedKey elements creates extraneous
ID elements (was: Signing EncryptedData or EncryptedKey elements creates
duplicate ID elements)
> Signing EncryptedData or EncryptedKey elements creates extraneous ID elements
> -----------------------------------------------------------------------------
>
> 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: Ruchith Udayanga Fernando
> 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: [email protected]
For additional commands, e-mail: [email protected]
