OASIS ebXML Core (ebCore) TC

Submitter's message Specification:
- New content covering draft CPPA 3.0.
- Editorial clean-up.
- Error codes and descriptions.
- Acknowledgments.

Schema:
- Some typos corrected.
- HTML documentation regenerated. -- Mr. Pim van der Eijk Document Name : ebcore-au-v1.0 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-08-22 07:04:23 Revision : 2

Dear members of the ebCore mailinglist, Please find attached some feedback and comments on the Agreement Update specification. With kind regards Ernst Jan van Nigtevecht Pim van der Eijk wrote: > /Submitter's message/ > Specification: > - New content covering draft CPPA 3.0. > - Editorial clean-up. > - Error codes and descriptions. > - Acknowledgments. > > Schema: > - Some typos corrected. > - HTML documentation regenerated. > > -- Mr. Pim van der Eijk Attachment: ebcore-au-v1.0-wd03-feedback-ejvn.odt Description: application/vnd.oasis.opendocument.text

Hi Ernst Jan, Thanks for the feedback.  As for your comments at the end of section 3,  there is a distinction between what changes (e.g. a certificate) and what needs to change as a result of the change.   The answer to the second question is implementation-dependent,  e.g. an update for ebMS2 may require a change to (and reload of) a CPA if the party uses CPA,  but there are ebMS2 products that don't use CPA and/or that have a different way of storing certificate configuration.  This is up to the receiver,  the sender shouldn't need to be aware.   I will try to clarify this. You are right that there are other types of configuration updates,  such as the URL of the messaging server or IP addresses to be configured in firewalls being the common ones (at least in my experience).  The schema extensibility makes this quite easy,  and who knows a future update of the specification could standardize these updates.    As the immediate need is for certificate updates,  the idea was to focus on those first. As for using AU for CPA updates,  this could work for simple changes,  and if both parties are known to use CPA.  But CPPA3 greatly simplifies CPA formation from CPPs,  so the alternative could be to just re-merge with an updated CPP and form a new CPA, and define a similar message-based protocol for requesting a CPA. E-Health in Norway (represented on this TC) have been using this concept in production, with ebMS2/CPPA2, for over a decade, and can provide input to such a protocol.   I will provide an updated version in the next few days incorporating any comments received until then.  And if there are no objections,  engage with TC Admin a few days later to move to CSD/PR ballot. Kind Regards, Pim On 09/03/2015 10:46 AM, Ernst Jan van Nigtevecht wrote: Dear members of the ebCore mailinglist, Please find attached some feedback and comments on the Agreement Update specification. With kind regards Ernst Jan van Nigtevecht Pim van der Eijk wrote: /Submitter's message/ Specification: - New content covering draft CPPA 3.0. - Editorial clean-up. - Error codes and descriptions. - Acknowledgments. Schema: - Some typos corrected. - HTML documentation regenerated. -- Mr. Pim van der Eijk --------------------------------------------------------------------- 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

Hi Pim,  I am still working on my review. I do already have one suggestion however. I think it might be useful to split the current document into two or even three separate specs. One describing the AU framework, maybe specific ones for bindings to transport protocols and another one for the certificate update. I think this will create a more flexible framework. If there is requirement for update of another part of an agreement this could more easily be specified in a new profile. Groet, Sander Fieten              FIETEN IT e:  sander@fieten-it.com t:   +31 6 51507886 This email was sent from a mobile device. On 04 Sep 2015, at 09:10, Pim van der Eijk < pvde@sonnenglanz.net > wrote:





Hi Ernst Jan,

Thanks for the feedback.  As for your comments at the end of
section 3,  there is a distinction between what changes (e.g. a
certificate) and what needs to change as a result of the
change.   The answer to the second question is
implementation-dependent,  e.g. an update for ebMS2 may require a
change to (and reload of) a CPA if the party uses CPA,  but there
are ebMS2 products that don't use CPA and/or that have a different
way of storing certificate configuration.  This is up to the
receiver,  the sender shouldn't need to be aware.   I will try to
clarify this.

You are right that there are other types of configuration
updates,  such as the URL of the messaging server or IP addresses
to be configured in firewalls being the common ones (at least in
my experience).  The schema extensibility makes this quite easy, 
and who knows a future update of the specification could
standardize these updates.    As the immediate need is for
certificate updates,  the idea was to focus on those first.

As for using AU for CPA updates,  this could work for simple
changes,  and if both parties are known to use CPA.  But CPPA3
greatly simplifies CPA formation from CPPs,  so the alternative
could be to just re-merge with an updated CPP and form a new CPA,
and define a similar message-based protocol for requesting a CPA.
E-Health in Norway (represented on this TC) have been using this
concept in production, with ebMS2/CPPA2, for over a decade, and
can provide input to such a protocol.  

