Maybe we can make this "alternate" method close enough to
the original one so that no difference can be seen in using the ebbp:NonRepudiationInformation in the Receipt, with the "regular" method of
recomputing digests.
When looking at the ebbp:MessagePartNRInformation children elements that are supposed to be
filled in, they could indeed be obtained - I believe - directly from the
signature header of the incoming message.
The main difference and interest of the "alternate method"
is how these digests are obtained: instead of computing them on Receiver side,
they come from the signature of the incoming message (therefore avoiding to
"stream" these potentially large attachments for computing these
digests.)
So in case we accept this alternate option, we could have
some text like the following:
"When the User message has been signed, a Receiving MSH MAY
reuse the contents of ds:Signature/ds:SignedInfo to generate the content of the
eb3:Receipt/ebbp:NonRepudiationInformation element."
(meaning implicitly that the Receipt does not have to exceed what has been
signed).
This supports the optimization (streaming) above mentioned,
avoiding the need to recompute these digests.
So the criterion for obtaining digests that way - for those
AS4 implementations that are able to do this "reuse" - is not so much the size
of the incoming message, but whether or not the incoming message is
signed.
A question remains - raised by Pim - as to whether we allow
the Receipt to target specific payload parts, or to cover exactly what the
incoming Signature was covering, or to always cover all.
Jacques
Durand, Jacques R. wrote:
0D4373E9E1236F42AB63FD6B5B306AA3C0D802@SV-EXCHANGE.fjcs.net
type="cite">
I am not an NRR expert, so I may miss something
here...
But the interest of this approach, is that - for
large payloads - it is not necessary for the Receiver to recompute digests
(problematic when using streaming for message delivery) before sending a
Receipt .
In case that is not a stupid idea, I would still only
promote it as an *option* available in case of large
payloads...
Hypothetically,
if AS4 does end up support alternative methods for NRR with this new proposal
covering the "large payloads" use case, how do you see the Receiver MSH invoking
one NRR method over the other? Is this a dynamic determination at runtime
that the payload qualifies as "large", or is this something that is more of a
static configuration determined by Pmode parameters and trading partner
relationships?
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php