BDE requirements

[kenneth@alfa1lab.com]

Dear all

As agreed at our last TC meeting I have tried my best to draft a 
complete set of requirements for the BDE based on known requirements and 
discussions:

https://www.oasis-open.org/committees/document.php?document_id=55132&wg_abbrev=bdxr

Please feel encouraged to comment, edit, discuss and correct me 
everywhere you feel beneficial.

The requirements are written so as to match the conclusions of the 
discussion that followed our last TC meeting (recap of the discussion 
here: https://lists.oasis-open.org/archives/bdxr/201502/msg00016.html). 
Some of these conclusions include action items to make changes to the 
working draft 03 of the BDE specification, why the draft BDE 
requirements may differ from what was implemented in the BDE 
specifications wd 03.

I have as well created a simple gap analysis / requirements mapping 
between the first draft of the BDE requirements and the CEN BII 
requirements that were submitted to the TC:

https://www.oasis-open.org/committees/document.php?document_id=55133&wg_abbrev=bdxr

A few thoughts on some of the requirements/implementations:

- "InstanceHashAlgorithm", is there any reason why the user must be 
able to specify the hash algorithm used or could we improve usability by 
removing this field and instead specify which algorithm to use?

- “PayloadInstanceEncryptIndicator“, could it include be a 
reference to the encryption method used (if any) instead of just an 
indicator as to whether encryption was used?

- “PayloadInstanceProfileID“ and “PayloadInstanceServiceID”, I 
believe these two could be combined into one since the original 
requirement is that the other is only necessary if the one is not 
present (BII requirements MSGE-15 and MSGE-16). The customization ID is 
a different animal from the profile ID by the way. The customization ID 
is commonly used to indicate a user community's individual requirements 
to a document (for example making it mandatory to always include certain 
information in a document), whereas the profile ID defines a business 
context. However:

- "CustomizationID" is, I believe always included in the business 
document itself. So why do we need to have it in the envelope also? Or 
should there perhaps be a customization ID for the envelope itself?

Finally a note on the "hash of the unencrypted document" discussion: 
How would you go about verifying the integrity of a document in cases 
where the sender must remain anonymous? It is my understanding that if 
signing the envelope then the originator would appear in the signature. 
If including the hash of the encrypted document then anyone tampering 
with the envelope could also replace the hash. So I am guessing that the 
origin of the requirement is to be able to somehow enable that the 
integrity of the original document can be verified without revealing the 
identity of the sender.

Best regards,

Kenneth