bdxr — archive

[Pim van der Eijk]

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,