Comments on PEPPOL AS4 Profile v.2.0.0
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
$
%
123
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABCDEFGHIJKLMNOPQRSTUVWX
1
IDSubmitter nameSubmitter e-mailParagraphTypeCommentProposed changeTICC CMB Notes and Decision
2
1Gait Boxmangait.boxman@tiekinetix.com4.2added requirement not needed and not wantedIn 4.2, the port is limited to 443 only, which causes trouble for systems that have the AS4 system in parallel to e.g. a web server running on https as well, or running other webservices that occupy the same port. This limitation is not needed as clients can connect to any port that is open for access, whilst addressing through the SMP allows for alternative ports, just like with AS2. If there are implementations that fail to support alternative ports in the URL, they fail to comply with the https scheme, and should be repaired, rather than adding an unnecessary burden on the receiving service that then needs to separate https handling from the AS4 access point software in order to support mutliple serivces and software packages listening to the same ip:port whilst acting on different url paths.Remove the limitation to port 443, allow https scheme https://hostname:portnr/path as per https URL scheme.The limitiation to port 443 is removed. But avoid that all ports need to be open for outgoing traffic, it was decided to limit the port to be 443 or in the range 44300 (incklusive) to 44399 (inclusive) so that a) outgoing ports can be limited and b) non-standard ports can be used
3
2Martin Forsbergmartin.forsberg@ecru.se2geI read the changelog to be the changes compared to version 1 of PEPPOL AS4 profile. But that seems not to be the case. When publishing this as an approved spec, then take out the changelog or list the changes compared to the first version.TICC CMB requests a ChangeLog from PEPPOL AS4 profile V1 to PEPPOL AS4 profile V2. And please remove the heading "Version 0.9.2"
4
3Martin Forsbergmartin.forsberg@ecru.se4.2geTransport level security is required and it is specified how. In the v1 of the profile, TLS was not used but only message encryption. We agree with the decision to add TLS, but the profile should make it more clear that also message encryption is required. As it is now, it can be deduced by the P-mode setting in table 5 (4.7).
The specification would benefit from introducing/describing the fact thattwo (three with signatures) security mechanisms are deployd.It is mentioned in chapter 1, last sentence. It needs to be part of the new ChangeLog.
Please add a sentence to chapter 4.7: "AS4 message level encryption MUST be used even though TLS is used."
5
4Martin Forsbergmartin.forsberg@ecru.se4.4geIt says that "If a MSH is able to execute custom validations of the payload of a User Message" then a check can be done on the addressee. But both the service identifier (Action and Service) and finalRecipient are part of the "ebXML User Message" section and there is no need to actually validate the payload to see if the finalRecipient is known.

Or does custom validation also mean that the accesspoint checks that these values corresponds/match (that is, the FinalRecipient=SBDH/ReceiverParty=Invoice|Order.../../EndpointID).
If a MSH is able to validate the SBDH payload inside the AS4 User Message during the ebMS message processing, it is RECOMMENDED that the Access Point includes the check on the addressee.
6
5Martin Forsbergmartin.forsberg@ecru.se4.5geSweden is in a parallel to PEPPOL also implementing eDelivery for other domains. The PEPPOL Profile seems to fit our need to a very high degree and only a few configurations would need to be changed. One thing that would be helpful would be if the PMode.Initiator.Role and Responder. Role would be assigned more generic identifiers that can be used also outside of PEPPOL. Such as urn:eu:ec:cefxyz:edelivery_ap:sender/receiver. That way only the PartyId.type would need to be adapted.Lets ask Martin for details what the motivation is and why SBDH is not an option
7
6Martin Forsbergmartin.forsberg@ecru.se4.6ge"When sending the business document the Access Point MUST set PMode[1].BusinessInfo.Service to the PEPPOL process identifier as specified in the PEPPOL BIS."
Proposal:
When sending the business document the Access Point MUST set PMode[1].BusinessInfo.Service to the PEPPOL process identifier as specified for the business document.
Rationale: No only PEPPOL BISes are exchanged.

