Re: [ebcore] Groups - cppa3-specification uploaded

Hi Yngve,

    

    Many thanks for your comments!   I know you've been working in this
    field and with the earlier CPPA2 for many years,  so you have a lot
    of experience and your feedback is valuable.

    I've added some comments inline.   

    

    

    
On 03-05-17 08:55, Yngve Pettersen
      wrote:

    

    
      
      
      
      
      

        
Hi Pim!

        
Sorry for late feedback, and hope it's not too
            late
          J

        
 

        
Regarding the CPPA3, I have not be able to read
            the spec in detail but as far I can see there are some good
            things.

        
Ithink the new ServiceSpecification is fine.
            It's very nice to be able to build up the complete process
            in the CPP or CPA and show which message following the
            others. CPPA2 was difficult to follow with
            CanSend/CanReceive.

        
It's also good to see that we can state the
            counterpart role. This will really help.

        
 

      

    
    

    Yes, this change was needed to automatically form CPAs from CPPs. 
    In CPPA2 it was not obvious which CanSend to pair with which
    CanReceive and vice versa, when there are more than two roles in a
    service.

    

    
      

        
But…

        
Why changing the Packaging? In CPPA2 you could
            explain in detail how a file should be packed, encrypted and
            zipped, and also the which version of message that was used.
            This is a large step backwards I think.

      

    
    

    There are a couple of aspects:

    1)  MSH processing and the way it affects packaging.

    2)  Packaging not determined by MSH processing.

    3)  Expected data type, schema, cardinality etc. of payloads
    exchanged for a particular Service/Action.

    4)  Packaging functionality verified by the MSH,  but applied by
    application or middleware.

    

    On 1)

    Re encryption and zipping.  Already CPPA2 described signing and
    encryption in DocExchange, e.g. the {Sender|Receiver}DigitalEnvelope
    and {Sender|Receiver}NonRepudiation. In CPPA3 this is not
    done differently. For ebMS2,  there is an ebMS2SecurityBinding
    element that contains Signature and Encryption
    sub-elements that would configure how the payloads are secured.   It
    is true that in CPPA2 compression was described in the Package
    group,  and one of the earlier draft schemas of CPPA3 did so too. 
    However,  I changed my mind on this. The reason is that compression
    is an MSH feature like the other two, and AS4 models it like this, 
    so treating it like a channel (messaging protocol) feature seemed a
    better design. There now is simply a Compression
    sub-element,  at the same level as the WSSecurityBinding
    etc. elements. Some protocols support compression and others don't,
    so configuring the feature for the protocol makes more sense than
    suggesting it can be configured independently as a packaging
    option.  The change also simplified the schema a bit and (for
    ebMS3/AS4) makes it easier to map from CPPA3 to "P-Modes" and the
    product-specific configuration formats of AS4 products.   

    

    On 2)

    There still is a Packaging element (and substitutions) and
    it can be used for aspects of packaging that are not (fully)
    determined by the MSH. For example, if there are two MIME parts, 
    the relative order of those parts. Or if there is an option to
    package a payload in one of multiple ways not otherwise controlled
    by the MSH, which option is used. For example, with ebMS3, a payload
    can be carried in the SOAP body, in a separate MIME part, or as an
    external payload.  CPPA3 Packaging supports configuring
    these options in the SOAPWithAttachmentsEnvelope package
    element.  Simple package elements have a PartName attribute
    that links the "physical" package element to the "logical" part
    element (see (3) below).  An ebMS3Channel element can
    reference a package specification using the package
    attribute. In CPPA3, the package element is not required, as often
    there is only a single package for a protocol, or at least a default
    one. CPPA2 had packaging completely separate from delivery channels,
    but in practice packaging is largely constrained by the messaging
    protocol used. 

    

    On 3) 

    Following ebMS3,  the CPPA3 schema separates PayloadProfile
    from Packaging.  A PayloadProfile is a "logical"
    specification of the payload parts that are exchanged, irrespective
    of messaging protocol and packaging used.  For example,  service S
    action A is linked to one XML payload named e-prescription
    and zero or more payloads of type application/pdf named attachment.
    A CPP may link an action to multiple different channels, each linked
    to a (possibly different) package, so the payload may for example be
    in a compressed MIME part if one channel option is chosen or in an
    uncompressed SOAP body if another option is chosen.   Each payload
    part has a name, and there are references from the package to the
    payload profile. So you could specify that the e-prescription is
    to be included in the body and the attachment in compressed
    MIME parts.    

    

    The payload part definition allows references to document schemas, 
    e.g. the payload part e-prescription may be linked to
    element E in namespace N of an XML schema located at
    schema location L.  There is also an option to link a part
    to multiple schemas, for example an XSD and a Schematron document,
    against both of which it must be valid. 

    

    As for versioning, it seems to make most sense to define versions at
    the level of services, not of individual actions,  because typically
    if you for example send a V2 request, you expect a V2 response and
    not a V1 response, even if you support both V1 and V2.  So service S1
    may be linked to a number of actions linked to payload profiles
    linking the exchanged payloads to version N of a schema
    whereas service S2 is linked to payloads of version N+1.  
    In a CPP, a party could have service specifications for V1 and/or
    V2.  Then in CPA formation,  it would be determined which version is
    used with a particular counterparty.  So at this level, versioning
    seems to be supported well.

    

    Now it may be an idea to have some kind of additional structure in
    the set of service specifications of a party.  For example, an
    obsoletes/obsoleted-by relation. Then after CPA formation, all but
    the most recent formed service versions could be removed (assuming
    newer versions are preferred over others).   It would probably be an
    easy to add feature.

     

    On 4)

    Sometimes it is desirable to be able to state some constraints on
    payloads other than data type or schema that are not about the
    processing of the MSH, but constraints that submitted/delivered
    payloads must meet that are to have been addressed outside the MSH. 
    For example,  a service may require exchange of XML or PDF documents
    that are signed (by a business application or user).   In the
    definition of PayloadPart in a PayloadProfile,
    this can be expressed using the Signature and Encryption
    subelements.   I notice Compression is currently missing, 
    I'll fix that in the next update of the schema.  

    

    So in all, I don't think any CPPA2 functionality is lost.  But if
    that's not true,  it should be corrected because CPPA3 intends to
    continue supporting ebMS2 and all the features that it and CPPA2
    provided.  

     

    If you have some (anonymized etc.) sample version 2 CPP and CPA
    documents representative of your current use,  I can offer to try to
    re-encode them in CPPA3?   It could be a useful double-check to see
    no functionality is lost.

    

    

    
      

        

        
