OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [bdxr] BDE requirements

Hi Ken

Thanks for this!

Please see my comments below.

Best regards,


On 2015-02-23 14:20, G. Ken Holman wrote:
- "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?

I believe the reason is that there is a plethora of hash algorithms
available to use, some easier than others and some more full-featured
than others.  I do not believe their use is self-identifying. For
examples, a user may wish to specify MD4, MD5, SHA1, SHA2, SHA256, or
any of dozens of hash algorithms listed here:


By all means, if there is a value for the user in being able to choose which hash algorithm to use, let's keep it in there. My question was if we could simplify the use a bit by specifying that hash totals was always to be generated with for example SHA256. But if there is not one shoe that fits all then we leave it as it is.

- “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?

I see encryption as different than a hash, in that it is somehow more
private.  Also, I see the hash being a property of the envelope
describing the integrity of the clear text of the document, but the
encryption of the document as being the business of the document
itself and not the envelope.  Your question prompted me to ask myself
if we could do without even the encryption indicator, but I think the
indicator has a purpose:  if the envelope processing knows the
document is not encrypted, that is a signal that the hash can be used
by the envelope processing to verify the integrity of the clear text.
If the payload is encrypted, the envelope processing software can't
use the hash but the recipient could.

And the hash is an easily auditable or verifiable string to compare
by a human user.  Consider how MD5 hashes are used by software sites
that have mirror distributions:  a user downloading a mirror copy can
compare its hash against the published hash to assess the integrity of
the download.  An example is on https://www.openoffice.org/download/
where you can see a number of hashes published (such as
for the MD5 for the Windows install).

Similarly, a recipient of an envelope with a hash can ask the sender
"is this the hash you sent to me?" if they think an interloper has
swapped both the encrypted content and the hash content.

Yes, I agree with everything you wrote above. My question was if "PayloadInstanceEncryptIndicator" could be replaced with a "PayloadInstanceEncryptionMethod". The PayloadInstanceEncryptionMethod would be not-present if no encryption was used, and in case encryption was used would hold the algorithm used for encryption.

- “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.

Sure, but if the envelope fields are populated with the document
fields and the sender wishes to specify some kind of overriding
process, there would be no room for it.  When I read this it made
sense to me that copies of the document context metadata in the
envelope were important and that an envelope specification of context
was also necessary.

I'm not sure I understand or see the use case where both the ProfileID and ServiceID would be present, but I'm not religiously opposed to having both of them in the spec either. If you believe that the necessity is there then no objection from me.


- "CustomizationID" is, I believe always included in the business document itself. So why do we need to have it in the envelope also?

Because the business document might be encrypted, and I think the
less that business envelope software looks in on any payload, the
better.  Also, especially if all of the document contexts are
applicable to satisfy CEN/BII but they are found in different places
in the payload for a UBL instance or a UN/CEFACT instance, the payload
software won't know where to look for such information.

And, after all, we are talking about a business envelope instead of
just a transport envelope, so I think the business context information
is important to have available in the envelope.

I strongly believe the envelope software should not be looking in on
the payload.

Is there any scenario where the business envelope software would need to know the CustomizationID? Will anyone ever need to know the CustomizationID except for understanding how to read the business document? For service routing etc. we already have the ProfileID and ServiceID.

Or should there perhaps be a customization ID for the envelope itself?

Interesting question ... but I think the payload service identifier is enough.

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?

I think by the envelope creator signing the envelope.  They can take
the originator's content, hash it, encrypt it, envelope it and send
it.  They have a trusted agent relationship to the originator.

So are we introducing a requirement for a third party to get involved in the creation of the envelope (in certain use cases at least)?

It is my understanding that if signing the envelope then the originator would appear in the signature.

Or the originator's agent.

If including the hash of the encrypted document then anyone tampering with the envelope could also replace the hash.

True, but the hash is a human-manageable piece of information (as I cite above).

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.

Personally, I didn't see the sender's identity as playing into it.  I
see it simply as a commonly-deployed web-oriented integrity-checking

I will await other comments but, meanwhile, I'll edit the
requirements in as you have drafted them in the DOCX file.  The
editing task includes changing all the hyperlinks from the components
to the requirements.

Anything I can do to help you just let me know!

May I please remind other members that we need the feedback ASAP so
that I can do the editing and any model and schema changes ASAP?  I am
on leave in less than 2 weeks.  It would be helpful if we could vote
on a package on Wednesday March 4 for public review (while I'm gone).
I should prepare CSD01WD04 first for everyone's review before
preparing CSD01 and PRD01.

. . . . . . . Ken

Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm | Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ | G. Ken Holman mailto:gkholman@CraneSoftwrights.com | Google+ profile: http://plus.google.com/+GKenHolman-Crane/about | Legal business disclaimers: http://www.CraneSoftwrights.com/legal |

This email has been checked for viruses by Avast antivirus software.

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]