Re: [ebcore] Groups - ebcore-au-v1.0 uploaded

[Pim van der Eijk <pvde@sonnenglanz.net>]

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