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

Thank you for pulling this together, Kenneth!

At 2015-02-23 02:42 -0500, kenneth@alfa1lab.com wrote:
Please feel encouraged to comment, edit, discuss
and correct me everywhere you feel beneficial.

I have some feedback.

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:

That is very useful, thank you.

- "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:


- â??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.

- â??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.


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

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.

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

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.

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.

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