Submitter's message Processed review comments from Ernst Jan van Nigtevecht.
Added note that CPPA3 is in draft, and references to it are non-normative.
In Abstract, sections 1.1, 2.3 and 2.4.3, explain that the AU messages do not constrain how parties manages configuration information.
In the XML schema for AgreementUpdateRequest, remove the .
This caused ambiguity with schemas extending UpdateRequest.
New appendix Appendix B to illustrate extensibility.
Updates due to feedback from Sander Fieten:
Diagram added to show the message flows.
If identifiers are not universally unique, a recipient needs to create an agreement within a partner context, since another partner may have another agreement with the same identifier. Some care is needed to avoid overwriting an agreement with another partner (potential vulnerability). Updated 2.3.1 to state that if Party B needs universally unique identifiers, it can reject requests that would violate this.
Additional references to schema documentation.
Added a note that the protocol bindings must secure the exchange.
In 2.3.2, clarified that the first bullet is that the AS4 AgreementRef has to match the agreement in AU request message. The second is about the request and response.
Add a note to 4.1 that exchanges can be implemented as One Way or Two Way, if the latter, the RefToMessageId would be used for response.
The intention in W3C XML Signature seems to be that a certificate chain should be represented as different X509Certificates, not necessarily excluding other options.
State that RetrievalMethod must not be used because the referenced certificate may not be secure.
Clarified Certificates to be restricted to X.509 tokens, not the other token types that XML Signature supports.
In 3.1, add note that the schema documentation profiles XML Signature's KeyInfo.
Separate Initiator and Responder Conformance. -- Mr. Pim van der Eijk Document Name : ebcore-au-v1.0-wd5 Description The ebCore Agreement Update specification defines message exchanges and an XML schema to support the exchange of agreement update requests and positive or negative responses to such requests. The main initial application of the specification is the exchange of X.509 certificates for certificate rollover, but offers extensibility for other types of updates. The specification is based on the concept of communication agreements and the creating of new agreements as independently identified updated copies of existing agreements. The specification supports ebMS2, ebMS3 and AS4 but can also be used with other protocols that have a concept of communication agreement. Download Latest Revision Public Download Link Submitter : Mr. Pim van der Eijk Group : OASIS ebXML Core (ebCore) TC Folder : Contributions Date submitted : 2015-09-09 10:24:33 Revision : 5