I will provide an updated version in the next few days
incorporating any comments received until then.  And if there are
no objections,  engage with TC Admin a few days later to move to
CSD/PR ballot.

Kind Regards,

Pim

On 09/03/2015 10:46 AM, Ernst Jan van Nigtevecht wrote:


Dear members of the ebCore mailinglist,

Please find attached some feedback and comments on the Agreement Update
specification.

With kind regards

Ernst Jan van Nigtevecht


Pim van der Eijk wrote:


/Submitter's message/
Specification:
- New content covering draft CPPA 3.0.
- Editorial clean-up.
- Error codes and descriptions.
- Acknowledgments.

Schema:
- Some typos corrected.
- HTML documentation regenerated.

-- Mr. Pim van der Eijk



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





Attachment: smime.p7s Description: S/MIME cryptographic signature

Interesting suggestion,  I'll think this over.  But even if the document remains a single document,  someone could define a new profile that adds or updates something (a new subtype of UpdateRequest,  or a new Protocol Binding),  and define conformance in relation to the original document (or documents) with the updates applied and having precedence over the updated.  On 09/05/2015 12:05 PM, Sander Fieten wrote: Hi Pim,  I am still working on my review. I do already have one suggestion however. I think it might be useful to split the current document into two or even three separate specs. One describing the AU framework, maybe specific ones for bindings to transport protocols and another one for the certificate update. I think this will create a more flexible framework. If there is requirement for update of another part of an agreement this could more easily be specified in a new profile. Groet, Sander Fieten              FIETEN IT e:  sander@fieten-it.com t:   +31 6 51507886 This email was sent from a mobile device. On 04 Sep 2015, at 09:10, Pim van der Eijk < pvde@sonnenglanz.net > wrote: Hi Ernst Jan, Thanks for the feedback.  As for your comments at the end of section 3,  there is a distinction between what changes (e.g. a certificate) and what needs to change as a result of the change.   The answer to the second question is implementation-dependent,  e.g. an update for ebMS2 may require a change to (and reload of) a CPA if the party uses CPA,  but there are ebMS2 products that don't use CPA and/or that have a different way of storing certificate configuration.  This is up to the receiver,  the sender shouldn't need to be aware.   I will try to clarify this. You are right that there are other types of configuration updates,  such as the URL of the messaging server or IP addresses to be configured in firewalls being the common ones (at least in my experience).  The schema extensibility makes this quite easy,  and who knows a future update of the specification could standardize these updates.    As the immediate need is for certificate updates,  the idea was to focus on those first. As for using AU for CPA updates,  this could work for simple changes,  and if both parties are known to use CPA.  But CPPA3 greatly simplifies CPA formation from CPPs,  so the alternative could be to just re-merge with an updated CPP and form a new CPA, and define a similar message-based protocol for requesting a CPA. E-Health in Norway (represented on this TC) have been using this concept in production, with ebMS2/CPPA2, for over a decade, and can provide input to such a protocol.   I will provide an updated version in the next few days incorporating any comments received until then.  And if there are no objections,  engage with TC Admin a few days later to move to CSD/PR ballot. Kind Regards, Pim On 09/03/2015 10:46 AM, Ernst Jan van Nigtevecht wrote: Dear members of the ebCore mailinglist, Please find attached some feedback and comments on the Agreement Update specification. With kind regards Ernst Jan van Nigtevecht Pim van der Eijk wrote: /Submitter's message/ Specification: - New content covering draft CPPA 3.0. - Editorial clean-up. - Error codes and descriptions. - Acknowledgments. Schema: - Some typos corrected. - HTML documentation regenerated. -- Mr. Pim van der Eijk --------------------------------------------------------------------- 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

