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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr-comment message

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


Subject: Re: [bdxr] Invitation to comment on Exchange Header Envelope (XHE) V1.0 - ends May 29th


Thank you for your comments and observations, Pim. I have documented them so that they are included in the TC's revision process, and will be included in the formal resolution log.

Also copying Anders Grangaard, who is leading the project from UN/CEFACT's side.

Best regards,

Kenneth


On 5/3/18, 3:47 PM, "bdxr@lists.oasis-open.org on behalf of Pim van der Eijk" <bdxr@lists.oasis-open.org on behalf of pvde@sonnenglanz.net> wrote:

    
    Here are some comments on the XHE specification
    
    1.1.2
    
    This states XHE is the successor of BDE and SBDH.  An overview of 
    changes would be useful for users of these predecessor versions. Is it 
    possible to automatically, without loss of information, convert from 
    SBDH to XHE and back?  It seems the answer is no, as some structures in 
    SBDH seem to have disappeared.
    
    1.1.3
    
    States that service and correlation information can be added. How is 
    this done?
    
    1.2.4
    
    “validation” is a noun (“to validate” is a verb)
    
    1.3
    
    Use the suggested labels from 
    http://docs.oasis-open.org/templates/w3c-recommendations-list/w3c-recommendations-list.html. 
    
    
    In particular, change label “[XMLDSIG]” to “[XMLDSIG-CORE1]”,  to make 
    clear you are referencing the 1.1 and not the 1.0 version.
    
    1.4
    
    If you reference the 1.1 for XML Signature, why are you referencing the 
    v1.0 of XML Encryption and not the 2013 V1.1?
    
    2.3
    
    Why is there at most one From Party?    Theoretically,  for some use 
    cases,  there could be multiple From Parties.
    
    Why is there at least one To Party?  Theoretically, for some use cases,  
    the recipient may not be known at the time the XHE is created (and 
    possibly signed).
    
    Missing elements:
    
    To be able to use an XHE in conjunction with ebXML messaging and 
    possibly other protocols, it is important to be able to record the Role 
    of the From Party and the Role of the To Party.
    
    To be able to use an XHE in conjunction with ebXML messaging and 
    possibly other protocols, it is important to be able to record a 
    correlation identifier.   This supports use cases to express that an XHE 
    is a response to another XHE. SBDH had a CorrelationInformation block 
    that seems to have disappeared.
    
    To be able to use an XHE in conjunction with ebXML messaging and 
    possibly other protocols, it is important to be able to record a 
    conversation identifier.
    
    If you don't want to define these in the XHE schema,  you could add an 
    extensibility option to allow users  to add extension headers to the XHE 
    header.
    
    2.8
    
    “reference to a business case, document or other issues”.  What do 
    “business case” and “issues” mean in this context?
    
    “login”, naming:  should this be “username” ?
    
    Why are “login” and “password” specified as the mechanism to use for 
    external references?   There are other mechanisms to control access to 
    an external resource.  Threshold cryptography was invented for this 
    requirement.
    
    2.9.2
    
    “Encryption Hash”, naming:   why are you calling this an encryption 
    hash?  A hash value is about integrity, not confidentiality.
    
    “Encryption Hash”, definition:   previous protocols were hardwired to 
    MD5 or SHA1,  and regretted it when vulnerabilities were found in them.  
    It's similarly not a good idea to hard-wire hashing to SHA256, as some 
    day it too may no longer be secure.   Better to add an element 
    indicating the algorithm used,  e.g. as an IETF/W3C algorithm identifier 
    URI.
    
    In some use cases,  there is a benefit to have multiple digests using 
    different digest algorithms.
    
    “Encryption Indicator”:  this will in general be indicated using other 
    means, and a simple indicator will not be sufficient.  E.g. if you want 
    to support CMS and XML Encryption,  you might want an element that 
    indicates which encryption format you are using and more likely also 
    have explicit substructures for the selected encryption formats.
    
    Encryption formats like XML Encryption already have structures for 
    references to key references, algorithms etc. There is no need to 
    duplicate those.  In fact duplicating them creates potential 
    interpretation and interoperability issues.
    
    When using XML documents,  it would make sense to simply select XML 
    Encryption and specify in detail how it is used.   XML Encryption can 
    cover multiple types of keys including RSA and PGP.
    
    You model encryption at the level of individual payloads.  It is 
    theoretically possible that you would encrypt payloads individually, 
    maybe for different audiences, but in practice the common use case would 
    be that an entire envelope is to be encrypted, including all its 
    payloads.  The current schema does not seem to provide this 
    possibility.  By using XML encryption, there would be much more 
    flexibility to selectively encrypt.
    
    Similarly,  you model HandlingServiceId at the level of individual 
    payloads.  These assume all payloads in the XHE are handled 
    individually,  but if you are sending a bunch of payloads in an XHE,  
    presumably there is some service to handle the combination of payloads.  
    Your schema does not seem to provide this possibility.
    
    This header seems to be the only remaining bit of SBDH “BusinessService” 
    block.  The ServiceTransaction block has disappeared with all its QoS 
    elements (e.g. TimeToAcknowledgeReceipt).  These elements are used by 
    some users.
    
    
    5.6.3  PayloadContent
    
    This assumes the content is XML (or mostly XML, with some character 
    escaping).   But if the content is binary, escaping does not make sense, 
    but rather the content would be base64 encoded. To support this,  you 
    need an indicator to specify the use of base64 encoding,  or a code list 
    of encodings that includes base64 encoding.
    
    
    
    
    
    
    On 27-04-18 22:50, Chet Ensign wrote:
    > OASIS members and other interested parties,
    >
    
    
    ---------------------------------------------------------------------
    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 
    
    



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