And…why change almost all tags? It's will be
            more difficult to acquire CPPA3 if you are familiar with
            CPPA2 because of the new structure, look complete new and
            strange for me.

      

    
    

    Yes it will take some time to get used to the new schema if you've
    used the old one.  When the TC started working on CPPA3 years ago, 
    the initial idea was to remain compatible with the earlier version, 
    but it was very difficult and unfinished.  Following the example of
    ebMS3, which was a new major incompatible schema, it seemed to make
    sense to make a clean start with a newer schema, also to appeal to
    new users who may have never seen the old v2 CPPA and may not be
    using ebMS2.  Even though the overall concepts are the same,
    sometimes two elements are combined in one, e.g. the new ebMS2Channel
    is a combination of a DeliveryChannel with a DocExchange
    (which in CPPA2 was always ebMS2) to simplify and flatten the
    structures, or to make CPA unification easier.   In some cases I
    think terminology has changed over the years, and the current naming
    aims to align with current practice.

    

    The schema documentation does contain detailed explanation of how
    the new elements relate to the old.  I hope that helps ..

    

    But if some of the name changes are really felt to be changes for
    the worse rather than for the better,  we can change them back of
    course.

    

    
      

        

        
I'm also concerned about the security and how
            we state the certificate details. But as I said, I have not
            read this spec in detail and had not time to compare with
            CPPA2 on this issue so it might be ok.

      

    
    

    That functionality is still there.    You can still include a
    certificate as a KeyInfo in a Certificate element, 
    and define TrustAnchor elements.  You can reference
    certificates from transports (e.g. for TLS client authentication) or
    from channels (e.g. to define the signing and encryption
    certificates).   When creating a CPA from two CPPs, a presented
    certificate (chain) is to be matched against a set of root
    certificates.  This is an advantage of CPPA from the early days, 
    trust is fully integrated in overall CPP model and processing and
    not something separate.

    

    

    
      
Med
          vennlig hilsen / Best regards
        
 

        
Yngve Pettersen

        
Seniorrådgiver
            / Senior adviser

        
Mobile
            (+47) 950 85 477

         
        
 

        
 

        

      

    
    

    Again, many thanks for taking the time to comment on the spec.   I
    hope more people will review it (and allow their reviews to be
    shared on the list),  so we can find and fix any issues.

    

    Kind Regards,

    

    Pim van der Eijk