Hi Frank, thank you for detailing it! > Adding a new profile with Core 1, a DSS vendor just had to import the > XSD within the WSDL, and in the code could do something like: > > AnyType optionalInputs = signRequest.getOptionalInputs(); > for (Object optionalInput : optionalInputs.getAny()) { > > if (optionalInput instanceof JAXBElement) { > > Object optionalInputValue = ((JAXBElement) > optionalInput).getValue(); > > if (optionalInputValue instanceof MyNewProfileElementType) { > > MyNewProfileElementType newProfile = > (MyNewProfileElementType) optionalInputValue; > > // do something with newProfile... > > } > > // ... > > } > > if (optionalInput instanceof Element) { > > // this is indeed an alien namespace, unknown to our > JAX-WS/JAXB... > > } > > } > > Hence adding a new profile had no impact on the existing processing of > other profiles. > Yes, agreed! > > With Core 2, because of the redefine top-level schema, this is no > longer the case. > Hmmm, I don't get it yet ... >> using DSS v 1.0 he was left to handle DOM fragment. > Even with Core 1, you had strong-typing via JAXB, see the above > example (which is basically a copy of our DSS code). > There is support by JAXB, but I won't call it 'strong typing'. The server side expert (like you) knowing the protocol details by heart will be able to deal with it. But think of the client side developer with a tight task of 'just add a signature'. He won't be willing to learn about all the details and build code that handles incoming response elements dynamically. A ready-made WSDL with a definitive schema is what he expects. A given set of elements in the Optional*puts with obvious cardinality. And maybe he would try to make test calls using a dynamic tool like SoapUI or Swagger. If obstacles and unpleasant surprises occur developers proclaim 'far too complex', 'immature' or 'broken' quickly! So I would like to provide a convenient experience here. And the client audience will outnumber the server developer by a magnitude, easily! > >> Nevertheless it would be a reason to include a catch-all ‘xs:any’ in >> the Optional*puts to support the ‘mustUnderstand=false’ case. > Yep. > Great! Let's see how we can sand off the other edges! Greetings, Andreas > On 01/31/2018 02:22 PM, Andreas Kühne wrote: >> >> Hi Frank, >> >> Yes, the task of ‘gluing’ may turn out to be tricky. But any server >> implementor faces this task, using DSS v 1.0 he was left to handle >> DOM fragment. Now he is a bit better off having pre-generated classes >> and IDE support. >> >> What do you mean with ‘lose the orthogonality’? >> >> Yes, the support for ‘redefine’ may be lacking. I even failed to >> handle multiple redefinitions at a time so fall back to my favourite >> tooling XSLT. This may also be an option for all stacks that do not >> support redefine. >> >> The ‘mustUnderstand’ issue is indeed an interesting aspect. But I >> wouldn’t blame it on the redefine but on the XML schema. Any client >> delivered to the world may fail when unexpected elements occur. In >> the benign case of ‘mustUnderstand=false’ it could be handy to >> silently ignore the new element. But is it really our major problem >> that we load our new version of profiles with ‘nice to have, but >> irrelevant, actually’ elements? >> >> Nevertheless it would be a reason to include a catch-all ‘xs:any’ in >> the Optional*puts to support the ‘mustUnderstand=false’ case. >> >> Greetings, >> >> Andreas >> >> *Von:*
dss-x@lists.oasis-open.org [ mailto:
dss-x@lists.oasis-open.org ] >> *Im Auftrag von *Frank Cornelis >> *Gesendet:* Dienstag, 30. Januar 2018 10:20 >> *An:* dss-x <
dss-x@lists.oasis-open.org> >> *Betreff:* [dss-x] Multi-profile support >> >> Hi, >> >> Started playing with a message-level security profile (see previous >> emails). Initial XML schema looks as follows: >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <xs:schema xmlns:xs="
http://www.w3.org/2001/XMLSchema" ; >> >> targetNamespace="urn:dss:security" >> >> xmlns:sec="urn:dss:security" >> >> xmlns:wsa="
http://www.w3.org/2005/08/addressing" ; >> >> >> xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" ; >> >> xmlns:ds="
http://www.w3.org/2000/09/xmldsig# >> <
http://www.w3.org/2000/09/xmldsig >" >> >> elementFormDefault="qualified" attributeFormDefault="unqualified"> >> >> <xs:import namespace="
http://www.w3.org/2005/08/addressing" ; >> >> schemaLocation="ws-addr.xsd" /> >> >> <xs:import >> namespace="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" ; >> >> schemaLocation="oasis-200401-wss-wssecurity-utility-1.0.xsd"/> >> >> <xs:import namespace="
http://www.w3.org/2000/09/xmldsig# >> <
http://www.w3.org/2000/09/xmldsig >" >> schemaLocation="xmldsig-core-schema.xsd"/> >> >> <xs:group name="SecurityGroup"> >> >> <xs:choice> >> >> <xs:element name="Security" type="sec:SecurityType"> >> >> <xs:annotation> >> >> <xs:documentation> >> >> Defines message-level security. >> >> </xs:documentation> >> >> </xs:annotation> >> >> </xs:element> >> >> </xs:choice> >> >> </xs:group> >> >> <xs:complexType name="SecurityType"> >> >> <xs:sequence> >> >> <xs:element ref="wsa:MessageID"> >> >> <xs:annotation> >> >> <xs:documentation> >> >> A unique identifier for this message. >> >> </xs:documentation> >> >> </xs:annotation> >> >> </xs:element> >> >> <xs:element ref="wsu:Timestamp"> >> >> <xs:annotation> >> >> <xs:documentation> >> >> Message should only be used within this time >> frame. >> >> </xs:documentation> >> >> </xs:annotation> >> >> </xs:element> >> >> <xs:element ref="wsa:ReplyTo"> >> >> <xs:annotation> >> >> <xs:documentation> >> >> The URL to which the DSS should send a >> response message. >> >> </xs:documentation> >> >> </xs:annotation> >> >> </xs:element> >> >> <xs:element ref="ds:Signature"> >> >> <xs:annotation> >> >> <xs:documentation> >> >> The message signature. >> >> </xs:documentation> >> >> </xs:annotation> >> >> </xs:element> >> >> </xs:sequence> >> >> </xs:complexType> >> >> </xs:schema> >> >> A profile author can always also publish the corresponding redefine >> XML schema. Example: >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <xs:schema xmlns:xs="
http://www.w3.org/2001/XMLSchema" ; >> >> xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" >> >> targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema" >> >> xmlns:sec="urn:dss:security" >> >> elementFormDefault="qualified" attributeFormDefault="unqualified"> >> >> <xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/> >> >> <xs:import namespace="urn:dss:security" >> schemaLocation="dss-security.xsd"/> >> >> <xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"> >> >> <xs:complexType name="OptionalInputsSignType"> >> >> <xs:complexContent> >> >> <xs:extension base="dss:OptionalInputsSignType"> >> >> <xs:group ref="sec:SecurityGroup"/> >> >> </xs:extension> >> >> </xs:complexContent> >> >> </xs:complexType> >> >> </xs:redefine> >> >> </xs:schema> >> >> A DSS vendor however will always have to define its own top-level >> redefine XML schema, in function of the selected set of profiles that >> they want to implement. So it is up to the DSS vendor to “glue” >> together all profile redefine XML schemas into a single instance. >> Depending on the complexity of the selected profiles, this could >> become a non-trivial task. An example where I glue together two >> profiles: >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <xs:schema xmlns:xs="
http://www.w3.org/2001/XMLSchema" ; >> >> xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" >> >> targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema" >> >> xmlns:sec="urn:dss:security" >> >> xmlns:my="urn:dss:myextension" >> >> elementFormDefault="qualified" attributeFormDefault="unqualified"> >> >> <xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/> >> >> <xs:import namespace="urn:dss:security" >> schemaLocation="dss-security.xsd"/> >> >> <xs:import namespace="urn:dss:myextension" >> schemaLocation="dss-example-extension.xsd"/> >> >> <xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"> >> >> <xs:complexType name="OptionalInputsSignType"> >> >> <xs:complexContent> >> >> <xs:extension base="dss:OptionalInputsSignType"> >> >> <xs:sequence> >> >> <xs:group ref="my:mygroup"/> >> >> <xs:group ref="sec:SecurityGroup"/> >> >> </xs:sequence> >> >> </xs:extension> >> >> </xs:complexContent> >> >> </xs:complexType> >> >> </xs:redefine> >> >> </xs:schema> >> >> You kind of lose the “orthogonality” of profiles in this way. >> >> Another important aspect is the support of the xs:redefine construct >> within the different SOAP stacks out there. For our DSS we provide 4 >> SDKs: >> >> Java:
https://github.com/e-Contract/dssp >> >> WCF .NET:
https://github.com/e-Contract/dssp-client >> >> PHP:
https://github.com/e-Contract/dssp-php >> >> NodeJS:
https://github.com/e-Contract/dssp-nodejs >> >> Still have to see to what extend PHP and NodeJS have support for >> xs:redefine, as they both provide a non-mature SOAP implementation >> (compared to Java and .NET that is). If they don’t offer xs:redefine >> support, this becomes a real show stopper. >> >> Another side-effect of the redefine extension mechanism that I just >> noticed: >> >> If I look back on how we positioned our DSS, the set of profiles we >> implement evolved over time quite drastically. >> >> In our SDK clients, we simply ignore new response message elements. >> This allows the DSS to “grow" without the need for constant syncing >> with all integrating RP clients. >> >> The redefine extension mechanism assumes that each RP always has full >> knowledge of all received XML elements. If a DSS adds a new XML >> element within the response messages, and the RP client did not >> import the corresponding XML schema for this, the RP client will >> error on this because of the “alien” elements. This could limit a DSS >> vendor in adding new response message elements (without a >> corresponding request message element by the RP). A >> “mustUnderstand=false/true” extension mechanism would not have this >> side-effect. >> >> Kind Regards, >> >> Frank. >> > -- Andreas Kühne phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas Kühne Company UK Company No: 5218868 Registered in England and Wales