Skip to content

[ENHANCEMENT]: Signed Attachment Support via Attachment-Content-Signature-Transform #535

@davidthornton

Description

@davidthornton

Is your feature request related to a problem? Please describe...

Hi Team 👋

I'm a bit of a long time xml-crypto user but first time contributor! While it has served me well to now, I've found that signing attachments and adding their signatures into the <SignedInfo> element has required us to fork this repository to support this transform: http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Content-Signature-Transform.

Describe teh solution you'd like...

While I'm no SOAP/SAML expert, I think it is at least worth proposing that I open a feature request/pull request back upstream so that others can use the implementation of addAttachmentReference().

However, if this is out of scope of the project feel free to let me know and I'll close these requests.

My favoured solution would be for a maintainer to review the change that we've proposed, and optionally provide a different paradigm for integration or simply let me know it looks good and I'll go ahead and add some tests and perhaps this could make it into the next release!

Describe the alternatives you've considered...

In coming up with this enhancement request, I have explored different node packages that might support signed attachments to XML documents, and not really found anything that natively supports it - and there are real world systems that require this as a part of their operational spec.

I've also considered using the Customizing Algorithms (https://github.com/node-saml/xml-crypto?tab=readme-ov-file#customizing-algorithms) section of the documentation but it appears that you can only select/sign an XML node that exists in the document, so the current implementation will throw an error or require a reference that can't/shouldn't exist in our documents.

There might also be security considerations to this, but given that these production systems exist, it would probably be better to scope in the security consideration rather that for this to live as a fork in all clients' codebases.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions