[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] self-describing DSS-X instances
Hi Frank, let me explain my view on the 'extension' mechanism: To me the use of an xs:any as a way to extend a given schema is more a flaw than a feature. The implementor of the spec is left on his own parsing something unknown and trying to make sense of it. No schema-generated object models helps along and all types of interpretation problems show up an runtime! As we write a specification we MUST specify the structure! So my approach to this flexibility problem is to create specific schemes including all elements. This eases the implementation of clients a lot and puts just a little more effort upon the server. In your case it is perfectly valid to define a profile that adds a ds:signature element into the OptionalInputs. And the server offers a WSDL refereing to a scheme where this ds:signature element is explicitly mentioned in the OptionalInputs. Nevertheless we came to the conclusion that directly embedding a ds:signature into the SOAP / DSSRequest message isn't a good idea due to namespace leakage and canonicalization side effects. BAse64 encoding eases the pain here. So I strongly reject the need for 'alien' namespace inclusions. The namespaces must all be known. And this isn't a restriction as sender and receiver are obliged to know them, anyway! Yes, the overall amount of parsing may increase. But you surely won't complain that there is a distinct parsing step to read a X.509 certificate within an XML message. Now there are some additional parsing required for XML within XML. This is a disadvantage but it enables a clear distinction between the 'DSS object model' and the different transport syntaxes. The processing of a request should be the same regardless of the usage of XML, JSON or whatever. E.G a XAdES object will be transferred in the same manner, always. And can be accessed at the same spot in the object model, always. This comes with the dis-advantage but avoids inter-dependencies between architectural layers. Therefore the UBL approach of 'any' representations in different syntaxes helps with our problem: A semantic 'any' may hold any content, but a XML any is limited to XML, a JSON 'object' limited to JSON, and so forth. Greetings, Andreas > Hi, > > > As one of the goals of DSS 2 is "Support other transport formats than > SOAP.", message-level security becomes a critical feature I guess. > > SOAP security is covered by WS-Security/WS-SecurityPolicy and such. A > non-SOAP binding requires message-level security, obviously by means > of XML signatures. > > > I did some more experiments with message-level security. While this > could be added in DSS 1, see: > > https://www.e-contract.be/sites/dssp/dssp-specs/dssp-specs-1.5.1.pdf > > section 2.2 Browser POST, due to the AnyType being a base64 in Core 2: > > <dss:SignRequest > xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" > xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > <dss:OptionalInputs> > <dsb:Other> > <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value> > </dsb:Other> > </dss:OptionalInputs> > </dss:SignRequest> > > it becomes impossible to express this. > > XML Signatures work at the DOM level, so we really need to be able to > add "alien-namespace" XML elements. > > > Besides the XML Signature issue, the parsing of additional profiles > becomes a two-pass operation. > > In Core 1, you could add your additional profiles within your WSDL by > means of a simple import. See example: > > https://www.e-contract.be/sites/dssp/dssp-specs/dssp-ws.wsdl > > Feeding this to JAXWS/JAXB made it possible for JAXB to actually parse > your additional profiles in one go. > > With the Core 2, you parse a first time towards base64, and then you > have to run a second JAXB unmarshalling against this. From a > usability/performance point-of-view, this becomes really painful. > > >> The structures intended to be supported by a client or a server >> system MUST be known to be implementable. But the usual tools for >> schema support leave the task of handling the content of an any type >> to the developer. Without extensive testing problems with unexpected >> content may occur at runtime, even while using typed languages. >> > An AnyType of unknown namespace (in the context of the parser like > JAWS/JAXB) simply results in a DOM element, as it should be. I don't > see the problem here. > > Even if one would acknowledge this as a problem, doing a base64 is not > solving anything at all. The problem remains. > > > > What am I missing here? > > > I'm already managed to use Jackson for JSON Schema compilation in > Java. Will play a bit with this AnyType stuff to see if the above > issues could be resolved in a generic way to keep both XML and JSON > happy. > > > > Kind Regards, > Frank. > > > > On 01/28/2018 12:16 PM, Frank Cornelis wrote: >> Hi Andreas, >> >> >> Still have to get acquainted with the JSON Schema specs/tooling, but >> it seems like OASIS UBL solved a similar problem where both their XML >> and JSON have extension points, and their XML does it via xsd:any. >> See: >> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-XML-SCHEMA-FRAGMENTS-AND-DECLARATIONS >> >> And: >> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-JSON-SCHEMA-FRAGMENTS-AND-DECLARATIONS >> >> >> >> BTW: In my “sandbox” project here, as part of my message-level >> security experiments, I also had to give the new Core 2 XSD a 2.0 >> namespace to be able to compile both Core 1 and Core 2 within the >> same Java Maven project. Core 2 will eventually receive a new >> namespace I guess? >> >> >> Kind Regards, >> Frank. >> >>> Op 26 jan. 2018, om 19:47 heeft Andreas Kühne <kuehne@trustable.de >>> <mailto:kuehne@trustable.de>> het volgende geschreven: >>> >>> Hi Frank, >>> thank you for your feedback! >>> Yes, it’s an advantage to provide a sample WSDL as implementor’s >>> support. But due to the support of current frameworks the WSDL >>> slides towards being a derived artefact. >>> I was assuming that the binding and the ‘annox’ namespaces, leaking >>> thru from prior processing steps, are just irrelevant here. >>> Interesting to see that these declarations do cause problems. Now >>> I’ll drop them before reaching the final schema stage. Surprisingly >>> no way to drop namespace declarations that are defined in the >>> incoming document using XSLT … had to fall back to RegEx. >>> Regarding the AnyType: >>> The handy use case of putting some random XML fragment into an >>> AnyType cannot be supported by the JSON syntax and vice versa. So >>> the only feasible approach to transport arbitrary data _/and/_ >>> supporting multiple syntaxes is to use some base64 encoded >>> container. And we already have a fully featured Base64DataType >>> defined in DSS (with a content describing MIME type attribute, >>> support for references and attachments). So why not align all usages >>> to the Base64DataType? >>> The biggest pain point of the current multi-syntax approach is the >>> effect on foreign schemes. As outlined in the new core draft, >>> section 2.6, some well-respected features of XML cannot easily be >>> mapped to e.g. JSON. So my current approach is to rewrite the >>> referenced schemes and replace the XML specifics. Yes, bad approach >>> but I don’t know of any better! Proposals welcome! >>> Greetings, >>> Andreas >>> *Von:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org> >>> [mailto:dss-x@lists.oasis-open.org]*Im Auftrag von*Frank Cornelis >>> *Gesendet:*Freitag, 26. Januar 2018 15:16 >>> *An:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org> >>> *Betreff:*Re: [dss-x] self-describing DSS-X instances >>> >>> Hi Andreas, >>> >>> Hereby some feedback on the XML schema and such. >>> >>> Why change AnyType exactly? >>> >>> Kind Regards, >>> Frank. >>> >>> OASIS DSS Core 2 Remarks >>> ======================== >>> >>> xml.xsd is missing from the ZIP. >>> >>> Always found it funny that there was no proper SOAP binding defined. >>> See attachment for a first shot at it. >>> >>> >>> === oasis-dss-core-schema-v1.0-os.xsd >>> >>> When trying to compile with JAX-WS I get: >>> org.xml.sax.SAXParseException; >>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd >>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd>; >>> lineNumber: 1; columnNumber: 703; Unsupported binding >>> namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. >>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" >>> <http://java.sun.com/xml/ns/jaxb/xjc>? >>> Had to remove: >>> xmlns:annox="http://annox.dev.java.net" >>> <http://annox.dev.java.net/> >>> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >>> >>> === oasis-dss-base-schema-v2.0-os.xsd >>> >>> Same error here: >>> org.xml.sax.SAXParseException; >>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd >>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd>; >>> lineNumber: 1; columnNumber: 555; Unsupported binding >>> namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. >>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" >>> <http://java.sun.com/xml/ns/jaxb/xjc>? >>> So had to remove: >>> xmlns:annox="http://annox.dev.java.net" >>> <http://annox.dev.java.net/> >>> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >>> >>> === xmldsig-core-schema.xsd >>> >>> This does not seem to be the original XMLDSig XML schema. >>> Same error here: >>> org.xml.sax.SAXParseException; >>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd >>> <file://home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd>; >>> lineNumber: 23; columnNumber: 579; Unsupported binding >>> namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. >>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" >>> <http://java.sun.com/xml/ns/jaxb/xjc>? >>> So had to remove: >>> xmlns:annox="http://annox.dev.java.net" >>> <http://annox.dev.java.net/> >>> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >>> >>> === oasis-sstc-saml-schema-protocol-1.1.xsd >>> >>> This does not seem to be the original SAML 1.1 XML schema. >>> org.xml.sax.SAXParseException; >>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd >>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd>; >>> lineNumber: 1; columnNumber: 705; Unsupported binding >>> namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. >>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" >>> <http://java.sun.com/xml/ns/jaxb/xjc>? >>> So had to remove: >>> xmlns:annox="http://annox.dev.java.net" >>> <http://annox.dev.java.net/> >>> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" >>> >>> On 01/24/2018 03:49 PM, Andreas Kuehne wrote: >>>> Hi Frank, >>>> good to see you re-joined DSS-X! >>>> Attached id the current core document reflecting our latest >>>> discussions >>>> regarding the dss:AnyType. In this version the AnyType is replaced >>>> by a >>>> Base64DataType. >>>> As you are interested in Remote Signing I added the schema of the >>>> ChipGateway profile, too. >>>> Greetings, >>>> Andreas >>>>> Hi Andreas, >>>>> Were can I find the 2.0 XML schema? >>>>> I would like to check whether a "Remote Signature" profile with >>>>> message-level integrity protection could be easily defined against >>>>> the >>>>> new 2.0 proposal. >>>>> Kind Regards, >>>>> Frank. >>>>> On 01/24/2018 12:47 PM, Andreas Kuehne wrote: >>>>>> Hi all, >>>>>> the current version of the base schema includes a set of types to to >>>>>> self-decribe the DSS-X server instance (e.g. the >>>>>> DescriptionType). There >>>>>> are similiar concepts around, a popular one is HATEOS. >>>>>> So I would consider to separate this topic from the DSS-X >>>>>> specification. >>>>>> Like the TLS details included in core version 1.0 that outdated >>>>>> quickly >>>>>> the evolving area of instance meta information may render our >>>>>> specification effort useless. >>>>>> What's your view on this? >>>>>> Greetings, >>>>>> Andreas >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 ; >>> >>> >>> >>> -- >>> Frank Cornelis >>> e-Contract.be <http://e-Contract.be> BVBA >>> https://www.e-contract.be <https://www.e-contract.be/> >> > -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]