Same comment for Service.Type and Action
Agreed to replace "PEPPOL BIS" with "business documents".
8
7Martin Forsbergmartin.forsberg@ecru.se4.7geDescribe in clear text that payload encryption is mandatory.See ID 3
9
8Martin Forsbergmartin.forsberg@ecru.se4.1geQuestion: when using payload encryption and compression in combination. Is the compressed content encrypted? Or is the encrypted content compressed? (should have significant effect on the compression efficiency.)First compress, than encrypt, see
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+-+1.13#eDeliveryAS4-1.13-Benefits
Add a note in chapter 4.10 that compression comes before signing and encryption
10
9Davide Ciannamea IT-Abteilüng
Enercom Swiss Finance SA
it@enercomswiss.com4.1edIn reference to the following sentence: "Receiving access points MUST configure TLS on port 443" we proposed following change"Receiving access point MUST configure TLS v1.2 on port 443 with configuration https to be configured in your access point".Chapter 4.2: TLS v1.2 MUST be supported. Older versions (SSL v2, SSL v3, TLS 1.0 and TLS 1.1) MUST NOT be used. Versions newer than TLS v1.2 might be used upon mutual agreement via the TLS handshake.
11
10Davide Ciannamea IT-Abteilüng
Enercom Swiss Finance SA
it@enercomswiss.com4.1edIn reference to the following sentence: "Sending access points need only to allow outbound transmissions using port 443" we proposed following change"Sending access point MUST only to allow outbound transmissions using port 443 with the specific configuration https to be configured in your access point".See ID 9
12
11Davide Ciannamea IT-Abteilüng
Enercom Swiss Finance SA
it@enercomswiss.com4.4edIn reference to the following sentence: "The errorCode attribute of the generated Error MUST be set to EBMS:0004 (Other error) and its severity attribute MUST be set to failure." we proposed the following change, being a problem of communication to the destination access point."The errorCode attribute of the generated Error MUST be set to EBMS:0005 (ConnectionFailure) and its severity attribute MUST be set to failure".Rejected. 0004 is correct.0003: Although the message document is well formed and schema valid, some element/attribute value is inconsistent either with the content of other element/attribute, or with the processing mode of the MSH, or with the normative requirements of the ebMS specification.
0005: The MSH is experiencing temporary or permanent failure in trying to open a transport connection with a remote MSH.
13
12Davide Ciannamea IT-Abteilüng
Enercom Swiss Finance SA
it@enercomswiss.com6.2obIn the following reference "Note that an Access Point MAY use a "generic" P-Mode to receive the registered business documents" we can hypothesize that the dynamic discovery of an Access Point could be indicated in this sentence because the dinamic discovery uses a generic P-mode configured in the access point.-Split chapter 6.2 into 2 pieces:
a) SMP transport profile identifier
Stating only the transportProfileIdentifier (there is a typo in the current version)
b) AS4 and dynamic discovery
Outline that new P-Modes may need to be created per document exchange and outline what SMP response values fit where in a PMode. Also a note that this feature is non-standard AS4 might be worthwhile.
14
13Davide Ciannamea IT-Abteilüng
Enercom Swiss Finance SA
it@enercomswiss.com6.2edWe proposed the following addition to the end of paragraph 6.2Receiver Access point records the Sender Access Point metadata in SMP and configures its PModes to be able to accept messages from trusted senders that are not previously configured in the PMode.See ID 12
15
14Gregory Nickmans
Advalvas-Europe
gregory.nickmans@advalvas-group.com5inconsistancyPMode.Initiator.Role and PMode.Responder.Role have a different fixed value then described in chapter 4.5 urn:fdc:peppol.eu:2017:roles:ap:as4 vs urn:fdc:peppol.eu:2017:roles:ap:sender and urn:fdc:peppol.eu:2017:roles:ap:receiverUpdate chapter 5 to make it in line with chapter 4.5Align chapter 4.5 with Table 7 - the inconsistencies need to be resolved
16
15Philip Helgerphilip@helger.com4.9according to the CEF profile the type attribute of the message properties “originalSender” and “finalRecipient” must be used. But please note that there is an issue with this attribute in the ebMS specification as it is not included in the XSD defining the ebMS header and therefore AS4 implementations executing schema validation of the header cannot handle this attribute (see also issue #2 in the OASIS ebMS TC’s issue tracker). In e-SENS and in CEF conformance testing this attribute isn't used, so it’s unclear whether it will be interoperable!Issue: https://issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2
Include in the discussion with Martin Forsberg on ID 5; suggestion to remove the attribute "type" under the precondition that it is otherwise possible to clearly identifiy that the role is "PEPPOL AccessPoint"
17
16Philip Helgerphilip@helger.com4.9Also related to these properties is that in the CEF profile it is stated that "The consumer SHOULD validate that, for any message delivered to it, the values of the AS4 Four Corner message properties match the values of the corresponding SBDH values.”. The consumer system is the back-end system, so this mixes responsibilities! It makes the integration between AS4 gateway and back-end more complex as these properties need to be exchanged. Additionally it is unclear what the consumer should do in case the value do not match. This results in unpredictable behaviour.
18
17Philip Helgerphilip@helger.comgeThere is no normative statement on the value to use for ConversationId. To prevent interoperability issues I would recommend to specify to use the default value (as it was in the first profile)Please add the sentence from PEPPOL AS4 profile V1:
As the eb:ConversationId element is required it MUST always have a value. If no value is included in the submission of the business document to the Access Point, the Access Point MUST set the value of eb:ConversationId to “1” as specified in section 4.3 of [ebMS3CORE].
19
18Philip Helgerphilip@helger.comgeThat the P-Modes should be dynamically created based on the meta-data retrieved from the SMP is completely missing from the document. See ID 12
20
19Philip Helgerphilip@helger.comgePlease remove me from the Contributors listApproved
21
20
22
21
23
22
24
23
25
24
26
25
27
26
28
27
29
28
30
29
31
30
32
31
33
32
34
33
35
34
36
35
37
36
38
37
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
Main menu