Hi all, please find attached the agreement update document with my review comments included. These are additional to comments from my previous email which are not included in this document. Regards, Sander  Attachment: ebcore-au-v1.0-wd05_sf.odt Description: application/vnd.oasis.opendocument.text On 05 Sep 2015, at 12:05, Sander Fieten < sander@fieten-it.com > wrote: Hi Pim,  I am still working on my review. I do already have one suggestion however. I think it might be useful to split the current document into two or even three separate specs. One describing the AU framework, maybe specific ones for bindings to transport protocols and another one for the certificate update. I think this will create a more flexible framework. If there is requirement for update of another part of an agreement this could more easily be specified in a new profile. Groet, Sander Fieten              FIETEN IT e:  sander@fieten-it.com t:   +31 6 51507886 This email was sent from a mobile device. On 04 Sep 2015, at 09:10, Pim van der Eijk < pvde@sonnenglanz.net > wrote: Hi Ernst Jan, Thanks for the feedback.  As for your comments at the end of section 3,  there is a distinction between what changes (e.g. a certificate) and what needs to change as a result of the change.   The answer to the second question is implementation-dependent,  e.g. an update for ebMS2 may require a change to (and reload of) a CPA if the party uses CPA,  but there are ebMS2 products that don't use CPA and/or that have a different way of storing certificate configuration.  This is up to the receiver,  the sender shouldn't need to be aware.   I will try to clarify this. You are right that there are other types of configuration updates,  such as the URL of the messaging server or IP addresses to be configured in firewalls being the common ones (at least in my experience).  The schema extensibility makes this quite easy,  and who knows a future update of the specification could standardize these updates.    As the immediate need is for certificate updates,  the idea was to focus on those first. As for using AU for CPA updates,  this could work for simple changes,  and if both parties are known to use CPA.  But CPPA3 greatly simplifies CPA formation from CPPs,  so the alternative could be to just re-merge with an updated CPP and form a new CPA, and define a similar message-based protocol for requesting a CPA. E-Health in Norway (represented on this TC) have been using this concept in production, with ebMS2/CPPA2, for over a decade, and can provide input to such a protocol.   I will provide an updated version in the next few days incorporating any comments received until then.  And if there are no objections,  engage with TC Admin a few days later to move to CSD/PR ballot. Kind Regards, Pim On 09/03/2015 10:46 AM, Ernst Jan van Nigtevecht wrote: Dear members of the ebCore mailinglist, Please find attached some feedback and comments on the Agreement Update specification. With kind regards Ernst Jan van Nigtevecht Pim van der Eijk wrote: /Submitter's message/ Specification: - New content covering draft CPPA 3.0. - Editorial clean-up. - Error codes and descriptions. - Acknowledgments. Schema: - Some typos corrected. - HTML documentation regenerated. -- Mr. Pim van der Eijk --------------------------------------------------------------------- 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 Attachment: smime.p7s Description: S/MIME cryptographic signature

On 09/08/2015 02:02 PM, Sander Fieten wrote: Hi all, please find attached the agreement update document with my review comments included. These are additional to comments from my previous email which are not included in this document. Regards, Sander  Thanks,  a new version was uploaded with a change log. In addition below a comment disposition using section and timestamp. 2.1 16:04, CEM is discussed because the audience of this protocol will be aware of CEM and wonder what the difference is. KMIP (like EKMI previously) is more an enterprise protocol and to my knowledge is not used for B2B or across firewalls.  KMIP defines its own exchange protocol for certificates, whereas AU is intended to be used with B2B protocols like AS4, and messages are processed by a B2B MSH.  KMIP also has binary formats, AU is aligned with W3C XML Signature, as it is more natural for use with AS4 and WS-Security. 2.2, 16:21.   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).  I updated 2.3.1 to state that if Party B needs universally unique identifiers, it can reject requests that would violate this. 2.3, 10:41.  Nice diagram, thanks. 2.3, 10:45.  With the users we discussed an explicit terminateBy parameter, but people though it might not be always be possible to state in advance what the value should be.  The condition to be able to terminate is successful use of the new agreement,  and as soon as you've sent the first message successfully,  you can stop using the old one.  I have clarified this in other sections. If we would have a terminateBy,  then if the update is accepted but it turns out there is a problem anyway, there would need to be a way to cancel the termination, which would complicate the protocol.   An explicit terminate agreement would be better,  but would be another message type to implement, and as it in most cases it would be unnecessary,  they preferred to leave it out. 2.3.1, 10:39.  The discussion of the elements in the messages is in the schema documentation, which is an integral part of the spec.  Once OASIS publishes it,  the hyperlinks (at least from the HTML) will go directly to the HTML documentation. On extensibility, there is a section 3.4.  I'm adding a reference in this section. On securing the exchange, I've added a note that the protocol bindings must secure the exchange. 2.3.1, 10:42,  I've replaced immediately by without delay and added a sentence in 2.3 that update exchanges are typically asynchronous. 2.3.2, 10:52,  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.  Have clarified this in 2.3.1. 2.3.2, 10:50,  on message id,  I 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. 2.4.1, 11:01,  yes,changed to MUST. 2.4.2, 12:25,  the intention in W3C XML Signature seems to be that a certificate chain should be represented as different X509Certificates, not necessarily excluding other options. 2.4.2, 12:27,  W3C signature does not specify the order of the certificates.  Common tooling seems to use whatever order the certificates were in in the input files.  2.4.3, 12:33, 1, @@@ agreed add profiling to schema. 2.4.3, 12:33, 2, @@@ yes better not require support for this. 5  agreed,  split into sender / responder. xmldsig1-schema.xsd