[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (EBXMLMSG-14) 5.2.2.12 external payloads
[ http://tools.oasis-open.org/issues/browse/EBXMLMSG-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33985#action_33985 ]
Pim van der Eijk edited comment on EBXMLMSG-14 at 6/26/13 4:49 PM:
-------------------------------------------------------------------
This may best be done in a separate profile for external payloads:
Other aspects:
- Any authentication of the external payload identified by an http:// or https:// URI. For example, the payload may be protected by HTTP authentication. The configuration (username / password) may be pre-configured, perhaps by PMode parameters. But it can also be included in the message (as special ebMS properties).
- If we assume WS-Security support including encryption, then the submitting application cannot simply specify the external URI. Instead the encrypted external payload will somehow be created by the WS-Security module of the sending MSH. So the submit() operation is different. The submitting application or middleware provides content (or a reference to content). The sending MSH processes this content and creates a reference to it, perhaps on some web server under control of the MSH.
- The sending MSH will want to remove such payloads after some time, the time when this is done could be a parameter and it could be yet another property included in the message (just like websites supporting large transfer provide such information in notification emails).
- Similarly, the deliver() operation will be different. When the payload is encryption, the receiving application or middleware should get the decrypted content, and the content validated by the WS-Security module (which may be different from a later download) so the URI of the external payload will be dereferenced before delivery.
Some of the above is functionality in proprietary messaging protocols.
- Etc.
was (Author: pvde):
This may best be done in a separate profile for external payloads:
Other aspects:
- Any authentication of the external payload identified by an http:// or https:// URI. For example, the payload may be protected by HTTP authentication. The configuration (username / password) may be pre-configured, perhaps by PMode parameters. But it can also be included in the message (as special ebMS properties).
- If we assume WS-Security support including encryption, then the submitting application cannot simply specify the external URI. Instead the encrypted external payload will somehow be created by the WS-Security module of the sending MSH. So the submit() operation is different. The submitting application or middleware provides content (or a reference to content). The sending MSH processes this content and creates a reference to it, perhaps on some web server under control of the MSH.
- The sending MSH will want to remove such payloads after some time, the time when this is done could be a parameter and it could be yet another property included in the message (just like websites supporting large transfer provide such information in notification emails).
- Similarly, the deliver() operation will be different. When the payload is encryption, the receiving application or middleware should get the decrypted content, and the content validated by the WS-Security module (which may be different from a later download) so the URI of the external payload will be dereferenced before delivery.
..
- Etc.
> 5.2.2.12 external payloads
> ---------------------------
>
> Key: EBXMLMSG-14
> URL: http://tools.oasis-open.org/issues/browse/EBXMLMSG-14
> Project: OASIS ebXML Messaging Services TC
> Issue Type: Improvement
> Components: Core Spec
> Reporter: Pim van der Eijk
> Priority: Minor
>
> Sender and receiver may want to limit the domains on which external payloads can be stored, for security or network configuration reasons.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]