[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] Business Document Envelope Committee Specification Draft 01 Working Draft 03 now available for internal review
Dear all
Below the notes I received from Ken from the discussion between Ken, Kees and Sander following yesterday's TC meeting:
>Page 3 shows a Copyright statement from 2001 - 2015 .. but the spec
>was not created before 2015 .. so why that 2001 - 2015? .. and not
>2015 only (for now .. when there is a spec update in 2016 it will be
>2015 -2016)
>In the footer it also only says 2015.
So noted.
>chapter 2.
>
>" It should be possible to identify the sender and receiver of the envelope."
> Should that be split in two requirements where the receiver
> is always mandatory but the sender is optional? (in line with MSGE-04)
Action: modify the requirement to clarify that the sender is not mandatory.
>" It should be possible to transport digitally signed and encrypted
>payload within an envelope."
> If we say the envelope specification is payload "agnostic"
> then why this special requirement? Is it up to the "creator" of the
> envelope to sign and encrypt the payload? Or should that payload
> already be delivered in encrypted/signed format? And are these two
> options (signing and encryption) always combined or can they be
> independent from each other (so signed and not encrypted, encrypted
> not signed, both encrypted and signed or nothing)
Action: modify the requirement to clarify that there should be no
restrictions on the payload from a business perspective
Action: add a requirement that payloads must be expressed in such a
way not to interfere with the XML schema ... e.g. using Base64
>" An envelope must be able to carry sufficient information about its
>included payload allowing the recipient to decide the appropriate
>processing of the payload."
> This implies that payload meta data describing the actual
> payload should always be present .. but isn't the interpretation of
> the payload and the actual processing of the payload not based on
> the actual payload it self, and so not a element of the "envelope"?
Action: clarified that "must be able" is to the specification writers
and not to the users, so reword not to leave an impression that the
information is mandatory
>" It should be possible for the receiver to verify the integrity of
>the payload after decryption."
> Again ... isn't this the responsibility of the payload
> creator to allow for this .. and not a function of the envelope.
Action: discuss the need for two hashes, one for the integrity of the
content of the payload and one for the integrity of the content after
having been decrypted
Consider that we may not need the one for after decryption as that
could be the responsibility of the payload.
>Chapter 2.1
>" The following requirements have been identified for enabling
>routing of an envelope and its payload through one or more transport networks."
> Why the "payload" in this context .. once the payload is
> enclosed in the envelope then the envelope should be routed .. and
> not be based on the contents.
Action: remove "and its payload"
>" MSGE-05 An envelope should contain information about
>identification schema used to issue the ID of the party that
>originated the envelope and the ID of the party to which the
>envelopes payload is destined."
> The envelope is destined for a receipiant .. not the
> payload (although that is inside the envelope .. and there for ends
> up at that recipient)
Action: no need to reference the payload because all payloads go to
the recipient; different processing on the payload is addressed
through other requirements.
>" MSGE-06 To be able to support use of multiple address registries
>(e.g. similar to PEPPOL SML) the
>envelope should have the ability to identify where the sender and
>receiver are registered. An example
>of use would be that one registry is used for commercial invoices
>while another may be used for customs
>information. A receiver may have identical identifiers in the two
>registries while the service addresses
>may be different."
>
> Is this a further specification of requirement MSGE-04 and
> MSGE-07? Or a separate requirement? They way I read it this is a
> further specification about how the sender/receiver are identified.
>
>Should these requirements be in a "logical" order? Now we already
>say something about the recipient in MSGE-05 and MSGE-06 where the
>recipient itself is first defined in MSGE-07
>
>Also 2.1 says something about "routing" but things like the
>date/time of the envelope, one or more payloads and payload
>identification are not routing related. So should we have a more
>"generic requirements" section?
Discussion: If we remove example and references to differing service
addresses so as to clarify that MSGE-06 is related to MSGE-04 and
MSGE-07, then MSGE-6 is offering nothing new to MSGE-05 ... can we
get clarification from the source of this requirement as to what was
intended? Can the requirement be removed during the rewrite? Is the
envelope model meeting this requirement in a way that is different than MSGE-5?
Question: do all we need to do is change cardinality to 1..n? Answer: not
Do we need another information item for registration identification?
In theory the address should be understandable, so we can probably
defer the resolution of this.
Re: MSGE-07 - could this be positioned earlier in the list of requirements?
Re: MSGE-08 - could be moved into a new section of general
requirements ... could other requirements also be regarded as general
and not routing
Re: MSGE-09 - is the optionality redundant in "should be possible"
... should be "should be able"
>Chapter 2.2
>" MSGE-12 It should be possible to identify the type of each payload
>instance in the envelope in order to
>enable a Service registry lookup to verify and identify the type of payload."
> Should this not be a requirement of the payload it self
> instead of the envelope?
Agreed that it is a useful requirement ... perhaps reword to focus on
this being a technical requirement more than a business
requirement. Perhaps remove references to service registry.
>" MSGE-13 An envelope may need to contain a reference to a relevant
>business case, documents or
>other issues that are relevant when determining how to handle the
>envelope and its content. An example
>would be an envelope containing a tender in which case a reference
>to the relevant call for tender is
>necessary in order to determine when opening the envelope content is allowed."
> Should this information not be explicit on the envelope
> instead of being derived from the payload? So a "do not look at
> payload before ..." indentifier or something like that?
Should "envelope content" be "payload" at the end of the sentence?
A question to the source: how is MSGE-13 different from MSGE-15?
>" MSGE-14 When an envelope carries multiple payloads it needs to be
>possible to give indication of what
>is the primary payload instance in the envelope."
> If the envelope contains multiple payloads then I think it
> should be up to the actual payloads to identify that they relate to
> an other document, not on the actual envelope.
Document: we expect the initial payload identification to be
sufficient and that that first payload provide enough information for
any kind of ordering of other payloads
It is up to the user community to define the interpretation of more
than one payload indicating that it is primary.
>" MSGE-15 When a payload instance is used for a single business
>document, it should be possible to
>state the Business Transaction it represents, the Syntax Message in
>which it is expressed, the set of
>business rules (Customization) applicable and the Profile in which
>it is used."
> Should these all be split into separate requirements? And
> should al this information not also be available INSIDE the payload
> it self and therefor not be element on the envelope?
> We also run the risk that this might be perceived as "too
> UBL centric" .. or is the use of ProfileID/CustomizationID generic
> enough and also applicable for other syntaxes/standards?
In rewording this requirement, each payload can have only a single
business document so clarify the requirements are always applicable
to the payload.
Should the element names be renamed so as not to be a BII(UBL) bias?
Underscore that these are properties of context, not necessarily
properties of processing.
>" MSGE-16 When a payload instance is used for a single business
>document, it should be possible to
>identify the service appropriate for processing of the business
>document. I some cases these may be
>calculated based on information covered by MSG-15 (e.g. PEPPOL), but
>this it not necessarily always
>the case."
> This looks like additional information that should be used
> to construct the uniquely identifier of the recipient of the
> envelope? And what if there are multiple payloads? Then you can not
> add these details?
Same comment about a payload is always used for a single document.
>MSGE-15 and MSGE-16 are specified as "Payload" related attributes ..
>but in reality they are used for routing (looking up the service
>where the envelope should be posted to) .. so should these be
>promoted to the envelope level instead on the payload where they are now?
Ken's view: Underscore that this metadata is describing the context
of the payload, not necessarily the procedural handling. They should
not be part of the envelope.
Kees and Sander agree, but ... in reality they are also being used
for routing. Sander suggests we discuss how MSGE-15 and MSGE-16 are
intended to be applied in the 4-corner model to clarify their use.
Ken says that routing is up to trading partners to agree on and is
out of the boundaries of the envelopes. Kees says "kind of".
>"MSGE-18 It should be possible to include a hash total of each of
>the payload instances, calculated over
>the unencrypted content of that payload, and to identify the
>algorithm that was used to calculate the
>hash."
> How do you deal with "encrypted" contents? Do you mean that
> the hash should be calculated BEFORE the encryption takes place of
> the payload contents? Or is this a hash over the actual payload
> contents (so even encrypted contents). And why per payload? Or
> should there be a hash over the envelope contents as a whole? So
> the recipient can verify the envelope as a whole? (looks like we
> missing that requirement currently)
Ask the source for more information regarding the utility of this
requirement since it seems we cannot justify it from a technical
analysis of possible attacks and integrity. For example, the
integrity of the payload in the envelope is addressed with signing
the envelope, and the integrity of the content in the payload is
addressed with signing the payload.
________________________________________
From: bdxr@lists.oasis-open.org [bdxr@lists.oasis-open.org] on behalf of Duvekot, Kees [kduvekot@Wehkamp.nl]
Sent: Wednesday, February 18, 2015 9:28 AM
To: Business Document Exchange TC
Subject: RE: [bdxr] Business Document Envelope Committee Specification Draft 01 Working Draft 03 now available for internal review
Ken, others
I have read through the specification and I have some remarks:
Page 3 shows a Copyright statement from 2001 - 2015 .. but the spec was not created before 2015 .. so why that 2001 - 2015? .. and not 2015 only (for now .. when there is a spec update in 2016 it will be 2015 -2016)
In the footer it also only says 2015.
I have some remarks/questions
chapter 2.
" It should be possible to identify the sender and receiver of the envelope."
Should that be split in two requirements where the receiver is always mandatory but the sender is optional? (in line with MSGE-04)
" It should be possible to transport digitally signed and encrypted payload within an envelope."
If we say the envelope specification is payload "agnostic" then why this special requirement? Is it up to the "creator" of the envelope to sign and encrypt the payload? Or should that payload already be delivered in encrypted/signed format? And are these two options (signing and encryption) always combined or can they be independent from each other (so signed and not encrypted, encrypted not signed, both encrypted and signed or nothing)
" An envelope must be able to carry sufficient information about its included payload allowing the recipient to decide the appropriate processing of the payload."
This implies that payload meta data describing the actual payload should always be present .. but isn't the interpretation of the payload and the actual processing of the payload not based on the actual payload it self, and so not a element of the "envelope"?
" It should be possible for the receiver to verify the integrity of the payload after decryption."
Again ... isn't this the responsibility of the payload creator to allow for this .. and not a function of the envelope.
Chapter 2.1
" The following requirements have been identified for enabling routing of an envelope and its payload through one or more transport networks."
Why the "payload" in this context .. once the payload is enclosed in the envelope then the envelope should be routed .. and not be based on the contents.
" MSGE-05 An envelope should contain information about identification schema used to issue the ID of the party that originated the envelope and the ID of the party to which the envelopes payload is destined."
The envelope is destined for a receipiant .. not the payload (although that is inside the envelope .. and there for ends up at that recipient)
" MSGE-06 To be able to support use of multiple address registries (e.g. similar to PEPPOL SML) the
envelope should have the ability to identify where the sender and receiver are registered. An example
of use would be that one registry is used for commercial invoices while another may be used for customs
information. A receiver may have identical identifiers in the two registries while the service addresses
may be different."
Is this a further specification of requirement MSGE-04 and MSGE-07? Or a separate requirement? They way I read it this is a further specification about how the sender/receiver are identified.
Should these requirements be in a "logical" order? Now we already say something about the recipient in MSGE-05 and MSGE-06 where the recipient itself is first defined in MSGE-07
Also 2.1 says something about "routing" but things like the date/time of the envelope, one or more payloads and payload identification are not routing related. So should we have a more "generic requirements" section?
Chapter 2.2
" MSGE-12 It should be possible to identify the type of each payload instance in the envelope in order to
enable a Service registry lookup to verify and identify the type of payload."
Should this not be a requirement of the payload it self instead of the envelope?
" MSGE-13 An envelope may need to contain a reference to a relevant business case, documents or
other issues that are relevant when determining how to handle the envelope and its content. An example
would be an envelope containing a tender in which case a reference to the relevant call for tender is
necessary in order to determine when opening the envelope content is allowed."
Should this information not be explicit on the envelope instead of being derived from the payload? So a "do not look at payload before ..." indentifier or something like that?
" MSGE-14 When an envelope carries multiple payloads it needs to be possible to give indication of what
is the primary payload instance in the envelope."
If the envelope contains multiple payloads then I think it should be up to the actual payloads to identify that they relate to an other document, not on the actual envelope.
" MSGE-15 When a payload instance is used for a single business document, it should be possible to
state the Business Transaction it represents, the Syntax Message in which it is expressed, the set of
business rules (Customization) applicable and the Profile in which it is used."
Should these all be split into separate requirements? And should al this information not also be available INSIDE the payload it self and therefor not be element on the envelope?
We also run the risk that this might be perceived as "too UBL centric" .. or is the use of ProfileID/CustomizationID generic enough and also applicable for other syntaxes/standards?
" MSGE-16 When a payload instance is used for a single business document, it should be possible to
identify the service appropriate for processing of the business document. I some cases these may be
calculated based on information covered by MSG-15 (e.g. PEPPOL), but this it not necessarily always
the case."
This looks like additional information that should be used to construct the uniquely identifier of the recipient of the envelope? And what if there are multiple payloads? Then you can not add these details?
MSGE-15 and MSGE-16 are specified as "Payload" related attributes .. but in reality they are used for routing (looking up the service where the envelope should be posted to) .. so should these be promoted to the envelope level instead on the payload where they are now?
"MSGE-18 It should be possible to include a hash total of each of the payload instances, calculated over
the unencrypted content of that payload, and to identify the algorithm that was used to calculate the
hash."
How do you deal with "encrypted" contents? Do you mean that the hash should be calculated BEFORE the encryption takes place of the payload contents? Or is this a hash over the actual payload contents (so even encrypted contents). And why per payload? Or should there be a hash over the envelope contents as a whole? So the recipient can verify the envelope as a whole? (looks like we missing that requirement currently)
I'm asking these questions just to get good clarification about what each requirement means and how it should be interpreted.
The rest of the document was "technical" and I think we should first get these questions clarified before I go into the technical details in order to not repeat the same questions.
Kees
p.s. I also agree with the Signature at the end of the envelope and not in an extension.
-----Oorspronkelijk bericht-----
Van: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] Namens G. Ken Holman
Verzonden: dinsdag 17 februari 2015 18:12
Aan: Business Document Exchange TC
CC: Martin Forsberg
Onderwerp: [bdxr] Business Document Envelope Committee Specification Draft 01 Working Draft 03 now available for internal review
In anticipation of BDXR committee members agreeing to my disposition of the comments received from Martin:
https://lists.oasis-open.org/archives/bdxr/201502/msg00008.html
... I have prepared Working Draft 03:
https://www.oasis-open.org/committees/document.php?document_id=55124
I was able to incorporate the W3C digital signature 1.1 schemas. The test files continue to work with the revised W3C schemas. We can await feedback regarding the XAdES schemas from our public review (unless someone on the committee knows how we can check this).
I have repaired the copy/paste error of cardinality for the payload content.
I received approval from OASIS TC Administration on the namespaces, and so they are now documented.
I have removed the reference to the empty "xml/" directory of examples since we don't have any examples to include. We can incorporate examples that are created in conformance with these draft schemas. Remember there are a few simple examples for testing purposes found in the "val/" directory.
I still need help rewriting any prose that needs to be better worded.
"See" you at tomorrow's BDXR committee conference call. Please post your questions or bring your questions to the meeting.
. . . . . . . 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.
http://www.avast.com
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]