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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore message

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


Subject: Groups - ebcore-au-v1.0-wd5 uploaded


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



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